What is a clean core strategy for S/4HANA, and how do you achieve one?
Keep the standard core standard, move real extensions to a governed layer, and upgrades stop hurting.
The short answer
A clean core strategy keeps the standard S/4HANA system standard and moves the extensions you genuinely need to a governed, upgrade-safe layer instead of modifying the core. The payoff is cheaper, faster upgrades, lower risk, and quicker adoption of new SAP capability. You achieve it in three moves: measure how far your estate is from clean (a Clean Core Score), retire or standardize the large share of custom code that duplicates standard capability, and re-platform the extensions worth keeping onto released APIs and extension points — side-by-side on SAP BTP, in-app with released enhancements, or with key-user tools. Clean core does not mean zero customization; it means customization that survives the next upgrade.
What clean core actually means
Clean core is SAP's principle for building on S/4HANA without breaking upgradeability. Instead of modifying standard objects or hard-wiring logic into the core, you extend through released, versioned extension points, and you keep custom data and processes cleanly separated from the standard system. A clean core is not an aesthetic preference — it is what lets you take SAP's continuous updates without a re-testing marathon each time.
Why it matters: upgrade cost, risk, and innovation speed
Every core modification is a tax you pay at every upgrade: it must be re-checked, re-tested, and often re-worked. A messy core is why some ECC customers dread upgrades. A clean core inverts that — upgrades become routine, new SAP capabilities become adoptable quickly, and your team spends its time on the extensions that differentiate the business rather than on regression-testing modifications nobody remembers the reason for.
The three tiers of extension
Clean core routes each real extension to the least invasive layer that works:
- In-app extensibility — released enhancement points and key-user tools for changes that live inside S/4HANA.
- Side-by-side on SAP BTP — separate services that call S/4 through released APIs, for larger or cross-system logic.
- Released BAdIs and the condition technique — for the classic functional extensions (pricing, output, credit) that used to be user exits.
How to get there from a messy ECC estate
The path from a heavily-customized ECC system to a clean S/4HANA core is: measure, retire, re-platform. Measure the distance with a Clean Core Score so you have a baseline and a target. Retire the custom code that duplicates standard — often a third to a half of the estate. Then re-platform the extensions worth keeping onto released extension points. Doing this before or during the migration is far cheaper than carrying modifications across and cleaning up later.
Frequently asked
Does clean core mean no customization at all?
No. It means no modifications to the standard core. You can and should extend S/4HANA for genuine business needs — but through released, upgrade-safe extension points (in-app, BTP side-by-side, released BAdIs), so your extensions survive SAP's updates.
Is a clean core mandatory for S/4HANA?
It is not strictly mandatory, but it is strongly incentivized: cloud editions constrain core modifications, and the cost of upgrades scales with how dirty your core is. A clean core is the difference between routine upgrades and painful ones.
Where do I start on clean core?
Start by measuring the distance — a Clean Core Score baselines how far your estate is from standard. Then retire the custom code that duplicates standard capability, and re-platform the extensions worth keeping. Measure, retire, re-platform.
See your own Clean Core Score.
Run the free S/4 readiness scan in under a minute — no system access required.
Keep reading