问题描述
当您落后多个版本时，哪种版本升级更可行的策略。例如从 6.4 到 2005。 我们真的应该像 SAP 建议的那样逐个版本地做一个版本。我知道这是推荐的方式，但仍然如此。 任何人都可以分享他们在这方面的经验吗？ 直接迁移多个版本会遇到什么困难？
谢谢！
解决方法
您可以采用多种方法。您选择哪一种取决于您的团队拥有的知识以及您已经执行的自定义数量。
一步一步
这是 SAP 推荐的方式。这是一种更安全的策略，其中非常清楚不同版本之间的变化。对于每个版本，您都会遇到构建失败、启动失败甚至可能需要迁移的数据问题。但是很明显是哪个版本导致了这些问题。借助 SAP 帮助和升级说明，您应该能够轻松找到更改的内容以及修复方法。这种方法的缺点是您需要为每个版本下载、解压缩和构建，这需要时间。有时你甚至需要两次修复相同的代码，当实现多次更改时
一枪
通过这种方法，您可以直接进入最新版本。您只需将自定义代码放在最新版本中，然后看看您会遇到哪些构建失败。 使用这种方法，将更难弄清楚究竟是什么版本升级导致了特定问题。您仍应检查所有升级说明，以确保不需要迁移。优点是您只需执行一次。如果您有经验丰富的团队，这是一种可行的方法。如果您有一个新团队，请小心使用这种方法。您可能会遇到一些难以确定的错误，其中您不确定是哪个版本导致的，因此在 SAP 帮助中查找信息可能会更困难
混合方法
第三种选择是混合方法，您可以一次升级多个版本（例如，升级到包含重大更改的版本，例如在 6.3 中添加后台）。这样可以更轻松地为那些重大更改应用更改，而您不必一一检查每个版本。
结论
我过去尝试过所有方法。循序渐进的方法需要很多时间，但使更改更容易和更清晰。使用 One Shot 方法，您只需要下载最新版本，但可能更难找到错误。如果您有一支经验丰富的团队，则应该采用一次性方法。当你落后很多版本并且有很大的变化时，你可以选择混合方法
,我有类似的要求，要从 6.2 版升级到 2005，我采用了Yoni 所述的一次性方法，而我面临的最大挑战是 Java版本变更。
我相信一次性方法和循序渐进方法在主要版本升级中花费的时间相似，尽管循序渐进 strong> 方法是安全但多余的。我个人最喜欢的是One-Shot。