ECC 到 S/4HANA 迁移：路径、步骤与时间线

SAP ECC 的主流维护将于 2027 年 12 月 31 日结束，距今约 15 个月。可选的延长维护持续到 2030 年底，费用更高（SAP News）。复杂的迁移一旦真正开始测试，很容易拉长到 18 至 24 个月。如果您还没有选定路径，要在截止期限之前上线，已经不太可能。

如果您是做这个决定的 CIO 或项目负责人，您有三条路径：Greenfield、Brownfield 或选择性数据转换。每条路径背后的工作都遵循同样的五个步骤。先运行 SAP Readiness Check，再做选择。

从 ECC 到 S/4HANA 不是一次直接升级。它改变了数据的存储方式、事务的过账方式和用户的工作方式。在我参与的一个项目中，团队把几十份自定义报表按 ECC 里的样子原封不动地重建了。没有人问过它们是否还需要。后来，其中一半从未被使用。迁移在技术上很干净，价值却没有。

决定迁移工作量的差异如下：

领域	SAP ECC	SAP S/4HANA
数据库	任何受支持的数据库（Oracle、Db2、SQL Server 等）	仅限 SAP HANA
财务数据模型	FI、CO 和盈利能力分析各有独立的表，外加汇总表	Universal Journal（表 ACDOCA）作为唯一的行项目来源
客户和供应商主数据	客户和供应商记录分开	业务伙伴为必选
用户界面	SAP GUI	SAP Fiori 应用，本地部署和 Private Edition 仍可使用 SAP GUI
部署方式	本地部署	本地部署、Private Edition（RISE with SAP）或 Public Edition（GROW with SAP）
扩展	Z 程序和修改	Clean Core：已发布的 API、同栈 ABAP Cloud，或 SAP BTP 上的并行（side-by-side）扩展
维护	EHP 6 至 8 的主流维护到 2027 年底，延长维护到 2030 年底	SAP 承诺维护到 2040 年底

我合作过的一个客户一直在问，为什么转换之后他们的自定义批处理作业不能用了。这些逻辑依赖的是 ECC 的表结构，而 S/4HANA 改变了这些结构。迁移本身已经完成。没有人问过，这些作业在新模型里是否还有意义。

迁移搬运的是数据。真正的问题是，您打算如何处理继承下来的设计决策。

Decide

哪条迁移路径适合您的情况？

遗留系统支离破碎，您想重新设计流程

→Greenfield

流程合理，ECC 稳定，必须保留历史数据

→Brownfield

多实体，希望部分复用并选择性迁移数据

→Bluefield

Greenfield：重新开始

全新实施 S/4HANA。不沿用任何旧配置，流程依照 SAP 标准重新设计，只通过 SAP S/4HANA Migration Cockpit 加载您需要的数据。

适用于遗留系统过于零散、无法干净地转换，或者业务希望重新思考流程，而不是照搬流程的情况。

需要留意变革带来的负担。用户会失去熟悉的工作流程。我见过一些公司后悔没有让用户为 Greenfield 系统的不同感受做好准备。如果采用度规划要到培训阶段才开始，就已经晚了。

Brownfield：系统转换

您现有的 ECC 系统就地转换。配置、自定义代码和历史数据都会随您带过去。技术转换通过 Software Update Manager（SUM）及其数据库迁移选项来运行。

适用于流程成熟、交易历史对合规很重要，并且没有重大重组正在进行的情况。

需要留意您带过去的技术债务。除非在转换期间有意识地清理，否则遗留系统的复杂性会随您一起迁移。

选择性数据转换

有时被称为“bluefield”。您迁移选定的公司代码、业务单元或数据的时间切片，而不是全部，通常要借助专门的工具和有经验的合作伙伴。它适合通过并购或业务剥离形成的集团，或者多年历史数据已不再重要的情形。

适用于您想要 Greenfield 式的流程自由，同时在关键之处保留 Brownfield 式的数据连续性的情况。

下面是这三条路径在董事会通常会问的问题上的对比：

标准	Greenfield	Brownfield	选择性
流程重新设计	全面，依照 SAP 标准	基本保留	按单元选择
历史数据	不沿用（或仅沿用未清项和余额）	完整沿用	选定范围
上线时间	较长	较短	取决于范围
技术债务	消除	沿用	迁移范围内减少
变革影响	高	较低	中等
最适合	零散的遗留系统，大幅重新设计	稳定、维护良好的 ECC	并购、业务剥离、分阶段推广

迁移顺序

1. 01

   评估

   运行 SAP Readiness Check。盘点自定义代码、附加组件和接口。

2. 02

   数据分类

   把数据分为热、温、冷三类。冷数据不必迁移。

3. 03

   清理

   解决重复、不一致和缺失字段。总是比计划花得更久。

4. 04

   调整代码

   运行 ABAP Test Cockpit 检查。减少 Z 代码，而不是单纯移植。

5. 05

   测试与切换

   多轮测试，外加至少一次完整的切换演练。

1. 评估与就绪度

从这里开始。永远如此。SAP Readiness Check 会分析您的 ECC 系统，并报告简化项、附加组件兼容性、自定义代码、数据量和规模估算。

意外通常来自附加组件和自定义代码。我合作过的一些客户有数百个自定义对象在范围内，大多数人对出现的闲置代码数量感到吃惊。第二周发现，好过第十二个月才发现。

同时检查技术前提。转换支持从任意增强包的 SAP ERP 6.0 开始。系统必须是 Unicode，否则要规划两步转换。双栈系统需要先拆分。转换之前，客户和供应商主数据必须转换为业务伙伴。最后这一条难倒的团队比任何一条都多。

2. 数据分析与分类

迁移之前先衡量您的数据，并对它分类：

1. 热： 经常使用，实时处理所需。
2. 温： 偶尔访问，相关但并非每日使用。
3. 冷： 历史数据或未使用的数据，仅为审计保留。

冷数据不需要进入 S/4HANA。把它归档。跳过这一步的团队会把杂乱带进新系统，既拖慢迁移，也拖慢性能。

3. 数据清理与归档

这一步花的时间，比任何计划预留的都长。重复的供应商记录。不一致的计量单位。填了一半的客户主数据。每个 ECC 系统都有这些问题，如果没人先修复，它们会原封不动地进入 S/4HANA。

我合作过的一个客户，仅数据清理和归档就花了五个月。跳过清理的团队，会在切换时才发现问题，那时已经没有时间好好修复。我那篇关于 SAP 数据迁移为何失败的文章对这一步讲得更深入。

4. 自定义代码调整

运行 ABAP Test Cockpit（ATC）的 S/4HANA 就绪度检查，它会把您的代码与 SAP 的简化项做比较。输出显示哪些需要语法修复，哪些需要功能替换，哪些应该淘汰。

目标是减少 Z 代码，而不只是让 Z 代码能运行。您带过去的每个自定义对象，都会给今后的每一次升级增加成本。我的 Clean Core 指南讲了如何对保留下来的部分分类。

5. 测试、培训与切换

分轮次进行测试：单元测试、集成测试、用户验收测试（UAT），然后至少做一次完整的切换演练。UAT 要同时纳入重度用户和偶尔使用的用户。他们发现的问题不同。

演练不是可选项。它会暴露只有整个流程跑一遍才会出现的时间缺口、缺失的校验和接口故障。跳过演练的团队，会在上线的周末碰上这些问题。

我希望在任何迁移计划中都能看到的 SAP 工具：

工具	作用	何时使用
SAP Readiness Check	简化项、附加组件、自定义代码、规模估算	选择路径之前
ABAP Test Cockpit (ATC)	找出会失效的自定义代码	自定义代码调整
SAP Signavio	显示流程实际如何运行，而不是文档如何记载	设计冻结之前
SAP LeanIX	绘制应用和接口图谱	集成设计
Software Update Manager (SUM)	运行技术转换	Brownfield 转换
SAP S/4HANA Migration Cockpit	加载主数据和交易数据	Greenfield 数据迁移

对于增强包 6 至 8 上的 SAP ERP 6.0，主流维护于 2027 年 12 月 31 日结束。可选的延长维护持续到 2030 年 12 月 31 日，需在维护基数上额外加收两个百分点。更早的增强包已在 2025 年底退出主流维护。

2030 年之后只有一条狭窄的路。SAP 的 SAP ERP 私有版过渡选项覆盖 2031 至 2033 年。它只适用于在 2030 年底之前迁移到 SAP HANA 上 SAP ERP 私有版的大型系统，并且只有配合 SAP 的 max success plan 才可用。请把它当作例外，而不是计划。

在时长方面，复杂系统的完整迁移一旦真正开始测试，可能拉长到 18 至 24 个月甚至更久。对中型到大型公司来说，准备充分的转换通常需要 12 至 18 个月或更久。跨多个实体的大型 Greenfield 项目可能需要 24 至 36 个月。

1. 2027ECC 主流维护结束12 月 31 日，适用于 SAP ERP 6.0 EHP 6 至 8
2. 2028现在启动的话，可能的上线时间真正开始测试后需要 18 至 24 个月
3. 2030延长维护结束可选，需加收两个百分点
4. 2033过渡选项结束私有版，仅限大型系统

来源: SAP News，2020 年 2 月和 2025 年 8 月

所以算术很简单。如果您今天开始一项复杂的评估，上线会落在 2028 年。请为延长维护编列预算，并利用这段时间清理数据、淘汰自定义代码，而不是干等。想测试您的选项，可以试试我的迁移评估。

ECC 到 S/4HANA 的 Greenfield 和 Brownfield 迁移有什么区别？

Greenfield 是全新实施：不沿用任何旧配置或自定义代码，流程依照 SAP 标准设计，只加载您需要的数据。Brownfield 转换您现有的 ECC 系统，保留配置、自定义代码和历史数据。它更快、干扰更小，但技术债务会一并带过去。选择性数据转换介于两者之间。

SAP ECC 到 S/4HANA 的迁移截止期限是什么时候？

对于增强包 6 至 8 上的 SAP ERP 6.0，主流维护于 2027 年 12 月 31 日结束。可选的延长维护持续到 2030 年 12 月 31 日，需在维护基数上额外加收两个百分点。2031 至 2033 年的过渡选项，仅适用于在 2030 年底之前迁移到 SAP HANA 上 SAP ERP 私有版的大型系统。

SAP Readiness Check 会告诉您什么？

它会分析您的 ECC 系统，并报告影响您配置的简化项、附加组件兼容性、自定义代码影响、数据量和 HANA 规模估算。尽早运行它会改变范围讨论，因为团队经常发现他们不知道自己依赖的附加组件和自定义代码。

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

对中型到大型公司来说，准备充分的转换通常需要 12 至 18 个月或更久。复杂的多实体项目一旦真正开始测试，可能拉长到 18 至 24 个月，大型 Greenfield 项目则为 24 至 36 个月。数据清理是进度延误最常见的原因。

什么是 Universal Journal（ACDOCA），它为什么对迁移很重要？

Universal Journal 是单一的行项目表 ACDOCA，它把 ECC 中分别存放在不同表里的财务会计、管理会计和盈利能力分析数据整合在一起。读取旧结构（例如 COEP 或盈利能力分析表）的自定义代码和报表需要审查。有些只需小幅调整，有些则需要重新设计。

把 ECC 转换到 S/4HANA 有哪些技术前提？

转换支持从任意增强包的 SAP ERP 6.0 开始。系统必须是 Unicode，否则要采用两步法。双栈系统必须先拆分。客户和供应商主数据必须转换为业务伙伴。在确定日期之前，请先运行 SAP Readiness Check 和 ATC 自定义代码检查。

ECC 迁移应该选 RISE with SAP 还是 GROW with SAP？

大多数有大量自定义代码和复杂流程的 ECC 客户，会选择 RISE with SAP 下的 S/4HANA Cloud Private Edition，它支持现有系统的转换。GROW with SAP 使用 Public Edition，这是一次采用标准流程、只允许使用已发布 API 扩展的全新实施。它适合愿意采用 SAP 标准的公司。