
目录
ECC 到 S/4HANA 迁移,是把您的 SAP ERP 系统从 SAP ECC 6.0 迁移到 SAP S/4HANA,同时换上新的数据库、财务数据模型和用户界面。您要做的决定是选哪条路径,以及能否在 ECC 主流维护于 2027 年 12 月 31 日结束之前上线。
简短的回答:从其他系统迁移过来或需要新流程,选绿地;流程已定义且运行良好,选棕地;只有部分领域需要重新设计,选选择性数据迁移。根据我的经验,棕地需要 12 至 18 个月,绿地需要 18 至 24 个月,选择性数据迁移需要 12 至 18 个月。在确定任何一条路径之前,先运行 SAP Readiness Check。
ECC 到 S/4HANA 不是一次简单的升级。数据的存储方式、交易的过账方式和用户的工作方式都会改变。
在我参与的一个项目中,团队把几十张自定义报表按照 ECC 中的原样重建了一遍。没有人问过它们是否还需要。后来,其中一半从未被使用。
迁移在技术上很干净。价值却没有体现。
SAP ECC 是 SAP ERP Central Component 的缩写。它是 SAP ERP 6.0 的核心,也是 SAP Business Suite 7 的核心应用之一。人们说“SAP ECC”时,几乎总是指 ECC 6.0。它在 SAP 支持的任何数据库上运行财务、管理会计、采购、销售和生产,从 Oracle 到 SQL Server 和 Db2 都可以。
迁移的第一个理由是维护。对于增强包 6 至 8 的 SAP ERP 6.0,主流维护于 2027 年 12 月 31 日结束。增强包 5 及以下的系统已在 2025 年底结束主流维护(SAP)。
SAP S/4HANA 是它的继任者,SAP 已承诺维护到 2040 年底。
第二个理由是时间。如果您今天,也就是 2026 年 10 月,开始棕地转换,上线会落在 2027 年底到 2028 年春之间。如果今天开始绿地,您会在 2028 年上线。
所以对大多数 ECC 客户来说,问题已经不是要不要迁移。问题是走哪条路径,以及迁移期间要为延长维护准备多少预算。
我也在自己的 YouTube 频道上用一段视频(英文)讲解了这个话题。
决定大部分迁移工作量的是以下这些差异:
| 领域 | SAP ECC | SAP S/4HANA |
|---|---|---|
| 数据库 | 任何受支持的数据库(Oracle、Db2、SQL Server 等) | 仅 SAP HANA |
| 财务数据模型 | FI、CO 和获利能力表各自独立,并有汇总表 | 通用日记账(表 ACDOCA)作为唯一的行项目来源 |
| 客户和供应商主数据 | 客户和供应商记录分开 | 业务伙伴为强制要求 |
| 物料号 | 18 位 | 启用扩展长度后最多 40 位 |
| 信贷管理 | SD 信贷管理 | SAP Credit Management(FIN-FSCM) |
| 用户界面 | 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 上并行扩展 |
| 维护 | EHP 6 至 8 主流维护到 2027 年底,延长维护到 2030 年底 | 承诺维护到 2040 年底 |
SAP 把每一项差异都记录为一个简化项,并在每个 S/4HANA 版本的简化清单中公布。有些对每个客户都是强制的,比如业务伙伴。另一些只有在您使用该功能时才有影响,而 SAP Readiness Check 会告诉您哪些适用于您的系统。
2023 年我合作过的一家欧洲制造业客户,一直在问为什么转换后他们的自定义批处理作业不再运行。这些逻辑依赖于 ECC 的表结构,而 S/4HANA 已经改变了这些结构。没有人问过这些作业在新模型中是否还有意义。
迁移搬走的是数据。真正的问题是,您如何处理继承下来的设计决策。

我的选择原则很简短。从其他系统迁移过来,或者需要定义新流程时,选绿地。流程已定义且运行良好时选棕地,部分领域的流程需要重新定义时选选择性数据迁移。
哪条 ECC 到 S/4HANA 路径适合您的情况
绿地
从其他系统迁移过来,或需要定义新流程
棕地
流程已定义且运行良好
选择性数据迁移
只有部分领域需要重新定义流程
绿地:全新实施
这是全新实施 S/4HANA。不沿用任何旧配置,流程按照 SAP 标准设计,只加载您需要的数据。
如果您今天有一部分业务运行在非 SAP 系统上,这是自然的选择。我见过一些公司后悔没有让用户提前准备好面对绿地系统带来的巨大差异。如果推广采用的规划要到培训阶段才开始,那就已经晚了。
棕地:系统转换
棕地就是系统转换。您现有的 ECC 系统原地转换,配置、自定义代码和历史数据都随之迁移。技术转换通过 Software Update Manager(SUM)及其数据库迁移选项完成。
SAP 为每个版本发布 SAP S/4HANA Conversion Guide,其中列出前提条件和技术步骤的顺序。在规划日期之前,先读目标版本的那一份。风险在于带过去的技术债务,因为除非您有意识地清理,旧的复杂性也会一起迁移过去。
选择性数据迁移
选择性数据迁移只迁移选定的公司代码、业务单元或某些时间段的数据,而不是全部。它需要专门的工具,以及在这方面有经验的合作伙伴。有些供应商把它称为“蓝地”来销售。
它适合这样的集团:财务运行良好,但采购需要重新设计;或者并购和剥离让截然不同的流程并存。您可以重新设计需要改的领域,并在重要的地方保留历史数据。
下面按董事会通常会问的问题,对三条路径做个比较:
| 路径 | 何时选择 | 典型时间线 | 主要风险 |
|---|---|---|---|
| 绿地 | 从其他系统迁移过来,或需要定义新流程 | 18 至 24 个月 | 用户承受的变革负担,以及留在旧系统中的历史数据 |
| 棕地 | 流程已定义且运行良好 | 12 至 18 个月 | 技术债务和未使用的自定义代码被带过去 |
| 选择性数据迁移 | 部分领域的流程需要重新定义 | 12 至 18 个月 | 依赖专门的工具和合作伙伴,数据范围界定复杂 |
路径不同,细节会变,但顺序不变。以下是我会规划的五个步骤,按顺序排列。
迁移顺序
Readiness Check
运行 SAP Readiness Check,确认技术前提条件。
选择路径并规划
选择路径、确定范围,在开始构建之前规划整个项目群。
自定义代码
找出在用的内容,淘汰其余部分,改造保留下来的部分。
数据
在迁移任何内容之前,先分类、清洗和归档。
测试与切换
多轮测试,加上至少一次完整的切换演练。
1. 运行 Readiness Check
从这里开始。每次都是。SAP Readiness Check 会分析您的 ECC 系统,并报告简化项、附加组件兼容性、自定义代码、数据量和容量规划。
意外通常出在附加组件和自定义代码上。我合作过的一些客户,范围内有数百个自定义对象。在第二周发现,总比在第十二个月发现要好。
如果是棕地转换,请同时检查以下前提条件:
- 版本:任何增强包的 SAP ERP 6.0 都可以进行转换。
- Unicode:系统必须是 Unicode,否则就要规划两步转换。
- 双栈:双栈系统需要先拆分。
- 业务伙伴:客户和供应商主数据必须在转换之前转换为业务伙伴。被这一项卡住的团队比其他任何一项都多。
2. 选择路径并规划项目群
用 Readiness Check 的结果和我上面的原则来选择路径。然后在任何人开始构建之前,规划整个项目群,包括数据、测试和切换。
在我主导或挽救过的 21 个 SAP 项目群中,我看到的最大迁移错误,是在实施一开始没有好好规划迁移。在最初几周就决定谁负责数据清洗、淘汰哪些自定义代码、何时进行切换演练。这些决定做得越晚,代价越高。
3. 改造自定义代码
在 ABAP Test Cockpit 中运行 S/4HANA 检查,把您的代码与 SAP 的简化项进行对比。Custom Code Migration 应用会把同样的结果和使用数据一起显示,这样您在修改任何东西之前就能看到哪些代码在用。
目标是更少的 Z 代码,而不只是能运行的 Z 代码。在一个项目群中,借助 smartShift 的分析,我们把自定义对象从 18,000 个减少到 3,200 个。
您带过去的每一个自定义对象,都会给以后的每一次升级增加成本。我见过企业通过 Clean Core 原则把升级周期缩短 40%,我的 SAP Clean Core 指南介绍了如何对保留下来的部分进行分类。
4. 准备并迁移数据
在迁移任何内容之前,先分类、清洗和归档。这一步花的时间总是超过任何计划的预期,所以下面单独用一节来讲。
5. 测试、培训和切换
分轮进行测试:单元测试、集成测试和用户验收测试(UAT),然后至少做一次完整的切换演练。让关键用户和偶尔使用的用户都参加 UAT,因为他们会发现不同的问题。
演练不是可选项。它会暴露只有在整个流程跑一遍时才会出现的时间缺口、遗漏的校验和接口故障。跳过演练的团队,会在上线那个周末遇到这些问题。
迁移搬走的是数据。真正的问题是,您如何处理继承下来的设计决策。
根据我的经验,数据迁移占实施工作量的 30% 至 40%。它也是进度延误最常见的原因。
数据怎么迁移取决于路径。在棕地中,SUM 原地转换数据。在绿地中,您用 SAP S/4HANA Migration Cockpit 加载主数据和未清项;在选择性数据迁移中,由专门工具迁移您选定的范围。
无论哪条路径,迁移之前都要先给数据分类:
- 热数据:经常使用,日常处理需要。
- 温数据:偶尔访问,相关但不是每天都用。
- 冷数据:历史数据或不再使用的数据,只为审计保留。
冷数据不需要进入 S/4HANA。把它归档。重复的供应商记录、不一致的计量单位和只填了一半的客户主数据,每个 ECC 系统里都有,如果没有人先修正,它们会原封不动地进入 S/4HANA。
我合作过的一家客户,仅数据清洗和归档就花了五个月。我的文章为什么 SAP 数据迁移会失败对这一步讲得更深入。
以下是我在 ECC 到 S/4HANA 项目群中用过的五个工具。两个是 SAP 自己的,三个来自专业供应商:
| 工具 | 提供方 | 作用 | 适用阶段 |
|---|---|---|---|
| SAP Readiness Check for SAP S/4HANA | SAP | 报告简化项、附加组件兼容性、自定义代码影响、数据量和容量规划 | 选择路径之前 |
| Custom Code Migration 应用 | SAP | 运行 S/4HANA ABAP Test Cockpit 检查、并利用使用数据找出未使用代码的 SAP Fiori 应用;可在 S/4HANA 或 SAP BTP ABAP 环境中运行 | 自定义代码范围界定与改造 |
| smartShift | smartShift Technologies | 针对 S/4HANA 的 ABAP 自定义代码自动分析和转换 | 自定义代码分析与修复 |
| SNP(Kyano 平台) | SNP Group | 用于选择性数据迁移的数据转换软件,以 SNP 的“Bluefield”方法销售 | 选择性数据迁移、并购和剥离 |
| Natuvion | Natuvion Group | 用于 S/4HANA 转型的数据转换软件和切换工具 | 选择性数据迁移和切换 |
SNP 和 Natuvion 都是 SAP Selective Data Transition Engagement 社区的创始成员。您还会遇到的其他 SAP 工具,是用于棕地转换的 SUM,以及用于绿地数据加载的 Migration Cockpit。
工具代替不了决策。您这边仍然需要有人来确定淘汰什么。
对于增强包 6 至 8 的 SAP ERP 6.0,主流维护于 2027 年 12 月 31 日结束。可选的延长维护从 2028 年到 2030 年 12 月 31 日,在您现有维护基数上加收两个百分点(SAP News)。
2030 年之后只有一条狭窄的路,即 SAP ERP, private edition 过渡选项。它为在 RISE with SAP 下把 ECC 系统作为基于 SAP HANA 的 SAP ERP, private edition 迁入 SAP 私有云的客户,提供 2031 至 2033 年的维护。系统必须在 2030 年 12 月 31 日之前迁移,规模至少 2 TB,并且需要 SAP 的 max success plan。
所以 2033 年不是普遍适用的截止日期。它适用于已经把 ECC 迁入 SAP 云的大型系统。对其他所有人来说,运行在自有基础设施上的 ECC,2027 年是主流维护截止日期,2030 年是延长维护的终点。
- 2027ECC 主流维护结束12 月 31 日,适用于 SAP ERP 6.0 EHP 6 至 8
- 2028现在开始的话,可能的上线时间棕地 12 至 18 个月,绿地 18 至 24 个月
- 2030延长维护结束可选,加收两个百分点
- 2033过渡选项结束仅限 SAP ERP, private edition,2 TB 及以上的系统
来源: SAP News,2020 年 2 月和 2025 年 8 月
这笔账很简单。至少为一段时间的延长维护做好预算,并利用这段时间清洗数据、淘汰自定义代码,而不是干等。
成本和时间线由同样的因素决定:路径、自定义代码的数量、数据的状态,以及有多少实体上线。仅数据就占工作量的 30% 至 40%,这就是为什么一份干净的数据计划比任何费率谈判都更省钱。我的 S/4HANA 迁移成本指南讲解了推动迁移预算的因素,我的 SAP 实施成本指南按公司规模拆解了预算。
想看一个项目群的实际进展,请阅读我的 ECC 到 S/4HANA 迁移案例研究。想评估您自己的选项,可以试试绿地与棕地迁移评估。
本文是总览。下面每一篇指南完整回答一个问题。
- S/4HANA 迁移时间线与项目计划:逐阶段、按路径讲解,包括模拟转换和切换。
- S/4HANA 迁移成本:系统转换、新实施或选择性迁移的预算由什么驱动。
- SAP Readiness Check 与迁移评估:这项检查告诉您什么,又遗漏了什么。
- SAP S/4HANA Migration Cockpit 分步指南:用暂存表或直接传输加载数据。
- RISE with SAP:公有云与私有云:哪个版本适合您的流程。
- RISE with SAP 合同与定价:订阅涵盖什么,以及要谈判什么。
- 如何选择 S/4HANA 迁移合作伙伴:要问的问题和警告信号。
- SAP 项目挽救:如何挽救一个偏离轨道的迁移项目。
有两个工具可以帮您算清数字:SAP 实施成本计算器和数据迁移估算工具。
什么是 SAP ECC?
SAP ECC(SAP ERP Central Component)是 SAP ERP 6.0 的核心,属于 SAP Business Suite 7。它涵盖财务、管理会计、物流和其他核心流程,可在多种数据库上运行。SAP S/4HANA 是它的继任者,只在 SAP HANA 上运行。
ECC 到 S/4HANA 迁移需要多长时间?
根据我的经验,棕地转换需要 12 至 18 个月,绿地实施需要 18 至 24 个月,选择性数据迁移需要 12 至 18 个月。数据清洗是进度延误最常见的原因,因为数据迁移占实施工作量的 30% 至 40%。
2027 年之后 SAP ECC 会怎样?
对于增强包 6 至 8 的 SAP ERP 6.0,主流维护于 2027 年 12 月 31 日结束。您可以额外支付两个百分点,购买到 2030 年 12 月 31 日的可选延长维护。2031 至 2033 年的维护只能通过 SAP ERP, private edition 过渡选项获得,适用于在 2030 年底前迁入 SAP 私有云的大型系统。
棕地还是绿地:哪个更好?
一般而言,两者没有优劣之分。从其他系统迁移过来或需要定义新流程时,选绿地;流程已定义且运行良好时,选棕地。如果只有部分领域需要重新设计,可以考虑选择性数据迁移。
SAP 中的选择性数据迁移是什么?
选择性数据迁移把选定的公司代码、业务单元或某些时间段的数据迁移到 S/4HANA,而不是全部转换或从零开始。它让您可以重新设计部分领域,同时在其他领域保留历史数据。它需要专门的工具,例如 SNP 或 Natuvion 的工具,以及有经验的合作伙伴。
把 ECC 6.0 转换为 S/4HANA 有哪些前提条件?
任何增强包的 SAP ERP 6.0 都可以进行转换。系统必须是 Unicode,否则就采用两步方式;双栈系统必须先拆分。客户和供应商主数据必须在转换之前转换为业务伙伴。
SAP Readiness Check 能告诉您什么?
它分析您的 ECC 系统,报告影响您的简化项、附加组件兼容性、自定义代码影响、数据量和 HANA 容量规划。要尽早运行,因为团队经常发现一些自己都不知道在依赖的附加组件和自定义代码。
ECC 迁移应该选择 RISE with SAP 还是 GROW with SAP?
大多数自定义代码较多、流程复杂的 ECC 客户,会在 RISE with SAP 下迁移到 S/4HANA Cloud Private Edition,它支持对现有系统进行转换。GROW with SAP 使用 Public Edition,这是一种只采用标准流程和已发布 API 扩展的全新实施。它适合愿意采纳 SAP 标准的公司。
下一步
您现在正在推进ERP项目吗?
如果这篇文章谈到的正是您当前正在推进的项目,那么一次30分钟的交流,往往比再花一周做内部分析走得更远。




