这个问题是关于迁移项目的。目前遗留应用程序在 ColdFusion 中，我们希望将其迁移到 Spring Framework。
所以我的主要问题是:
- 在考虑迁移项目时需要注意哪些事项？
- 在考虑从 ColdFusion 迁移到 Spring Framework 时，我需要牢记任何具体事项吗？
- ColdFusion 如何与 Spring 框架相结合？
- 在开始从 ColdFusion 到 Spring 的迁移项目之前，您会推荐哪些资源让我自己熟悉？
我知道有些人可能认为这是一个非常开放的问题，但这是我的第一个迁移项目，我从来没有任何迁移项目的经验，也没有在这里寻找一些有用的指导。
最佳答案
移民项目充满危险。
第一个危险是，“这既昂贵又痛苦。让我们重建吧 这一切都从头开始，并实现任何新的想法或功能 任何营销人员/经理/程序员都使用结构化方法 等等等等……”这条路通向厄运，因为
1) 它是一个开放式的工作量，并且
2) 没有人真正知道旧系统的作用(最近看过规范吗？)因此，您最终会在新系统上线后重新发现旧系统的功能，这会给组织的能力带来巨大的痛苦和损害使用新软件完成它的工作。实际上，通常新系统永远赶不上旧系统，因此重写以丑陋的方式死去。
进行这种迁移的正确方法是:坚持保留功能，并转换现有系统。没有新的东西、功能和方法。
这种坚持有其自身的麻烦:组织经常不得不做出一些改变 出于生存原因，在发生迁移的窗口期间。
要解决这个问题，您确实需要一个自动迁移工具，以便“无功能更改”规则仅在实际转换期间适用，因此尽可能短。迁移工具的开发人员花一些时间来构建它并彻底测试转换工具是可以的；同时，本组织可以通过通常的方法增强遗留系统。当迁移工具准备就绪时......扣动扳机，转换代码，修补问题并测试结果系统的有效性。
系统迁移完成后，您就可以考虑彻底重组或 reshape ，因为您知道基本功能仍然完好。
无论您为自动迁移工具选择什么，您都需要注意它生成的代码在新环境中是可维护的。许多转换器转换为真正朴素的 1 对 1 转换，生成的代码最终成为 legacy-foo-coded-in-new-bar，或者在朴素的 COBOL 到 Java 转换之后被笑称为“JOBOL”。转换工具必须精通如何映射语言结构。 (您可能想阅读关于 PL/1 To Java Conversion 的 SO 讨论)。
您最大的麻烦可能是“测试”。目前的系统已经完成了功能测试，对吧？呃，你没有任何功能测试？您将如何验证新系统是否正确执行了旧系统所做的事情？
这里的正确答案是根据遗留系统的输入输出行为构建测试，并将这些测试应用于遗留系统和迁移系统。这是很多工作，没有人愿意做，更不用说付钱了。这是迁移失败的第二种方式。
发生的最后一件事是，管理层严重缺乏资金和时间来完成这项工作。通常与开发团队的谈判是这样的:
Mgr: How long to do this?
Team: Two years...?
Mgr: BZZZT! Wrong answer, try again...
Team: One year?
Mgr: BZZT! ..
Team: (Gulping) 6 months?
Mgr: OK, get started.
请注意这里没有对工作的实际讨论。
6 个月后，将开始指责。经理:“我问你们，你们说 6 个月……”
你的旅程很艰难。仔细准备。坚持让人们真正列出所有问题，并得出可信的估计。如果您是第一次进行迁移，那么您没有很好的基础来做出这样的估计；如果是该组织的第一次，则没有依据来判断任何估计是否正确。
(完全披露:我有偏见。我已经构建自动化迁移工具 22 年了。查看 B2 migration。)
关于java - 应用迁移注意事项 : ColdFusion to Spring，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/2830612/