Clean core is the principle that keeps SAP S/4HANA Cloud Public Edition upgrade-stable: the standardized ERP core is left unmodified, and everything an organization adds on top is built through released, supported mechanisms rather than by changing the core itself. A clean core extension strategy is the set of decisions and governance that keeps a landscape on that path as real requirements arrive. It is not a tool — it is how an organization decides what to build, where to build it, and what evidence it accepts before a custom extension is allowed.
The payoff is concrete. Because SAP S/4HANA Cloud Public Edition receives regular upgrades, extensions that rely only on released interfaces continue to work across those upgrades, while modifications to the core would break or require rework. A clean core strategy trades unconstrained customization for lifecycle stability, predictable operations, and a lower long-term cost of ownership.
The foundation of the strategy is the interface contract between an extension and the core. Extensions consume the core through public, released APIs and business events — stable interfaces that SAP commits to maintaining — instead of reading and writing internal tables or altering delivered logic. A warehouse process that needs a custom step, for example, is extended by calling released APIs and reacting to released events, so the flexibility lives in the extension while the core stays standard.
This is why "released" is the operative word. An interface that is publicly released carries a compatibility commitment; an internal object does not. A clean core strategy therefore starts every extension design by confirming that the required data and actions are available through released interfaces, and treats the absence of a released interface as a design constraint to resolve rather than a rule to bypass.
A clean core strategy applies a consistent order of preference to every requirement:
Working in this order keeps the number of extensions small and their coupling loose, which is what makes upgrades routine rather than risky.
A strategy only holds if it is governed. In practice that means a lightweight design review for every proposed extension, which checks four things before build starts:
Extensions that cannot be met through released interfaces are escalated as gaps — logged, raised with SAP where an interface is missing, and given an interim design with a defined exit — rather than solved by quietly reaching into the core.
Over time, SAP has refined how it classifies extension approaches by their alignment with clean core, evolving from an earlier tiered model toward a clean core "levels" maturity model that grades extensions on architectural integrity and upgrade safety. The exact classification and its labels change as the model matures, so a strategy should reference SAP's current guidance rather than a fixed set of tiers.
The goal of the whole strategy is lifecycle independence: the ability to upgrade the ERP core on SAP's schedule and to evolve extensions on the organization's own schedule, without the two blocking each other. Each extension should have a named owner, a test approach tied to the upgrade cycle, and a documented set of released interfaces it depends on, so that the impact of any change — from either side — is knowable in advance.
To choose between the concrete extension mechanisms this strategy governs, see [Extensibility options in SAP S/4HANA Cloud Public Edition]. For orientation on the platform as a whole, see [What is SAP Business Technology Platform (BTP) and how does it relate to SAP S/4HANA Cloud Public Edition?].
It is the set of decisions and governance that keeps SAP S/4HANA Cloud Public Edition upgrade-stable while still meeting real requirements. The standardized core is left unmodified, and additions are built through released interfaces and supported extensibility mechanisms rather than by changing the core.
Public Edition receives regular upgrades. Extensions built only on released interfaces keep working across those upgrades, whereas core modifications break or require rework. Clean core trades unconstrained customization for lifecycle stability, predictable operations, and lower long-term cost.
Extensions consume the core through public, released APIs and business events that SAP commits to maintaining, instead of reading or writing internal tables or altering delivered logic. Confirming a released interface exists is the first step of any extension design.
Adopt the standard first, then configure, then extend through released key-user, developer, or side-by-side mechanisms, and only then keep any justified custom logic outside the core. This order keeps the number of extensions small and their coupling loose.
The gap is logged and escalated: raised with SAP where an interface is missing, given an interim design with a defined exit, and reviewed — rather than solved by reaching into the core. Missing released interfaces are treated as design constraints, not rules to bypass.
Through a lightweight design review for each proposed extension that checks whether the requirement is truly unmet by standard and configuration, whether it can use released interfaces, which mechanism fits, and how it will be tested against each upgrade.
No. Customization is allowed and expected, but through supported extensibility that consumes released interfaces and lives outside the core. Clean core constrains how you extend, not whether you extend.
It is the ability to upgrade the ERP core on SAP's schedule and evolve extensions on your own schedule without either blocking the other. Each extension has a named owner, a test approach tied to the upgrade cycle, and a documented list of the released interfaces it depends on.
SAP has evolved from an earlier tiered model toward a clean core 'levels' maturity model that grades extensions on architectural integrity and upgrade safety. The labels change as the model matures, so use SAP's current guidance rather than a fixed set of tiers.
Use SAP's current clean core and extensibility documentation, the released API and event catalog for SAP S/4HANA Cloud Public Edition, and current SAP guidance. Interface availability and the maturity model evolve, so recheck before finalizing a design.