我的朋友，很高兴读到你的问题！我和你一样经历过同样的地狱，使用同样的堆栈......
方法3
老实说我永远不会尝试。原因很简单，我们不希望出现旧项目和新项目相互混合的风险。旧项目中的库很可能与新项目中的库（相同的库，不同版本）发生冲突，然后您需要重构旧代码以允许使用新版本，或者完全更改库。
迁移时，您将希望尽量减少对遗留代码的工作，如果可能的话，甚至不进行任何工作。
方法2
完美的一个，但正如你所说，它无法支付账单。如果你有足够的资金来开发它，那就太好了，那就去做吧，否则，你就……
方法一
绞杀，这对我有用。从工作共享登录开始，然后转向小功能。想象一棵树，你首先删除一些小树枝，然后将它们移动到节点，直到你能够砍掉所有东西。当您删除小功能时，它们应该在新产品上可用（显然您不能中断服务，否则您将采用方法 2）。
更具体地说，我的建议是：
Back-end
1) 使登录正常工作。就我而言，传统的一切都是关于会话的，但我们不希望新产品出现这种情况。因此，我们在登录过程中在遗留代码上实现了一种方法，该方法将从新产品中调用 Oauth 并将登录信息存储在数据库中，就像您提到的那样。原因在我回复的前端部分。
2) 定义您的遗留系统和后端如何共存，以及让它们同时工作的资源（更准确地说是 RAM 和 CPU）。
2.1) 如果万一您的旧产品在带有自定义库的 tomcat 上运行，那么您在不同的上下文中运行新产品时可能会遇到问题。如果发生这种情况，我的建议是使用 Docker（只需仔细查看内存使用情况并确保将其限制在容器上）。
3）从很小的地方开始，替换与创建几乎没有逻辑的新东西相关的功能（小问题，例如用户等），然后转移到具有中等规模逻辑或在遗留产品上确实很难看的东西最终用户日常使用。
4）其余的一切（当我离开公司时，我们还没有进入这个阶段，所以我无法提供太多信息）。
5) 不要将此项目仅仅视为迁移。让页面上的每个人都知道这是一个新产品。不应复制和粘贴旧代码，应使用最佳实践来理解和改进旧代码。
5.1）尽快进行单元和集成测试，如果您的遗留有它们，那就太好了，比较结果以确保您的重构不会破坏任何内容或更改预期输出。这是至关重要的。
前端
1）一旦“统一”登录正常工作，您将能够从新产品加载页面，就好像它们是旧产品的一部分一样（您甚至可以在旧产品的jsp上添加一个框架来加载您的角度页面，我们做到了，它的效果就像一个魅力）。
1.1) 从 UI/UX 的角度来看，拥有新旧页面并不可爱，但它会为最终用户增加价值，并在您将产品发布到生产环境后为您提供反馈。由于您的遗产现在可以访问令牌（或您正在使用的任何身份验证方法，这将是可行的）。
2) 从一开始就定义样式。不要把 UI/UX 的工作推迟到以后（就像我的团队所做的那样）。您越早弄清楚颜色、设计、图标等内容，您在会议上浪费的时间就越少，这些会议本应讨论版本及其影响，但却浪费在讨论“这不是我想要的颜色”或类似的问题上。老实说，先定义 UX，然后再定义 UI，并使其清晰可见。
3）像设计微服务前端一样进行设计。您可能需要花费很多时间才能达到这一点，但是如果您这样做了，那么从新架构迁移到微服务所造成的创伤就会小得多。
Culture
我不知道你们工作场所的文化，但我的工作场所远非完美，思想陈旧的老人进入了他们的舒适区。
改变工作场所文化以适应我们目前市场上的情况，老年人有时倾向于抵制改变，特别是当他们是技术人员并且不更新外面的新事物时。当人们离开公司时，替换他们会变得更加容易（因为人们确实会离开）。
我听说他们仍在尝试运行 Scrum（正如我提到的，我已不再在那里），因此对于定义功能迁移将发生什么以及如何发生的开发人员来说，这是一个巨大的头痛。
这是我的两分钱，希望它们能以某种方式帮助你，祝你好运。
