"Clean core is an S/4HANA system where the application core has not been directly modified: no altered SAP tables, no overridden standard programs, no unpublished internal objects called from custom code."
— The working definition every SAP team should agree on first
Here is the number that turns clean core from an architecture ideal into a board-level priority: enterprises running a clean core report 25 to 35% lower annual application maintenance costs, and they activate new SAP features on day one instead of spending 3 to 6 months validating each update on a heavily modified system. But cost and speed are no longer the main reason to do this. Clean core is now the prerequisite for the autonomous enterprise, because AI agents can only act safely on a system whose interfaces are stable, whose data is governed, and whose processes are standard. This is a practical, step-by-step guide to actually delivering one.
What "Clean Core" Really Means (and What It Does Not)
Start by killing the most common misconception: clean core does not mean "no customization." It means no modification of the standard core. Concretely, a clean-core S/4HANA system has no manually altered SAP tables, no overridden standard programs, and no custom code calling unpublished internal objects. Every extension instead runs through officially published, stable APIs documented in the SAP Business Accelerator Hub. You can still extend heavily; you just do it in a way that survives every upgrade untouched.
SAP frames clean core across several dimensions, commonly described as five: processes (follow SAP standard, justify deviations), extensions (only via published APIs through ABAP Cloud or BTP), data (formal governance and continuous quality), integrations (published APIs such as OData via the Integration Suite, never direct database access), and operations (automated transport control, regression testing, and governance KPIs). Getting all five right is what makes the core genuinely clean, not just the code dimension everyone fixates on.
Remember This
Clean core is a discipline, not a one-time cleanup. The goal is a system where you can extend freely around the core through released APIs, so that SAP can upgrade the core beneath you without breaking anything you built. Customize all you want, just never touch the engine.
Know Your Grade: The A-B-C-D Level Model
In August 2025 SAP formalized a maturity model that replaced the older three-tier approach. It grades a system, or an individual extension, on how upgrade-safe it is. Knowing your current grade is the honest starting point of any delivery plan.
| Level | What It Means |
|---|---|
| Level A | Full compliance. The core stays standard; all innovation runs outside it via ABAP Cloud or BTP using released interfaces. The target state. |
| Level B | Partial compliance. Extensions moved to BTP but some legacy calls remain. Acceptable, notably in private cloud, as a transitional state. |
| Level C | Rationalization in progress. Some cleanup done, but legacy code persists and carries upgrade risk. |
| Level D | Non-compliant. Accumulated, unmanaged customizations including direct core modifications. Upgrades are effectively blocked. |
Most organizations coming off a heavily customized ECC or older S/4HANA system start at C or D. The delivery goal is not necessarily 100% Level A overnight, especially in private cloud where Level B is a pragmatic waypoint, but every step toward A buys upgrade stability and, as we will see, AI-readiness. The choice between public and private cloud shapes how strictly this is enforced, a distinction we unpacked in our guide to private vs. public cloud delivery and consultant skills.
The Delivery Playbook: Five Steps
Delivering clean core follows a consistent, repeatable methodology. Here is the sequence that works in practice.
- Audit the custom code (roughly 3 to 4 weeks). Run a full inventory of custom objects using the SAP Custom Code Migration App (a Fiori app in the BTP catalogue) alongside SAP Readiness Check. These tools scan your unreleased ABAP objects, classify them by risk, and recommend a path for each.
- Classify and decide. Sort every object into three buckets: retire (dead code nobody uses anymore, and there is always more than you expect), remediate to ABAP Cloud (keep it in-stack but rebuild it on released APIs), or migrate to BTP (move complex logic outside the core as a side-by-side extension).
- Build and migrate. Rebuild retained logic the clean way: in-app extensions via ABAP Cloud for close-to-core needs, or side-by-side extensions on SAP BTP (using the CAP framework, SAP Build, or the Integration Suite) for independent subsystems. Low-code key-user extensibility handles the simplest business-configurable changes.
- Regression test. Validate that the remediated and rebuilt logic behaves identically to what it replaced. This is where the day-one-upgrade payoff is earned or lost.
- Govern continuously. Stand up long-term governance so new technical debt never re-enters: define exactly when teams may use key-user, developer, or side-by-side extensibility, and monitor compliance with SAP Cloud ALM dashboards that flag clean-core violations and API-consumption problems before they become upgrade blockers.
Step five is the one organizations skip and then regret. Clean core delivered once and left ungoverned drifts straight back toward Level D. The tooling makes governance far easier than it used to be, and AI is now part of the toolkit: Joule for Developers can generate clean-core-compliant ABAP by default, and the same AI-assisted approach is compressing the remediation effort itself, a trend we detailed in how AI is cutting S/4HANA migration timelines from years to months.
Why This Is the Real Prerequisite for the Autonomous Enterprise
Everything above pays off twice. The first payoff is the well-known one: painless quarterly upgrades, lower cost, faster innovation. The second payoff is the one that now matters more: clean core is what makes AI agents trustworthy. An autonomous agent acting inside your ERP relies on stable, released APIs to read and write data; if your interfaces are custom hacks into unpublished internals, an agent cannot depend on them, and neither can SAP. Governed data lets an agent reason correctly; standardized processes give it a well-defined space to act. A messy core does not just slow upgrades, it makes safe autonomy impossible.
This is exactly why full SAP Joule agent access, including agents like Cash Management and Dispute Resolution, is gated behind clean-core alignment. We made the broader architectural case in how to build the foundation for the SAP Autonomous Enterprise, where clean core sits at the base of the entire stack. Put simply: clean core is phase one of the autonomous journey, and there is no skipping it. An agent is only as reliable as the interfaces and data beneath it.
The Numbers That Justify the Work
Beyond the 25 to 35% lower annual maintenance costs, clean-core enterprises onboard acquired subsidiaries in 3 to 6 months rather than 12 to 18, and adopt new capabilities on day one rather than after months of validation. BTP adoption has reached roughly half of all SAP customers, up about 10 points year over year, a sign the ecosystem is standardizing on exactly the extension model clean core requires. And in May 2026 SAP launched an official Clean Core Certification Programme, turning the principle into a measurable standard.
Common Delivery Mistakes to Avoid
Three mistakes derail clean-core delivery more than any others. The first is treating it as a pure code exercise and ignoring the data, process, integration, and operations dimensions, which leaves you with clean code sitting on messy data an agent still cannot trust. The second is trying to remediate everything at once instead of aggressively retiring dead code first; a large share of custom objects in any old landscape are simply unused, and remediating them is wasted effort. The third, and most costly, is delivering clean core as a project with an end date rather than a governed, ongoing discipline, which guarantees the technical debt creeps back. The organizations that stay clean are the ones that wired governance into daily development, not the ones that ran a one-time cleanup.
Where to Start This Quarter
If you want a concrete first move, it is the audit. Run the SAP Custom Code Migration App and Readiness Check against your current system to get an honest grade on the A-to-D scale and a classified inventory of every custom object. That single output tells you how far you are from Level A, how much is safe to simply retire, and how big the remediation really is, which is the foundation of any credible plan and budget. From there, the sequence is always the same: retire, remediate, rebuild, test, govern.
Clean core has quietly become the highest-leverage investment in the SAP world, because it is simultaneously a cost story, an upgrade-speed story, and the entry ticket to the autonomous enterprise. The roadmap to autonomous operations runs directly through it. Deliver a clean core, govern it relentlessly, and you will not just cut maintenance costs, you will earn the right to let AI agents run the work.