How do you decide whether to retire, re-implement, or keep custom ABAP in an ECC to S/4HANA migration?
Usage first, standard second, rebuild last: a decision order that keeps the clean core promise.
The short answer
Decide object by object using three questions in order: is it used, does standard S/4HANA now do the same job, and if neither, can it be rebuilt on a released extension point. Unused code is retired. Code whose business rule is now covered by standard capability is retired after the rule is confirmed and mapped to configuration. Only what remains, the logic that genuinely differentiates the business, is re-implemented on released APIs, in-app extensibility, or side-by-side on SAP BTP, and a small remainder is kept as-is with a documented reason. Running the questions in that order matters, because most of the cost savings come from the first two answers, before anyone writes a line of new code.
Why decide object by object instead of by project
A mature ECC system carries thousands of custom objects, and they are not equal. Some run every night, some ran once for a 2011 data fix, and some encode a rule that standard SAP now handles natively. Treating the estate as one lump, either 'migrate it all' or 'rewrite it all', is the most common way budgets overrun, because you pay to convert, test, and re-platform code that should not exist.
A per-object decision turns an open-ended remediation project into a bounded list with a disposition on each line: retire, retire-to-standard, re-implement, or keep.
Question 1: is it actually used?
Usage evidence comes from the system, not from interviews. Usage statistics such as the Usage and Procedure Logging data and ABAP call-graph analysis show which custom programs, function modules, and enhancements executed over a meaningful window, ideally a full fiscal year so that year-end and quarter-end jobs are not missed.
Objects with no execution and no inbound reference are retirement candidates. They still get a quick sanity check with the process owner, but the burden of proof sits with keeping them, not deleting them.
Question 2: does standard S/4HANA now do this?
Many custom objects exist because ECC could not do something that S/4HANA now can. Credit checks hard-coded in a sales order user exit may be covered by credit management, custom output logic by the output management framework, and bespoke partner handling by Business Partner. The work here is to read the business rule inside the code, confirm that standard reproduces the outcome, and map it to configuration.
This is where fit-to-standard earns its keep. The decision is made in a workshop against the standard process, not in a developer's head, and the retired code is replaced by configuration that a change board can review.
- Retire to standard: the rule is covered, so the code goes and a configuration change takes its place.
- Partial coverage: standard handles most of it, and only the residual delta is carried forward as a small extension.
- No coverage: the object proceeds to Question 3.
Question 3: can it be rebuilt on a released extension point?
What survives the first two questions is the logic that is specific to how your company operates. Route each item to the least invasive layer that works: key-user and in-app extensibility for changes inside S/4HANA, released BAdIs and enhancement points for classic functional hooks, and side-by-side services on SAP BTP for cross-system or heavier logic.
Anything that cannot be moved to a released extension point is kept deliberately, with an owner, a reason, and a review date. 'Kept' should be a short list that someone is accountable for, not a default.
What the numbers look like in practice
Retirement share varies a great deal by estate and by industry, so no benchmark should be applied to your system. As an illustration only: in our reference estate, a live ECC system, analysis of 356 custom objects found that 44% could be retired. That figure belongs to that reference estate. A customer's numbers come from their own system, and the point of running the analysis first is to get that number before committing to a remediation budget.
Frequently asked
How long should the usage window be?
At least one full fiscal year, so that year-end close, annual reports, and seasonal jobs show up. A shorter window will misclassify rarely run but business-critical objects as unused, which is the costly kind of mistake.
Who signs off on retiring a custom object?
The business process owner confirms the rule is covered or no longer needed, and the architecture or change board approves the disposition. The analysis proposes; people with accountability decide. Evidence from usage data and the mapped standard capability should accompany every retirement.
Should we do this before or during the migration project?
Before, or at the very start. Retiring and mapping code ahead of conversion shrinks the scope that has to be converted and tested. Carrying everything across and cleaning up later means paying for the work twice, and it weakens the case for a clean core.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading