Every SAP migration conversation starts the same way. The slides show a clean before-and-after. ECC on the left (slow, rigid, expensive). S/4HANA on the right (fast, intelligent, cloud-ready). The migration timeline looks achievable. The business case looks solid. The pre-sales team is confident. Then the discovery phase begins. And someone finally looks at the custom code.
The Number Nobody Puts in the Business Case
The average SAP ECC system carries approximately 22,000 custom objects and 2.7 million lines of executable custom code.
Up to 80% of the entire ECC code base in many environments consists of individual extensions including Z-programs, customer-specific modifications, bespoke reports, workarounds built to compensate for processes that were never properly designed in the first place.
Of that custom code, up to 40% is either unused or redundant. Nobody uses it. Nobody knows why it was built. The people who built it left years ago. And yet, it all has to be assessed, triaged, and resolved before a migration can complete safely.
A thorough remediation cycle from discovery, triage, rewrite, regression testing, and to integration validation takes six to twelve months for a mid-to-large ECC landscape. This is the number that almost never appears in the original business case.
Why Custom Code Becomes the Migration Anchor
There are three things that slow an ECC-to-S/4HANA migration to a halt. Data quality is one. Process redesign is another. Custom code is the third (this is one most frequently underestimated).
Here is why.
Custom code in ECC was often built to compensate for broken or missing processes. The standard SAP functionality did not match how the business actually worked, so developers back then had built workarounds. Those workarounds accumulated over years, became load-bearing, and are now embedded in critical business flows that nobody fully understands.
Things most teams discover mid-migration:
- The custom code touches decommissioned SAP objects that no longer exist in S/4HANA
- The underlying business process code that was compensating for the workarounds was never documented
- Regression testing reveals dependencies that nobody knew existed
- The remediation timeline extends by months — and so does the go-live date
What the Qube Way builds in from the start:
- Process mining on real event logs to identify what the code is actually doing in practice
- A triage decision on each custom object: remediate, replace with standard SAP functionality, or retire
- Migration in structured waves, each scoped as a Qube with its own outcome and success metric
- Regression testing built into every wave, not left until the end
- Custom logic rebuilt as cloud-native extensions on SAP BTP compliant with Clean Core, not carrying forward the debt
The difference is not technical capability. It is sequencing. Process before platform. Always.
The Clean Core Opportunity Most Migrations Miss
SAP’s 2026 guidance is clear: custom logic built going forward should live on SAP BTP as cloud-native extensions that consume S/4HANA APIs and not as modifications to the core.
This is not just a technical recommendation. It is a strategic reset, making life easier going forward.
A migration that goes through proper custom code triage is an opportunity to retire 30 years of accumulated workarounds and rebuild the system around how the business actually wants to operate, not how it was forced to operate when the process was broken and a developer patched over the gap.
Add a Comment