Clean core and SAP extensibility explained

Written by an SAP Finance & Treasury practitioner working with SAP since 2008 · how the guides are written · Updated 10 October 2026

Clean core is the principle that an SAP system's standard code and data model stay unmodified, with everything a company adds built on released, upgrade-stable extension points beside or on top of the standard. It exists because SAP ships updates on a regular cycle, and a system whose core has been rewritten cannot take them.

What does clean core mean?

The traditional SAP system was an open codebase. Any developer with the key could change a standard program, add a field to a standard table or hang custom logic on hundreds of exits, and for decades that is what companies did. The price came due at every upgrade: each modification had to be compared with SAP's new version and re-applied by hand, which is why upgrades were rare, expensive and feared. Clean core is the discipline that ends this. The core — SAP's code, its data model and its delivered processes — is treated as something you configure and extend but do not alter, and every extension goes through an interface SAP has committed to keep stable: a released API, a released extension point, a released object. In the public cloud edition the rule is enforced by the platform, since there is no way to modify what you do not host; in the on-premise and private-cloud editions it is a policy the company adopts and its architects enforce. The glossary has the one-line version; the rest of this guide is the mechanism.

Why did it become the rule?

Because the business model changed. A vendor operating the software as a service, under the subscription bundles, has to be able to update every customer on a schedule, and it can only do that if the customers' additions survive the update untouched. The same logic serves the customer: a clean system takes new capabilities as they ship, its custom code is smaller and documented, and the next generational shift is a migration rather than a rebuild. The principle also reshaped SAP's own tooling — the current programming model, the released-API catalogue and the platform beside the ERP were all built so that the clean way would also be the easy way.

What are the five dimensions of a clean core?

Extensibility is one of five. SAP's training material defines the core through five dimensions, each a different way of examining an ERP system, and calls a dimension clean when the practices and tools SAP provides for it are followed. Most of this guide deals with the second row, because that is where the engineering decisions sit.

One consequence is easy to miss. A newly provisioned cloud system running SAP's standard processes is clean by definition, so on a new implementation the task is to stay clean as extensions, integrations and migrated data arrive.

What are the extensibility options?

There are three extensibility options — key-user, developer and side-by-side — distinguished by who builds, where the extension runs and how tightly it couples to the core. They answer where an extension is built; the clean core levels in the next section grade how clean the result is.

• Key-user extensibility, in the application. Tools inside the system that let a trained business user or functional consultant add custom fields to standard objects, write small pieces of logic at defined points, adjust forms and screens and build simple reports — all without a development environment and without a transport in the classic sense. It covers a surprising share of what used to need a developer, and it is the first option to try.
• Developer extensibility, in the stack. Real code, written in the restricted ABAP language variant and the RESTful application programming model, running inside the ERP but only against released objects and APIs. It is the option for logic that needs the system's data and transactions at full speed, with the compiler and the release checks stopping you from reaching into the unreleased core. The developer career guide covers what this changed for the craft.
• Side-by-side extensibility, on the platform. A separate application on BTP — or another platform — that talks to the ERP through its APIs and events. Its own runtime, its own data where needed, its own release cycle. This is the option for things that are not really ERP at all: a supplier portal, a mobile app for the shop floor, a workflow across several systems, anything with its own users or its own pace of change.

What are the clean core levels A to D?

They are SAP's four grades for an extension: A relies on released APIs alone, D on changes to SAP's own code. Since 2025 SAP has graded extensions on this scale rather than treating clean core as yes or no, and the levels are how a landscape's cleanliness is now measured and reported. Earlier SAP material described a "three-tier" extensibility model for on-premise and private-cloud systems; the levels replace that vocabulary, which is why this guide calls the key-user, developer and side-by-side split options rather than tiers (SAP News Center).

The practical use of the scale is the backlog it produces. A conversion inventory that labels every custom object A to D turns "clean up the custom code" into a list with an order: D items are retired or rebuilt first, C items get an owner and an upgrade check, and new work starts at A.

How do you decide between them?

Start with the lightest option that can do the job and move on only when it cannot. A field and a validation are key-user work; if the logic needs a loop over other documents or a call to another system, it becomes developer work; if it needs its own screens for people who are not ERP users, or it changes faster than the ERP release cycle, it moves to the platform. The second question is coupling: how much of the core's data does it need, and how fast? Logic that must run inside the transaction, at posting time, belongs in the stack; logic that can run a moment later, on an event, can live outside. The third question is ownership: who will maintain this in five years, and do they have the skills for the option you chose? A good decision record names the option, the clean core level the result lands at, the released objects it relies on, and the reason the lighter option was rejected — that last line is what a reviewer looks for.

How do you get to a clean core, and how is it measured?

The route depends on the starting point. SAP describes a new implementation as a matter of staying clean, and a conversion of an existing system as getting clean and then staying clean: moving traditional custom code to the current extensibility options, replacing old interfaces and cleansing data. Its guiding principles are short: avoid extensions that are not necessary, stay close to the standard, know your technical debt and review it regularly, apply a zero-modification policy, and use the platform beside the ERP for whatever differentiates the business. For measurement, SAP's clean core strategy page points, as of October 2026, to a RISE with SAP Methodology dashboard hosted on SAP Cloud ALM that reports the clean core status of each system. The A to D levels above are the unit that such a report counts for custom code.

What does clean core mean for ABAP developers?

A narrower toolbox and a more valuable one. The instinct to modify is retired, the released-API catalogue becomes the map of what is possible, and the skill becomes finding the clean route to an outcome — which may be a key-user tool, a released extension point, or a well-argued case that the requirement should change. Developers who make this shift are in demand on every conversion — and the ECC deadlines guarantee plenty of those — where the existing custom code has to be sorted into keep, rewrite and retire, and on every cloud implementation, where the clean way is the only way. Developers who do not make it drift toward the maintenance of ageing systems. An ABAP interview today almost always contains a question that tests which kind you are.

What does it mean for architects and functional consultants?

For architects, clean core is the design principle that organises everything else: the extension decision above is theirs to defend, and a landscape's cleanliness is now something they are asked to measure. For functional consultants, the fit-to-standard style of the current methodology makes the workshop job holding the line — telling a real gap from a habit — and key-user extensibility means a consultant who can add the field and write the small rule is worth more than one who writes a specification. As with the wider platform shift, knowledge of the standard, and of extending it without harming it, is what appreciates.