按路径划分的 S/4HANA 迁移时间线与项目计划

根据我的经验，从 SAP ECC 出发的 S/4HANA 迁移时间线，棕地系统转换需要 12 至 18 个月，绿地新实施需要 18 至 24 个月。选择性数据迁移需要 12 至 18 个月。项目计划遵循 SAP Activate 的六个阶段，而最常超期的阶段是自定义代码。

简短的回答：用 SAP Readiness Check 作为计划的起点，并给数据留出 30% 至 40% 的工作量。在棕地项目中，安排三次模拟转换，并预期切换停机时间在一个周末到一周之间。

本文是我的 ECC 到 S/4HANA 迁移指南背后的时间线与计划细节，那篇指南讲的是迁移路径和 ECC 截止日期。如果您是全新实施 SAP，而不是从 ECC 迁出，我的 SAP 实施时间线指南覆盖了这种情况，并给出了各阶段的时长。

路径决定时长。我的原则：从其他系统迁移过来或必须定义新流程时，选绿地。流程已定义且运行良好时，选棕地；只有部分领域的流程需要重新定义时，选选择性迁移。

下表是我见过的项目中每条路径需要的时间，以及通常拉长时间的因素：

路径	典型时间线	计划围绕什么展开	通常拉长时间的因素
棕地（系统转换）	12 至 18 个月	用 Software Update Manager 转换现有 ECC 系统，然后反复进行测试转换	自定义代码适配和业务伙伴转换
绿地（新实施）	18 至 24 个月	Fit-to-Standard 设计、构建和反复的数据加载周期	演变成冗长需求清单的 Explore 研讨会，以及数据清洗
选择性数据迁移	12 至 18 个月	商定哪些公司代码、业务单元和历史数据要迁移，然后使用专业工具	数据范围界定，以及对专业合作伙伴的依赖

日历和路径同样重要。对于增强包 6 至 8 上的 ECC，主流维护于 2027 年 12 月 31 日结束（SAP News）。本月启动的棕地项目将在 2027 年 10 月至 2028 年 4 月之间上线，现在启动的绿地项目则会在 2028 年上线。

所以，今天编写的大多数计划都需要在预算中留出一部分延长维护费用。一开始就放进去，不要等到第二年才成为意外。

RISE with SAP 是一个商业套餐，不是一条路径。在 RISE 下进行的棕地或选择性迁移，落地在 SAP Cloud ERP Private 上，这是 SAP 对很多人仍在搜索的 S/4HANA Cloud Private Edition 的现用名称。我给出的 GROW with SAP 6 至 9 个月和 RISE 9 至 18 个月，指的是新实施，而不是 ECC 迁移。

SAP Activate 是 SAP 用于 S/4HANA 的交付方法。它有六个阶段：Discover、Prepare、Explore、Realize、Deploy 和 Run（SAP Activate）。

迁移使用同样的阶段。变化的是每个阶段内部的工作。

迁移项目计划

1. 01

   Discover

   Readiness Check、路径决策和业务论证。

2. 02

   Prepare

   计划、治理、团队和第一个沙箱。

3. 03

   Explore

   Fit-to-Standard 或差异设计，商定 WRICEF 清单。

4. 04

   Realize

   构建、自定义代码、数据加载、测试转换。

5. 05

   Deploy

   彩排、切换和上线。

6. 06

   Run

   Hypercare、稳定运行并停用 ECC。

下表是迁移项目中每个阶段的内容，以及各条路径的差异：

阶段	迁移中发生什么	各路径有何不同
Discover	SAP Readiness Check、路径决策、业务论证、对自定义代码和数据的初步了解	选择性迁移需要在这里形成初步的数据范围
Prepare	计划、治理、团队、数据责任、沙箱	棕地进行第一次沙箱转换；绿地搭建系统并排定研讨会日程
Explore	Fit-to-Standard 研讨会或差异设计，商定 WRICEF 清单，数据映射	绿地在这里花的时间最长；棕地逐一处理适用的简化项
Realize	构建、自定义代码适配、数据加载周期、测试轮次	棕地进行模拟转换；绿地进行加载周期，通常使用 Migration Cockpit
Deploy	彩排、切换、上线	停机窗口取决于路径、数据量和方法
Run	Hypercare、稳定运行	停用 ECC，并归档您保留的内容

WRICEF 代表工作流、报表、接口、转换、增强和表单。它是您在 SAP 标准之外构建的所有内容的清单，也是需要盯紧的数字。

在我主导或挽救过的 21 个 SAP 项目中，最大的错误是在实施开始时没有好好做计划。在 Prepare 阶段，要商定由谁负责数据清洗、哪些自定义代码要淘汰，以及每次测试转换和彩排的时间。这些日期会成为计划的主干。

棕地：围绕测试转换做计划

棕地计划围绕转换周期来构建。Software Update Manager 负责转换系统，每一次测试运行都会告诉您正式转换需要多长时间，以及哪里会出问题。

在棕地项目中，我会在切换前安排三次模拟转换。每一次都应在最近的生产系统副本上运行，这样时长数据才有意义。最后一次应该像上线一样进行：同样的顺序、同样的人员、同样的检查。

SAP 自己为其停机优化方法制定的计划也类似。它列出了沙箱运行、质量保证运行、在克隆系统上的加载验证和彩排（SAP Learning）。SAP 指出，技术上可以减少运行次数，但会增加风险。

绿地：围绕设计和数据加载做计划

绿地的时间花在 Explore 上。Fit-to-Standard 研讨会决定您采纳多少 SAP 标准，每一个差距都会变成需要构建、测试和维护的 WRICEF 对象。

数据按加载周期迁移，通常使用 SAP S/4HANA Migration Cockpit。要计划好几轮完整的加载周期，每一轮之后都要有一次由业务签字确认的对账。我的 Migration Cockpit 分步指南讲解了暂存表、迁移对象和加载流程。

选择性：围绕数据范围做计划

选择性迁移的计划从数据范围开始。哪些公司代码、业务单元和多少年的历史数据要迁移，哪些流程要重新设计。

这个范围决定了工具、专业合作伙伴和测试周期。范围一旦后期变动，时间线也会随之移动。

根据我的经验，自定义代码是最常超期的阶段。它也是迁移中最常被遗忘的隐性成本，我的 S/4HANA 迁移成本指南对此有详细讲解。

以下是我会按顺序盯紧的地方：

1. 自定义代码。 团队根据一份报告来估算范围，等到开始修复时才发现真实的规模。在一个项目中，借助 smartShift 的分析，自定义对象从 18,000 个减少到 3,200 个。先淘汰，再适配。
2. 评估遗漏的自定义对象。 根据我的经验，SAP Readiness Check 遗漏的自定义对象，正是后来造成麻烦的那些。在把它的输出当作您的范围之前，请先读我的 SAP Readiness Check 指南。
3. 数据。 数据迁移占工作量的 30% 至 40%。数据清洗没有负责人时，就会启动得很晚，然后挤压测试周期。我关于SAP 数据迁移为何失败的文章讲得更深入。
4. Explore。 预算在 Explore 阶段受到冲击，因为 WRICEF 清单不断变长。当供应商控制范围时，供应商那边没有人有理由阻止它增长。
5. 为了节省时间而削减的演练。 为了保住日期而取消的一次演练，往往会在上线周末花掉比它省下的更多的时间。

我的观点：在 Explore 结束时锁定上线日期，那时 WRICEF 清单和自定义代码范围都已明确。在项目启动时定下的日期，只是一个附带了董事会演示文稿的猜测。

我见过的切换停机时间从一个周末到一周不等。数据量、转换方法、同时上线的实体和接口数量，以及业务验证的速度，都会影响它。

对于棕地，SAP 在 Software Update Manager 中提供了停机优化转换方法。它把部分数据转换和迁移工作移到系统运行期间完成，同时生产系统继续运行。

这不是白来的时间。SAP 列出了额外的测试运行、更复杂的计划、停机前对配置和开发的冻结，以及一名接受过该方法培训的专家。

所以，在选择技术方法之前，先商定业务能够接受的停机时间。然后在模拟转换中证明它，而不是在上线周末。让切换避开月结和业务旺季。

计划的好坏取决于它背后的假设。以下是我会在任何人签字之前提出的问题：

1. 计划假设的是哪条路径，我们的 Readiness Check 结果中有什么支持它？
2. 经过使用情况分析后，范围内有多少自定义对象，其中多少会被淘汰？
3. 谁负责数据清洗，从哪个阶段开始？
4. 计划了多少次模拟转换或加载周期，使用什么数据？
5. 计划假设的停机时间是多少，由哪一次测试运行来证明？
6. 日期什么时候锁定，如果 WRICEF 清单在 Explore 阶段增长，日期会怎样？

请合作伙伴提供与您类似项目的参考案例，以及他们的概要设计。如果回答很笼统，没有针对您的业务，就把它当作危险信号。

本季度就运行 SAP Readiness Check。在任何人承诺上线日期之前，把自定义代码和数据方面的发现摆到 CFO 和项目总监面前。

然后，从您能够接受的切换窗口倒推来构建计划：棕地安排三次模拟转换，或者安排您的路径所需的加载周期。如果想先检验路径本身，可以试试我的绿地与棕地迁移评估。

我帮助企业制定并压力测试这样的迁移计划。如果您需要一个独立的视角，欢迎与我联系。

S/4HANA 迁移需要多长时间？

根据我的经验，从 ECC 进行棕地转换需要 12 至 18 个月，绿地实施需要 18 至 24 个月，选择性数据迁移需要 12 至 18 个月。自定义代码是最常超期的阶段，数据迁移占工作量的 30% 至 40%。

S/4HANA 迁移项目计划有哪些阶段？

计划遵循 SAP Activate：Discover、Prepare、Explore、Realize、Deploy 和 Run。在迁移中，Discover 包含 Readiness Check 和路径决策，Realize 包含自定义代码、数据加载和测试转换，Deploy 包含彩排和切换。

S/4HANA 棕地迁移需要几次模拟转换？

在棕地项目中，我会在切换前安排三次模拟转换。对于其停机优化方法，SAP 列出了沙箱运行、质量保证运行、加载验证和彩排，并指出减少运行次数会增加风险。

S/4HANA 切换停机时间有多长？

我见过的切换停机时间从一个周末到一周不等。它取决于数据量、转换方法，以及有多少实体和接口同时上线。SAP 的停机优化转换把部分工作移到系统运行期间，但需要更多的测试运行和计划。

我们能在 2027 年 ECC 支持结束前完成 S/4HANA 迁移吗？

增强包 6 至 8 上的 ECC 主流维护于 2027 年 12 月 31 日结束。2026 年 10 月启动的棕地项目将在 2027 年 10 月至 2028 年 4 月之间上线，绿地项目则在 2028 年上线。现在启动的大多数项目都应为一部分延长维护做好预算。

什么因素最容易拖延 S/4HANA 迁移项目？

根据我的经验，最常超期的是自定义代码，其次是启动太晚的数据清洗，以及在 Explore 阶段不断变长的 WRICEF 清单。项目开始时没有好好做计划，是其中大多数问题的根源。