Clean core is the most repeated and least understood idea in conversations about S/4HANA. It tends to be presented as a moral rule — “do not modify the standard” — and received as what it has always been in practice: a recommendation the project abandons at the first requirement the standard does not meet.

It is worth changing the framing. Clean core is not about purity: it is a choice about where to put your difference. Every company needs things the standard does not do. The question is whether they will live inside the core, where they will fight with every update for the next ten years, or alongside it, connected through defined points the vendor commits to maintaining.

Why this matters now, and did not before

For many years, modifying the core was expensive but manageable: the company did an upgrade every four or five years, engaged a project, adjusted the modifications and carried on.

Two things changed. The first is cadence: in the cloud, updating stopped being an event and became a routine — what used to be a four-yearly project is now something that happens frequently, and every modification to the core turns into recurring friction. The second is that the cost moved: it used to appear in an upgrade budget, and now it appears diluted across maintenance, regression testing and deferred updates — an expense nobody can point to, but everybody pays.

There is a side effect that shows up early: those with a modified core defer updates. And those who defer updates do not receive what comes in them — including legal adaptations and the new features that justified the move to S/4 in the first place.

The four layers of clean core

Talking about “clean core” in the singular is confusing, because there are four different disciplines, with different difficulty and different returns.

Code. No modification of the standard and no direct reading of tables. Extension happens through the points provided for it and data access goes through a released interface, which carries a compatibility commitment. It is the most visible layer and the one the technical team understands first.

Data. A clean core is also a core that does not carry what it does not need. Endless history in the hot database drives up licence costs, makes updates slower and testing more expensive. It is the same conversation as archiving and data volume.

Integrations. An external system that reads ERP tables or writes straight to the database creates an invisible coupling that breaks on update — and breaks without warning, because nobody recorded that dependency. A clean integration goes through a published, versioned interface.

Processes. The most uncomfortable layer. Part of what gets customised exists because the company’s process was designed around a limitation that no longer applies. Revisiting the process sometimes eliminates the customisation altogether — and that conversation belongs to the business, not to IT.

How to get there without stopping the company

Nobody migrates to clean core in one leap. The path that works has six steps, and the order matters more than the speed.

1. Inventory what exists. Modifications, extensions, developments and integrations, with usage data alongside. Without that, everything else is just talk. It is the work we described in WRICEF inventory with AI.
2. Cut by usage. Whatever nobody runs does not need to be converted into anything — it needs retirement. It is usually the biggest scope reduction available.
3. Ask whether the standard already solves it. A great deal of old customisation exists because, at the time, the standard did not meet the need. Much of it is covered today. Checking before rewriting avoids rewriting for nothing.
4. Classify what is left by difficulty. An extension that fits within the assisted configuration tools is one thing; an extension that requires development alongside the core is another; and anything that only works by modifying the standard needs a conscious decision, with a deadline for its removal.
5. Move in waves, with measurement. One area at a time, with an indicator before and after: how many modifications remain, how many integrations now use a published interface, how long the regression test takes.
6. Close the door. The part almost every project forgets. Without an architecture rule and without someone applying it when each new request is approved, the core goes dirty again within two years — and the clean-up will have been spending with no legacy.

How to tell whether it is working

Clean core needs indicators, or it turns into rhetoric. Four measures say almost everything:

• Modifications to the standard that still exist, and the process each one serves.
• Objects that read tables directly instead of using a released interface.
• Integrations outside the published standard — the ones that will break without warning.
• Time and cost of the regression test at each update. This is the honest indicator: if clean core is progressing, this number falls.

The last is the most useful precisely because it is the hardest to dress up. A clean core translates into an update that goes through with fewer people and fewer late nights.

What changes when the core is clean

Updating stops being a project. That is the whole promise: receiving improvements and legal adaptations at the vendor’s cadence, without negotiating an internal deadline every time.

The cost becomes visible. The difference now lives in identifiable components, with their own owner and life cycle, rather than diluted inside the core where nobody can measure it.

The company gets back the option to change. A process that lives outside the core can be altered without touching the ERP — and that flexibility is the business argument that sustains the investment, far more than any technical conversation.

The honest limit: clean core is not free and is not won in one go. It demands architectural decisions, discipline in approvals and a willingness to revisit processes — three things that depend on people, not on tools. What technology does is show the size of the problem and reduce the cost of each step.

If your conversion is still being designed, the decision on approach comes first: the guide to brownfield, greenfield and bluefield at Inove Academy shows what each path demands — and the selective approach is precisely the one that lets you reach S/4 with a core already cleaner than it was. For the data side of that same decision, see master data cleansing.