If you're planning S/4HANA work this year, you'll hear "clean core" in almost every conversation. In August 2025 SAP replaced its earlier guidance with four levels, A to D, that describe how safe each kind of extension is when SAP upgrades your system. The levels are simpler than the name suggests, and they give you a practical way to sort the custom code you already have.
What clean core means
A clean core is an SAP system where custom work stays outside SAP's own code, or talks to it only through interfaces SAP promises to keep stable. The point is upgrades. If your extensions only use stable interfaces, an upgrade shouldn't break them, so upgrades get cheaper, faster and less frightening.
Most long-running SAP systems aren't clean. Over the years, teams modified standard code, wrote directly to SAP tables, or used enhancement points that SAP never promised to keep. Those shortcuts worked, and they're why upgrades take months.
The four levels
SAP describes the levels by how compliant an extension is.
| Level | What it covers | Upgrade risk |
|---|---|---|
| A | Extensions that use only publicly released, stable SAP interfaces. That means side-by-side apps on SAP BTP, or on-stack code written with ABAP Cloud and released APIs. | Lowest |
| B | Level A, plus classic APIs and technologies that are documented and generally stable across upgrades, such as BAPIs. | Low |
| C | Extensions that access SAP's internal objects, kept for legacy scenarios. SAP plans to publish a changelog so you can spot upgrade risks early. | Medium, needs governance |
| D | Techniques SAP explicitly doesn't recommend, such as modifications, write access to SAP tables and implicit enhancements. | Highest |
New work should land at level A or B. Levels C and D aren't banned, but every object there is something you'll need to retest, and possibly fix, at each upgrade. The framework matters most for S/4HANA Cloud private edition and on-premise systems, because the public cloud edition can only be extended in the first place.
SAP DEVELOPERSFiori and ABAP developers, ready in 1–2 weeks.Talk to us →
Examples from typical ECC custom code
A few common cases show how the levels play out:
- A new Fiori app on SAP BTP that reads purchase orders through a released API is level A.
- A Z report that calls a standard BAPI to create sales orders is typically level B.
- A report that reads SAP's internal objects directly, outside the released interfaces, falls into level C.
- A modification to a standard SAP program, or an update statement that writes straight into a standard table, is level D.
Your exact classification depends on the objects involved, so check it with the tools instead of guessing.
How to sort what you already have
The ABAP test cockpit is the main tool for this. It can check your custom code against clean core rules and flag what it finds. A practical way to use it:
- Run the clean core checks across your custom code and export the results.
- Combine them with usage data, so you can see which objects actually run in production.
- Retire unused objects first. It's the cheapest clean-up there is.
- For used objects in level D, decide whether to replace them with standard SAP, rebuild them at level A or B, or keep them with a clear owner and a retest plan.
- Treat level C as a watch list. Keep it small and documented.
For new work, set a simple rule: new extensions are built at level A or B unless someone signs off on an exception.
Where new extensions should go
You have two clean options for new work. On-stack, ABAP Cloud lets you build inside S/4HANA using only released APIs. Side-by-side, you build on SAP BTP and connect through APIs, which suits apps that also touch non-SAP systems or that you want to change often. Many teams use both: on-stack for logic close to the data, side-by-side for new user-facing apps and integrations.
How we help
We work on both sides of this. We review and rework existing ABAP custom code, rebuild level D objects as cleaner extensions, and build new Fiori and SAPUI5 apps with OData services that sit at the levels SAP recommends. Our developers work inside your landscape, standards and transport process.
See our SAP development services, read our post on SAP ECC end of support in 2027, or get a quote.
