The Custom Code Audit Most Teams Skip
The migration teams that get burned by technical debt almost never get burned by the big, obvious custom objects. They get burned by the ones nobody remembered to check.
A 2025 Horvath study found that 44 per cent of S/4HANA overruns trace back to technical debt: years of Z-transactions, custom pricing routines in SD, bolt-on reports in FI/CO, and interfaces that were never fully documented. What makes this dangerous is not that the debt exists. Every ECC system that has run for a decade or more has it. What makes it dangerous is that most teams do not inventory it properly before they commit to a go-live date, so it surfaces during realization or testing instead of during scoping, when there is still room to plan around it.
This is also where clean core stopped being a governance nicety and became something closer to a hard requirement. SAP’s own direction at Sapphire 2026, the Business AI Platform, the new AI Agent Hub, and the Autonomous Suite, all depend on agents that reason over standardized processes and a clean data model. Custom logic sitting on top of core objects does not just complicate a migration. It gives an AI agent an inconsistent picture of how the process actually runs, which is exactly the kind of ambiguity these agents are not built to handle well. Teams that treat clean core as a box to check for go-live are setting up a second remediation project later, once leadership wants Joule or agent-based automation actually working in production.
The pattern we keep seeing on real projects is a custom code inventory that starts too late and stays too shallow. Someone runs a usage report, counts objects, and calls it done. That misses the parts that matter: which Z-transactions are load-bearing for a business process versus which ones nobody has touched in three years, which custom pricing conditions in SD have logic baked in that the business team cannot fully explain anymore, and which FI/CO reports were built to work around a limitation that clean core extensibility actually solves natively now.
A few things consistently separate the teams that handle this well from the ones that get surprised by it.
They run the custom code inventory before scope is locked, not during realization, and they involve someone from the business side who actually uses the object, not just the technical owner. They classify every custom object into keep, retire, or re-platform to BTP extensibility, and they do it early enough that the decision shapes the project plan instead of getting made under deadline pressure in sprint twelve. They treat SD pricing logic and FI/CO custom reporting as their own workstream with its own owner, because these are consistently where “we’ll figure it out later” causes the most rework. And they price the remediation work as its own line item instead of folding it into general development capacity, because it is a different kind of work with a different skill profile.
None of this is about being a clean core purist for its own sake. It is about not building a system you will have to remediate twice, once to get to S/4HANA and again to get agentic AI to actually work on top of it. The teams doing this well right now are treating the custom code audit as a discovery deliverable with its own timeline and its own specialist, not a checklist item inside a broader workstream.
If there is one lesson from watching these projects up close, it is that the audit is cheap compared to what it prevents. The rework it prevents is not.