"Keep the core clean" has become the standard advice for any SAP programme. But it is often misunderstood as "no customisation at all". In reality, almost every company needs some logic that standard SAP does not provide. Clean core is about where that logic lives.
What clean core really means
A clean core is an ERP that can be upgraded without breaking. Custom functionality is still allowed, but it is built in a way that does not depend on SAP internals: through released APIs, supported extension points and clear separation from standard code. The payoff is practical: shorter upgrade projects, less regression testing and the freedom to adopt new SAP innovations when you need them.
Three places an extension can live
- In-app (key user) extensibility. Custom fields, simple logic and adapted forms, configured inside the ERP with SAP's own tools.
- On-stack developer extensibility. Custom code that runs inside the ERP but uses only released APIs and the restricted ABAP Cloud model, so it stays upgrade-safe.
- Side-by-side on SAP BTP. Applications, workflows, portals and integrations that run next to the ERP and talk to it through standard APIs and events.
SAP's four clean core levels
In August 2025 SAP replaced its earlier three-tier extensibility model with a four-level classification that gives every extension a clear grade, and maps directly to ABAP Test Cockpit (ATC) checks:
- Level A: only publicly released, stable interfaces, built with ABAP Cloud on-stack or side-by-side on SAP BTP. Fully upgrade-safe, and the target for all new development.
- Level B: also uses SAP's classic, documented APIs. Acceptable, but worth tracking.
- Level C: accesses SAP internal objects that are not released. Flexible for legacy scenarios, with real upgrade exposure.
- Level D: explicitly non-recommended techniques such as modifications, direct writes to SAP tables or implicit enhancements. The highest risk and technical debt.
The practical value of the model is that it turns "is this clean?" into a measurable grade that ATC reports automatically, from no message at level A to an error at level D.
A simple decision guide for existing custom code
Most landscapes carry years of custom objects. Each of them falls into one of four buckets:
- Retire it if nobody uses it. Usage data usually shows a surprising amount of dead code.
- Replace it with standard if SAP now covers the requirement, even if the process needs a small adjustment.
- Keep it in the core, rebuilt on released APIs, if it is tightly coupled to transactional data and has to run inside the same logical unit of work.
- Move it side-by-side if it has its own users or UI, serves external parties, spans several systems or needs its own release cycle.
Make it measurable
Clean core decisions should rest on facts, not opinions. Build an inventory of custom objects, combine it with real usage data, and run automated code checks to see which objects use non-released APIs. The result is a prioritised list with a recommendation for every object, and an effort estimate for the ones that need work.
You do not need to wait for a migration
Clean core is not only for new S/4HANA Cloud implementations. Companies on SAP ECC or S/4HANA on-premise can start today: retiring unused code, moving new requirements to SAP BTP and replacing fragile point-to-point interfaces. Every step reduces the size of the eventual migration and makes the current system easier to run.