How much custom code can you retire moving from ECC to S/4HANA?
Custom code is the famous migration problem. Much of it doesn't need converting — it needs deleting.
The short answer
More than most teams expect — often a third to a half of the custom estate — because a large share of custom ABAP either re-implements capability S/4HANA now delivers as standard or is simply dead and unused. On a reference estate (a live ECC system, not a specific customer's result), an evidence-weighted read found that 44% of custom objects were retirement or standardization candidates. The key is reading the business rule inside the code, not just its syntax: an MV45AFZZ exit that enforces a static credit limit is a credit-check policy that S/4HANA FSCM performs as standard, so you retire the exit instead of converting it. Every object you retire with a documented reason is testing you never run and license and maintenance cost you stop carrying.
Why the number is bigger than teams assume
Two decades of ECC customization accumulate for reasons that no longer hold. Some custom objects were built to fill gaps that standard SAP has since closed. Others were written once, used briefly, and forgotten — dead code that still shows up in an inventory but never executes. When you measure both, the retirement pool is large: on the reference estate, 188 of 229 configured SD order types were dead or unused, and 44% of custom objects were candidates to retire or standardize.
This matters because the migration conversation usually fixates on converting custom code to run on S/4HANA. Converting code you should be deleting is the most expensive mistake in the program — you pay to migrate it, then pay to test it, then carry it for another decade.
Read the business rule, not the syntax
A code-conversion tool translates ABAP into ABAP — it makes custom code run on S/4HANA and leaves you with all of it. The higher-value move is to work out what each object is for and whether S/4 already does it. The canonical example is MV45AFZZ, a classic sales-order user exit. If it enforces a static credit limit at order save, it is not really code — it is a credit policy, and S/4HANA FSCM (credit management) does exactly that as standard. So you retire the exit and adopt the standard capability.
That chain — custom object to business rule to standard S/4 capability to a retire decision — is the difference between a cheaper migration and a genuinely simpler business.
What retiring actually saves
Retirement compounds. Every retired object is regression testing you never write, an upgrade dependency you never carry, and, often, a license or add-on you stop paying for. It also raises your clean-core posture, which lowers the cost and risk of every future S/4HANA upgrade. The saving is not a one-time migration discount; it is a lower operating cost for the life of the system.
What you should keep
Retirement is not an ideology. The custom code that encodes genuine competitive differentiation — the process that is actually yours — should be kept, but re-platformed onto released extension points rather than left as a core modification. The goal is a clean standard core plus a small, governed set of extensions that matter, not zero customization.
Frequently asked
Isn't retiring custom code risky?
The risk is in retiring blind. When each retire decision is backed by evidence — the object's usage, the business rule it encodes, and the standard S/4 capability that replaces it — retirement is lower-risk than carrying unexamined code forward, because you remove things you have proven you do not need.
How do you know it is safe to retire a specific object?
By reading the rule it implements and confirming S/4HANA delivers that capability as standard, plus checking real usage. The honest version of this also measures a false-positive rate against human-validated dispositions — a bad retire recommendation is the costly one, so the evidence must be strong before an object is marked retire.
Doesn't code conversion already handle this?
No. Code conversion makes custom code run on S/4HANA; it does not ask whether the code should exist. Retirement analysis is a separate, business-logic step that decides what to convert, standardize, or delete before conversion begins.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading