SAPCodeMonkeyClean Core & ABAP Cloud, Explained
Clean core is widely misread as an instruction to stop building things. It is really a discipline about what you build against — and SAP now grades that on a four-level scale most material hasn't caught up with.
The phrase “clean core” is often heard as an instruction to stop building things. It is not. Clean core does not mean no customization; it means customizing in a way that survives the next upgrade. The question is not whether you customize, but what you customize against.
What it actually means
Extend using interfaces SAP has formally committed to keeping stable, and your extension survives releases. Extend against internal objects, and you own the risk every time SAP ships. Read as a prohibition, clean core gets resisted and ignored. Read correctly, it is a discipline about where risk sits.
It also spans more than custom code. There are six dimensions — software stack, extensibility, integrations, processes, data and operations — and a project can be blocked by data quality or process divergence as easily as by code. This article focuses on extensibility, where the A-to-D levels live, but the others matter.
The model you learned was replaced
In August 2025 SAP moved from a three-tier model to a four-level scale. Most training material has not caught up, so anyone quoting the old three tiers is working from superseded guidance. The old model told you a classic-ABAP estate was simply “not clean” and left you there. The level scale gives you a backlog you can sequence.
The four levels
Extensions are graded on upgrade safety. Level A uses released APIs only — a formal stability contract, on-stack via ABAP Cloud or side-by-side on BTP, carrying no upgrade risk. Level B uses classic but documented APIs: stable in practice without the formal contract, acceptable as a recorded decision. Level C reaches into internal SAP objects — it works today, but SAP never promised it would, so it needs a remediation roadmap. Level D is modifications, implicit enhancements and direct table writes: severe upgrade risk, and the thing being eliminated.
The grading rule that catches people out
An extension is graded by the lowest-ranked thing inside it. Three immaculate ABAP Cloud components and one direct table write produce a Level D extension. There is no averaging and no partial credit — which is why “mostly clean” is not a status worth reporting.
What to do about it
This is not a transformation program. Grade what you already have by running ATC with the clean core and ABAP Cloud readiness checks — most estates are less uniformly bad than feared. Stop the bleeding first: new development goes to Level A, and Level D patterns get blocked in new code. Triage by risk rather than by count, retiring dead code first. Wrap what you cannot yet replace behind your own interface, so that when SAP releases a proper API you change one thing rather than fifty. And choose on-stack versus side-by-side deliberately — both reach Level A, and the choice is architectural, not a compliance checkbox.
The bottom line
Clean core is not a restriction. It is a decision about who owns the risk. Build against a contract and SAP carries it; build against internals and you carry it, every release, forever.
Sources & further reading
- SAP Help — Getting Started with ExtensibilityCovers on-stack vs side-by-side and key-user vs developer extensibility. Verified live.
- SAP Community — ABAP & clean core discussionPractitioner coverage of the levels model and ATC readiness. Verified live.
The extensibility levels and clean core guidance are revised regularly — the three-tier model was replaced in August 2025. Verify against the current ABAP extensibility guide for your release. SAP guidance, transaction availability and dates change between releases and editions. Verify anything here against SAP Help for your own situation before you commit to it. This article is independent commentary and is not affiliated with SAP or any implementation partner.