{"id":2838,"date":"2026-07-23T08:53:42","date_gmt":"2026-07-23T06:53:42","guid":{"rendered":"https:\/\/secat.de\/from-tier-1-3-to-level-a-d-understanding-the-new-clean-core-level-model\/"},"modified":"2026-07-23T09:05:18","modified_gmt":"2026-07-23T07:05:18","slug":"from-tier-1-3-to-level-a-d-understanding-the-new-clean-core-level-model","status":"publish","type":"post","link":"https:\/\/secat.de\/en\/from-tier-1-3-to-level-a-d-understanding-the-new-clean-core-level-model\/","title":{"rendered":"From Tier 1\u20133 to Level A\u2013D: Understanding the New Clean Core Level Model"},"content":{"rendered":"\n

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 \u2013 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. <\/p>\n\n

Why a New Model?<\/h2>\n\n

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” \u2013 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. <\/p>\n\n

Level A: The Target State<\/h2>\n\n

Level A comprises the cleanest extensions \u2013 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 \u2013 encapsulating unreleased access behind a proprietary interface remains the clean transition path. Level A extensions are maximally upgrade-stable and Public Cloud-ready. <\/p>\n\n

Level B: Classic ABAP According to the Rules<\/h2>\n\n

Level B is new \u2013 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. <\/p>\n\n

Level C: Conditionally Clean \u2013 with Audit Obligation<\/h2>\n\n

Level C includes extensions that access arbitrary SAP internal objects \u2013 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 \u2013 provided one knows which objects are affected. <\/p>\n\n

Level D: The Actual Need for Action<\/h2>\n\n

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 \u2013 and on which a Clean Core roadmap should first focus. <\/p>\n\n

What Does This Mean in Practice?<\/h2>\n\n

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 \u2013 but it requires knowing how your custom code is distributed across the four levels. <\/p>\n\n

Would you like to know how your custom code is distributed across Levels A\u2013D? With our Clean Core Assessment, we create transparency in just a few days \u2013 contact us. <\/em><\/p>\n\n

Sources<\/h2>\n\n