ERP 现代化与 SAP ECC 退役：迁移方案里没人估算的那部分工程
每个 ERP 迁移里都藏着两个项目。一个写在计划书上：新系统、流程设计、系统集成商。另一个在第四个月冒出来，那时候终于有人去数了一遍接口。
第二个项目归我们。八十个定制集成、财务离不开却没人认领的报表、连着某个数据库视图的仓库终端、直接读旧表的客户门户，还有二十年的数据要以新系统肯收的形状搬进去。这部分很少写进最初的范围，却经常是决定上线日期的那部分。
为什么现在被推上日程
SAP ECC 6.0 的主流维护于 2027 年 12 月 31 日结束。延长维护可以把企业带到 2030 年底，但要加钱，范围也缩水。装机量里有相当大一部分还没动工，而迁移通常要十八到三十六个月，能做这件事的合作伙伴和云厂商产能正在被预定。
同样的压力也存在于 SAP 之外。Oracle EBS 客户面对自己的支持终点，Dynamics AX 和 NAV 装机被推向 Business Central 和 Dynamics 365，还有一长串企业跑着十年前被大改过、而改它的人早已离职的 ERP。
贵司若在欧洲设有子公司或生产基地，同一份日历也适用于那里的 ERP。
无论终点是哪里，问题的形状都一样：ERP 不是孤岛，而挂在它上面的东西通常没有文档。
我们做什么
接口发现与清单
计划要能立起来，先得搞清楚到底有什么在跟 ERP 说话。我们用实证的办法做这件事（读数据库日志、网络流量、定时作业、集成中间件配置和源码），而不是发一份问卷然后祈祷。
产出是一份接口清单，逐条标明方向、协议、频率、数据量、能找到的话还有业务负责人，以及必须重建、可以下线还是可以改造的判断。客户发现的接口数量，经常是原先预估的二到五倍，其中相当一部分最后证明什么都没在服务。
重建集成层
必须存活的接口由我们重建，而且我们倾向于对着一层抽象重建，而不是直接指向新系统。在周边应用和 ERP 之间放一层集成层，意味着下一次迁移（一定会有下一次），不必把这套活再干一遍。它也让您可以分批把应用切过去，而不是压在一个割接周末上。
这里的工作跨 IDoc 与 BAPI 接口、OData 服务、上个时代留下的 SOAP 端点、至今仍撑着半个欧洲 B2B 的平面文件与 SFTP 交换、消息队列，以及新系统侧的现代 REST API。
数据迁移工程
抽取、清洗、转换、加载，以及通常被低估的那一步，对账。我们把迁移写成可重复运行的代码，而不是一次性脚本，这样它可以对着逐次变干净的数据跑几十遍，每次结果自动比对。
可信度就落在对账上。财务不会因为加载成功而签字，他们签字是因为余额对得上、笔数对得上，剩下的差异有解释并被书面接受。
比 ERP 活得更久的定制应用
多数企业在旧 ERP 周边建了一批应用，用来实现 ERP 做不了的事：配置器、报价工具、车间终端、客户门户，还有那张不知不觉变成承重结构的计划表格。有些应该退回到新系统的标准功能里；有些是真正的竞争优势，应当作为独立应用被认真重建，不再焊死在一套即将改变的数据库结构上。
我们帮您分清这两类，然后把值得留下的那些建好。
报表与影子数据
任何长寿的 ERP 周边都会长出一层报表、抽数和表格。它们会在割接时高声炸开，而且几乎从不在计划里。我们把它们盘点出来，识别业务真正靠它运转的那些，然后对着新数据模型重建，或者对着一层能把它们与数据模型隔开的报表层重建。
退役与数据留存
旧系统里存着法律要求在关机后仍需保留多年的记录。让 ECC 只读运行十年，是满足留存要求的一种昂贵方式。我们把数据抽取到可访问的归档中，配上审计师和税务机关实际会用到的检索与导出通路，这样旧系统才能真的关掉。
我们不做什么
我们不是 SAP 功能顾问。我们不配置 FI/CO，不设计流程模板，也不是运作 S/4HANA 项目的那个合作伙伴。那是专门的角色，您该找专门做这个的人。
我们是在那个合作伙伴旁边干活的工程团队，负责 ERP 触及、但 ERP 项目不覆盖的一切。实践中要么由客户直接聘用以守住自己这一侧，要么作为分包方配合主导项目的系统集成商。
如果您要找的是把整个 S/4HANA 转换扛下来的人，我们会告诉您我们不是，而且宁愿在第一次沟通就说，而不是第三次。
我们介入的场景
与 S/4HANA 项目并行：集成重建、数据迁移工程、周边应用改造，以及旧有资产的退役。
彻底迁出 SAP：迁往 Odoo、Dynamics 365 Business Central、ERPNext、Netsuite 或行业专用系统，常见于认为 S/4HANA 过重的中型企业。这类项目里，集成和数据工作占大头。
Oracle、Dynamics AX/NAV 与 Infor 资产，面对同样的生命周期压力，只是关注度更低。
决定暂不迁移的企业，眼下留在原地，需要把周边系统现代化、把接口做到可维护、在等待期内把风险降下来。
项目怎么推进
调研，三到六周。接口清单、数据质量评估、周边应用梳理，外加一份关于周边资产实际长什么样的书面报告。这一步刻意做成可以单独采购的服务，好几家客户拿它重新谈了系统集成商方案的范围和价格，省下的钱远超这笔投入。
开发，与主项目并行推进：集成层、迁移流水线、应用重建，按贵司排期和割接日期来。
割接支持，包括演练、对账运行，以及那些在测试中从未被真正跑透的接口终于被跑透的护航期。
退役，在新系统稳定、归档签收之后进行。
技术栈
应用侧用 Java、.NET、Python、Node.js 和 PHP；SAP 接口技术包括 IDoc、BAPI、RFC 和 OData；中间件包括 MuleSoft、Apache Camel、Kafka 和 Azure Integration Services；数据库涵盖 SQL Server、Oracle、DB2、HANA 和 PostgreSQL；云用 AWS 和 Azure。现有资产跑在更老的东西上（ERP 旁边的 Delphi、VB6、PowerBuilder、COBOL），对我们是熟悉的地形，不是意外。
常见问题
SAP ECC 的支持到底什么时候结束？
SAP ECC 6.0 的主流维护于 2027 年 12 月 31 日结束。延长维护可用至 2030 年底，需额外付费且范围缩减。具体条款请就贵司的增强包和合同直接向 SAP 确认，因为条件各不相同。
我们已经定了系统集成商，你们在哪个位置？
在他们旁边。集成商负责 ERP 转换，我们负责围绕它的资产，接口、数据工程、周边应用、报表和退役。这种分工很常见，能让集成商专注于他们擅长的系统，也确保那些通常掉在合同缝隙里的部分有人负责。
彻底迁出 SAP 现实吗？
对一部分企业来说现实。取决于业务中有多少是标准的、多少沉在定制里，以及更小的平台能否撑住贵司的业务量和监管要求。对中型制造和分销企业这是一个真实选项，对复杂的跨国集团则不是。调研阶段给的是判断依据，不是立场。
接口盘点要多久？
多数中型资产三到六周。主要受限于访问权限，我们能多快拿到日志、源码、中间件配置，以及找到还记得某个东西为什么存在的人。
关机之后，旧系统还能供审计查询吗？
可以。我们把数据抽取到可查询的归档中，满足贵司审计师和税务机关要求的留存期、检索与导出能力。这通常远比让一套持牌 ERP 只读运行十年便宜。
如果我们决定暂时不迁移呢？
这是一个正当的决定，尤其在延长维护可用到 2030 年的前提下。那么这段时间的工作就是降风险：把接口文档化并稳定下来、下线无人使用的东西、把 ERP 周边的应用现代化，这样等真正要动的时候，周边资产不会成为障碍。
开始行动
告诉我们贵司在跑什么、决策走到哪一步、是否已经定了集成商。我们会告诉您周边资产大概会让您付出多少，以及我们会从哪里下手。
联系我们，界定一次接口与数据调研的范围。