Ask a room of SAP architects whether clean core is a good idea and you will get unanimous agreement in under a second. Ask the same room what percentage of their production landscape actually complies and the answers get careful.
That gap is the whole subject. Clean core is not technically difficult. SAP BTP works. The extension patterns are documented and mature. The reason estates drift is not that anyone forgot how to build a side-by-side extension. It is that on a Thursday afternoon, with a plant idle and a controller escalating, the in-core enhancement takes two days and the clean one takes three weeks, and nobody in the room has the authority to choose three weeks.
Do that eleven times a year and the six percent growth rate takes care of itself.
What clean core actually commits you to
The principle is narrow: standard SAP functionality is used wherever it fits, and custom business logic runs alongside the core rather than inside it, on SAP BTP, communicating through released APIs and events.
The payoff is equally narrow and worth stating precisely. It is not elegance. It is that SAP's quarterly innovation cycle applies to your system without a regression scramble every time, because nothing you built is sitting inside the objects SAP is updating. Upgrades become routine rather than projects. That is the entire return, and it is substantial, because the alternative is an estate where every upgrade is a negotiation with your own history.
The patterns that deliver it are well established. Side-by-side extensions build custom functionality alongside S/4HANA using BTP services and APIs. API-first integration connects SAP and non-SAP systems through REST, OData, and event-driven architectures rather than point-to-point code. Custom UI extensions deliver Fiori apps and role-based interfaces on UI5 without touching standard applications. Data extension services add fields and business logic while preserving upgrade compatibility. Process automation extends standard workflows with SAP Build Process Automation, RPA, and rules-driven decisions. AI and ML augmentation adds intelligent document processing and predictive capability through BTP services.
The BTP ABAP Environment matters more than it gets credit for in mid-market conversations, because it lets an existing ABAP team build cloud-native, side-by-side extensions with the skills they already have. The most common objection to clean core is that it requires a workforce you do not employ. Frequently it does not.
The part that is genuinely hard
Not one of the above is the reason estates drift. Drift happens because clean core is a standing constraint on how your organization responds to urgency, and no architecture pattern enforces a constraint.
Three things have to exist in writing before go-live, and if they do not, the policy will not survive contact with the business.
A decision rule for what gets built where. Not a principle, a rule, specific enough that a developer can apply it without escalating. Configuration first. Then in-app extensibility where SAP provides it. Then side-by-side on BTP. Core modification only through a named exception. Without the rule, every request becomes a debate, and debates under time pressure resolve toward whatever is fastest.
A named owner with the standing to say no. Clean core fails when the person enforcing it reports to the person whose plant is idle. This is an organizational design question rather than a technical one, and it is usually solved by locating the authority in architecture governance with an escalation path to the CIO, not by exhortation.
A documented exception route. This is the one most policies omit, and its absence is what kills them. A rule with no exception path does not produce compliance. It produces quiet non-compliance, which is worse, because the modification still happens and now nobody has recorded it. A working policy says: exceptions are permitted, they require this approval, they carry a remediation date, and they appear on a register the steering committee reviews.
Measure the policy by whether the register is short and current, not by whether it is empty. An empty register on a real manufacturing estate means people stopped writing things down.
The honest costs
Clean core advocacy tends to skip the trade-offs, which makes it less persuasive to anyone who has built systems.
Side-by-side is slower to build. An extension that would have been a user exit is now a service with its own lifecycle, deployment pipeline, and monitoring. For simple requirements this is real overhead, and pretending otherwise damages the argument.
It introduces network boundaries. Logic that used to run in-process now runs across a call. That is a latency consideration and a failure mode consideration. For high-volume transactional paths it needs design attention rather than assumption.
It is more moving parts. BTP subaccounts, service instances, connectivity, identity propagation, and a separate operational surface to monitor. Organizations that have not budgeted for BTP operations discover this in month eight.
And it needs skills you may need to build. Existing ABAP capability transfers well, but the platform disciplines, CI/CD, API governance, service lifecycle management, are frequently new.
The correct response is not to abandon the principle. It is to apply it proportionately: rigorously on anything touching a core object SAP will update, pragmatically on peripheral functionality where the overhead exceeds the benefit. A policy that treats every requirement as equally sacred will be ignored within a year.
Migration is when this gets decided
The window for setting this up is the migration itself, for an unromantic reason: it is the only time anyone will fund a serious examination of what your custom code does.
In most manufacturing estates, forty to sixty percent of custom code turns out to be unused or replaceable with standard functionality. Objects serving processes that changed years ago. Enhancements duplicating something SAP now ships. Reports whose requester retired. The same review typically finds licence count can come down fifteen to twenty-five percent once inactive users and mis-sized types are cleaned.
None of that surfaces during business as usual. There is no budget line for auditing Z-code, no sponsor for it, and no reward for the person who does it. It happens during a migration or it does not happen.
This is also why the migration path decision and the clean-core decision are the same decision viewed from two angles. Brownfield preserves and refactors custom code. Selective cherry-picks what gets rebuilt. Greenfield replaces it clean. Choosing a path without having scored the code is choosing your clean-core posture by accident.
What to ask a partner
Four questions, and the quality of the answers is diagnostic.
"What is your written rule for what gets built where, and will it be in the SOW?" Clean core stated as a value is marketing. Clean core stated as a contractual commitment, with custom code re-platformed on BTP as a deliverable rather than an aspiration, is a different conversation.
"What is your target, and how will it be measured at go-live?" A hundred percent clean-core alignment is a reasonable target for a new build. Anything unmeasured is not a target.
"Who owns the exception register after you leave?" If the answer is your team and nobody has discussed who on your team, the policy has a twelve-month life expectancy.
"What did the code analysis find?" If they are recommending an approach before scoring your custom objects, they are recommending the approach they staff.
The number that tells you whether it worked
Not the count of extensions built. The time between SAP releasing an upgrade and your system taking it.
On a governed clean-core estate, upgrades are routine and quarterly innovation actually reaches your users. On a drifted one, each upgrade opens a regression project, the interval stretches, and within a few years you are running a version behind the capability you are paying for. That is the same position ECC customers are in today, arrived at by a different route and considerably faster.
Clean core is not about keeping the system tidy. It is about keeping the option to move.
If you take one thing into your next steering committee, make it the exception register. Not the architecture diagram and not the extension count. Whether exceptions get written down, reviewed, and remediated is the single best predictor of where your estate will be in three years.
Score Your Custom Code Before You Commit to a Path
A fixed-fee, two-week diagnostic for manufacturers planning S/4HANA, focused on what your custom code is actually doing and what clean core will cost you.
We'll deliver:
- A complete custom object inventory with complexity scoring, including what is unused or replaceable with standard functionality.
- A clean-core roadmap identifying which objects re-platform to BTP, which retire, and which need a documented exception.
- The extension architecture, mapped to the patterns that fit your requirements rather than a reference diagram.
- A realistic view of the BTP operating capability you will need, and what you already have.
Delivered by the principal architect who would run the program, contracted by name.
No sales drip. A board-ready plan in fourteen working days.
