一个运行了十几年甚至二十几年的 SAP 系统里，真正让升级项目变得棘手的，往往不是 SAP 标准功能，而是那些没人敢轻易碰的Z*程序、自建表、增强、出口、接口、批处理、ALV 报表以及直接读取 SAP 标准表的历史代码。
这些代码通常不是某一天突然变坏的。很多程序在 ECC 时代完全合理，业务部门也已经依赖多年。问题出现在技术环境改变之后。系统从 ECC 走向 SAP S/4HANA，从一次大版本升级转向更频繁的持续交付，从 SAP GUI 走向 SAP Fiori，从经典 ABAP 走向 ABAP Cloud，又开始引入 SAP BTP、RAP、CAP、Event Mesh、Joule 和各种 SAP Business AI 能力。原来只是一个开发团队内部维护的问题，逐渐变成企业架构层面的技术债务。
这种情况在当前 SAP 项目里非常常见。
一类系统属于典型的brownfield carry-over。ECC 里积累了大量经典 ABAP 程序，转换到 SAP S/4HANA 时，项目目标主要是把业务平稳搬过去，所以大量程序只做兼容性修改。程序能够继续跑，业务也没有中断，但架构思想基本还停留在 ECC 年代。
另一类情况更有意思，项目明明是新实施的 SAP S/4HANA，技术上却依然按照过去的方法开发。开发团队熟悉 SE38、SE80、SE11、BAdI、User Exit、Function Module 和直接表访问，却还没有系统掌握 ABAP Cloud、RAP、Key User Extensibility、released API 以及 SAP BTP，于是一个新系统最终长出了和旧 ECC 十分类似的扩展体系。
这样的系统并
