SAP ECC 维护于 2027 年 12 月 31 日结束：是价格上调，不是停机

服务器机房里插着蓝色跳线的网络机架

2027 年 12 月 31 日，SAP 将结束对 SAP ECC 6.0 以及 SAP Business Suite 7 其他核心应用的主流维护。2028 年 1 月 1 日，什么都不会被关掉。您的系统会继续运行，用户会继续过账发票，SAP 也仍然会向您出售支持服务。变化的是您为此支付多少钱，以及能得到什么。

这个区别很重要，因为流传中的很多建议把 2027 年当作悬崖。对仍在使用 ECC 的大多数公司来说，它并不是，而他们也清楚这一点：剩下的 ECC 用户中，最大的一群正在按 2030 年做规划。真正的风险是另一回事。真正决定日期的那些工作（自定义 ABAP、接口、数据）范围界定得太晚，结果 2030 年变得和 2027 年一样紧。

本文写给中型公司的 CIO 和 SAP 负责人，他们大多身处德语区市场，仍在运行 ECC，必须决定接下来三年怎么走。

SAP 实际承诺了什么

条款见 SAP 的维护策略页面，最早于 2020 年 2 月公布：

到 2027 年 12 月 31 日为止：对 Business Suite 7 核心应用（包括 SAP ERP 6.0）的主流维护，适用于最新的三个增强包。如果您的系统处于更早的增强包上，在以 2027 年这个日期制定计划之前，先查看 SAP Note 2881788（该页面上有链接）。
2028 年 1 月 1 日至 2030 年 12 月 31 日：可选的延长维护，费用为“在维护基数上加收两个百分点的溢价”。简单地说，您现在支付的维护费率会上调两个百分点。
如果您不选择延长维护：您会自动转入客户特定维护。它涵盖什么，见同一页面上链接的 SAP Note 52505。在假定它足够之前，先读一读。
对于 S/4HANA：SAP 已承诺提供维护至 2040 年底。

对于一个更小的群体，还有另一条路。SAP 在 2025 年 8 月公布了 SAP ERP, private edition 过渡选项：一种有期限的订阅，让 ECC 在 SAP 私有云中从 2031 年运行到 2033 年。条件很严格。“系统必须在 2030 年 12 月 31 日之前迁移到基于 SAP HANA 的 SAP ERP, private edition。”HANA 是唯一受支持的数据库，该选项只能与 2031 年至 2033 年的 max success plan 一起提供，而且 SAP 规定按此选项订阅的系统最低为 2 TB。SAP 表示，它面向的是“我们规模最大、最复杂的 SAP ERP 客户”。SAP 提供的“商业上等同的条款”，适用于在 2025 年底之前承诺采用 private edition 的客户。

无论选择哪个级别，都要以书面形式向 SAP 和您的实施伙伴提一个问题：哪些法规变更（税务、薪资、电子发票格式）仍然会进入您的 ECC 系统，持续到什么时候。对一家德国公司来说，光是这个答案就可能决定原地不动是否可行。

市场上其他公司在做什么

德语区 SAP 用户组 DSAG 在 2025 年 12 月 8 日至 2026 年 1 月 21 日期间，对 198 名受访者开展了《2026 年投资报告》调查。其中 54% 仍在运行 ECC 或更早的 Business Suite，而 2024 年这一比例为 68%。

在时间安排上，将近一半的受访者计划在 2030 年底之前切换到 S/4HANA，DSAG 指出，这意味着要为延长维护付费。另有 37% 希望在 2027 年底之前切换，只有 4% 瞄准 2033 年和 private edition 过渡选项。

DSAG 主席 Jens Hungershausen 直言了原因：技能短缺、并行的转型项目和有限的预算正在把时间表往后推，“即使这会导致更高的维护成本”。

公共采购方也在行动。我们自己对欧盟公共招标公告的统计显示，2025 年和 2026 年每半年大约有 200 个 S/4HANA 迁移采购程序，到 10 月初，2026 年已超过 300 个，其中大部分在德国。工作正在进行，只是铺开在一条比 2027 年的新闻标题所暗示的更长的跑道上。

工作真正在哪里

从 ECC 到 S/4HANA 的技术转换，SAP 及其合作伙伴有完善的工具支持。如果您运行的是一套轻度定制的 ECC，只有少数几个标准接口，那么您的集成商已经做过很多次，下面的大部分内容都不是您的问题。

您自己构建的东西越多，它就越是您的问题。

自定义 ABAP：项目延误的地方

S/4HANA 不是换了新数据库的 ECC。数据模型的一部分变了。客户和供应商变成了业务伙伴。财务和库存过账被合并到了更少、更宽的表中。一些事务和功能被删除或替换。

直接读表、依赖已经移动的出口（exit），或者默认某种排序顺序的自定义代码（除非查询明确要求，HANA 不保证顺序），可能通过语法检查，却依然做错事。最后这一类最伤人，因为它会在集成测试中或上线之后才暴露，而不是在代码扫描时。

行之有效的流程是：

先测量使用情况。 在生产系统中开启使用日志（ABAP 调用监视器，事务 SCMON），并让它持续运行到完成一次完整的年终结账。在长期运行的系统中，相当一部分自定义对象往往从未运行过。没人执行的代码直接删除，不做迁移。
对剩下的代码运行分析工具。 SAP 的检查会找出可能的问题。它们无法告诉您哪些问题对业务真正重要。
对每个对象分类。 停用、用标准功能替换、原地修复，或者在核心之外重建。每个对象一个决定，并指定一名业务负责人。
按流程测试，而不是按对象测试。 改代码是便宜的部分。证明从订单到收款和月末结账仍然得出相同的数字，才是昂贵的部分。

项目在这里延误的原因很无聊：没人足够早地清点。自定义代码的数量只是大概知道，写代码的人往往已经离开，而真正的发现要到第二轮测试才出现，那时日期已经在内部公布了。

接口，以及在同一时钟上的 PI/PO

ECC 很少孤立存在。发往仓库的 IDoc、来自车间的 RFC 和 BAPI 调用、发给银行和税务顾问的平面文件、读取某人在 2011 年创建的数据库视图的客户门户。它们每一个都必须被找出来、测试，有些还要重建。

如果这些接口通过 SAP Process Integration 或 Process Orchestration 运行，那么在同样的日期上还有第二个期限。SAP 的架构中心说，PI/PO 即将迎来“2027 年标准维护的结束”，客户可以把维护延长到 2030 年，此后 SAP 的支持即告结束。SAP 把 PI/PO 客户引向 SAP Integration Suite，后者附带迁移评估和向导式的迁移工具。

这些工具对标准对象有帮助。它们不会告诉您哪些接口仍在为某些东西服务，而自定义的映射逻辑仍然需要有人去读。从中间件配置、日志和计划任务中构建清单，而不是靠问卷。然后把 ERP 迁移和中间件迁移放在一起规划。如果一个接一个地做，每个接口都要测试两遍。

数据迁移

在系统转换中，您的数据随系统一起迁移，数据质量也一样。业务伙伴转换通常是第一个冲突点：重复的客户、同时也是客户的供应商、写在自由文本字段里的地址、放错位置的税号。所有这些都必须在转换之前清理，而不是在转换过程中。

在全新实施中，您要抽取、清洗、转换和加载，而难点在于对账。财务部门签字确认的依据是余额和未清项一致，而不是加载任务跑完。把迁移构建成可重复执行的代码，能针对越来越干净的数据运行十几次，每次运行都自动比对结果。

无论走哪条路，先把不再需要的数据归档。数据越少，转换运行时间越短，停机窗口也越短。

干净核心扩展

在一个由截止日期驱动的项目中，诱惑在于把所有修改都带过去，并承诺以后再整理。以后永远不会来。

SAP 给替代方案起的名字叫干净核心（clean core）：不修改标准系统，基于 SAP 发布并保持稳定的接口构建扩展，要么在 S/4HANA 内部，要么在旁边的 SAP Business Technology Platform 上。不是所有东西在第一天就能做到干净。您真正能守住的规则更简单：任何新东西都不再用老办法构建。现在避免的每一处修改，都是今后每次升级时不必重新测试的一处。

决策框架

现实的路径有三条，还有一条较少受到关注的第四条。

在 2027 年 12 月 31 日之前在 S/4HANA 上线。 这适合已经启动、运行着基本标准的系统并已约好实施伙伴的公司。从今天算起是十五个月，而很少有财务团队会接受在年终结账期间切换。如果您的自定义代码分析还没做，这大概不是您的路。

支付延长维护费用，在 2030 年之前上线。 这是市场上大多数公司的方向。代价是两个百分点的溢价；如果您在这一期间中途上线，请与 SAP 确认溢价如何计算。风险在于像当初对待 2027 年那样对待 2030 年：一直觉得很远，直到突然不再遥远。

采用 private edition 过渡选项，延续到 2033 年。 这意味着一份 RISE with SAP 合同、HANA、在 2030 年 12 月 31 日之前把系统迁移到 SAP ERP, private edition、max success plan 以及 2 TB 的最低要求。对一家中型公司来说，这很少是争取时间最便宜的方式。

离开 SAP。 对一些中型制造商和分销商来说，一套更小的 ERP 是真正的选项。接口和数据的工作量不会缩小，反而会成为项目的主体。

接下来六个月，无论您选哪条路

从现在到 2027 年 3 月底，以下这些在每条路上都会有回报：

确认您的起点。 增强包、数据库、维护合同。以书面形式向您的 SAP 客户团队索取适用于您的延长维护条款。
现在就开启使用日志，让它覆盖 2026 年的年终结账。
进行自定义代码分析，得出一个数字，而不是一个印象：有多少对象，多少在使用，多少触及数据模型中已变化的部分。
构建接口清单，包括所有通过 PI/PO 运行的接口，每个接口都有负责人和决定。
开始主数据清洗，先从客户和供应商开始。
停止新增修改。 从今天起，新开发遵循干净核心。
把 2028 年的维护费上调列入 2027 年预算，作为已知成本，而不是意外。
预订资源：实施伙伴、您内部的 SAP 团队，以及负责 SAP 周边系统的开发人员。技能短缺正是 DSAG 成员给出的时间表延误原因之一。

从 2030 年上线倒推：2030 年做测试周期和切换演练，2029 年开发和修复，2028 年设计和数据清洗，现在做分析。这里面的余量，比看上去要少。

从哪里获得帮助

我们不是 SAP 功能咨询公司，也不做 S/4HANA 转换；我们与负责转换的合作伙伴并肩工作，负责接口清单和重建、数据迁移代码及其对账，以及围绕 ECC 构建、必须在迁移后继续存活的应用。这些工作在我们的 ERP 现代化页面上有介绍，而遗留系统维护则覆盖在您迁移之前原地保留的系统。如果您希望在签下一个项目之前，先把 ERP 周边的系统盘点清楚，请写信到 office@c9group.dev。