Anyone who has been involved with Clean Core in recent years is familiar with the three-tier extensibility model. However, since the update of the ABAP Extensibility Guide in Summer 2025, a new landscape applies: the Clean Core Level Concept with four levels A to D. The good news first – if you are already developing according to Tier 1 principles, you are automatically on the right track. The new model doesn’t change the direction but brings significantly more granularity to where most existing systems stand today: Classic ABAP.
Why a New Model?
The old tier model was essentially a binary decision: clean or not clean. This works well for new developments. However, for a grown system with thousands of Z-objects, it is not very helpful if 80 percent of the code is indiscriminately classified as “Tier 3” – without distinguishing whether an object only uses a classic BAdI or modifies the SAP standard. This is precisely the differentiation the level model provides: it assesses how close each individual extension is to the Clean Core principles, thereby enabling a gradual transformation at one’s own pace.
Level A: The Target State
Level A comprises the cleanest extensions – built either on-stack with the ABAP Cloud development model directly in the S/4HANA system or side-by-side on the SAP BTP, for example, with ABAP Cloud, CAP, or low-code tools from SAP Build. The common denominator: only released APIs and extension points are used, for which SAP provides stability commitments. If a required API is missing, the proven wrapper concept is applied – encapsulating unreleased access behind a proprietary interface remains the clean transition path. Level A extensions are maximally upgrade-stable and Public Cloud-ready.
Level B: Classic ABAP According to the Rules
Level B is new – and perhaps the most important stage for existing systems. This is where classic ABAP lands, which follows SAP’s development recommendations and uses the frameworks offered as classic APIs: BAdIs, released function modules, documented extension techniques. No ABAP Cloud, but disciplined construction. The message behind it is remarkably pragmatic: well-executed Classic ABAP is not a case for remediation. It does not necessarily have to be migrated to be considered largely clean.
Level C: Conditionally Clean – with Audit Obligation
Level C includes extensions that access arbitrary SAP internal objects – i.e., what constitutes the lion’s share in grown systems: direct selects on SAP tables, calls to unreleased modules. The interesting point: these objects are considered “conditionally clean” if dedicated checks against the change history of the used SAP objects are performed before each release upgrade. This transforms a diffuse risk into a controlled process – provided one knows which objects are affected.
Level D: The Actual Need for Action
Level D is not Clean Core. This is where extensions with severe violations of SAP’s development recommendations lie: modifications to the standard, unrecommended objects, and deprecated extension technologies. This is the area that reliably generates effort and errors with every upgrade – and on which a Clean Core roadmap should first focus.
What Does This Mean in Practice?
For new developments, the rule remains simple: Level A first, BTP-first where sensible, wrappers where APIs are missing. For existing systems, the model fundamentally changes the equation: instead of “everything must eventually move to ABAP Cloud,” the task is now to specifically replace D-objects, transfer C-objects into a controlled audit process, and simply keep B-objects clean. This is significantly more realistic – but it requires knowing how your custom code is distributed across the four levels.
Would you like to know how your custom code is distributed across Levels A–D? With our Clean Core Assessment, we create transparency in just a few days – contact us.