SAP clean core: what it means, levels A to D and governance

SAP clean core means keeping your S/4HANA system as close to SAP standard as your business allows. Anything you add is built through interfaces SAP has released and promised to keep stable, so upgrades do not break it.

Short answer: clean core is a discipline for how you extend and govern SAP. Custom logic goes on-stack with ABAP Cloud or side-by-side on SAP BTP, and SAP grades every extension from level A (cleanest) to level D (modifications to remove). The payoff is faster upgrades: I have seen firms cut upgrade timelines by 40% this way.

If your system is full of modifications to SAP standard objects, every release becomes a regression project. If your custom logic sits behind released interfaces, upgrades become routine maintenance.

I have seen firms cut upgrade timelines by 40% by applying clean core principles. They did it by keeping customisations to the minimum and governing the ones they kept.

In 2024 a European consumer goods company replaced its legacy pricing logic with a modular Fiori app built outside the core on SAP BTP. That eliminated regression testing for that logic entirely.

You can still customise a clean core ERP. The customisation has to use interfaces SAP has released and committed to keep stable. SAP offers two ways to do that:

• On-stack, with ABAP Cloud. Extensions run inside S/4HANA but only use released APIs and extension points.
• Side-by-side, on SAP BTP. Extensions run as separate applications and talk to S/4HANA through APIs or events.

SAP describes its approach as BTP-first, choosing per use case. In my experience, where the code runs matters less than whether the requirement needs code at all.

A dirty core looks familiar to anyone who ran ECC: modified standard programs, Z-tables written to directly, interfaces that read SAP internals, implicit enhancements nobody documented. None of it was wrong when it was built. It just was not built for a system that upgrades every year or two.

I walk through why a migration without a clean core is already in trouble in this video.

SAP organises clean core around five guiding principles. This is how SAP frames each one, and what I look at first:

Principle	What SAP means	What I check first
Processes	Stay as close as possible to the SAP standard process	Which process variants exist only because "we always did it this way"
Extensibility	Extensions decoupled from the core through released APIs, with governance over which option is used	How much custom code exists, how much is used, and which level it sits at
Data	Clean, compliant data with an established governance model	Duplicate and incomplete master data, custom fields nobody can explain
Integrations	Standardised, secure connections built on supported technologies	Point-to-point interfaces that read tables directly
Operations	Governance, people, processes and tools that keep the other four in place	Who approves an extension, and what stops the next modification

Most teams start and finish with extensibility because it is the easiest to measure. In my experience processes and data cause more delay. Custom code is usually the symptom, and the process behind it is the cause.

In August 2025 SAP replaced its earlier three-tier extensibility model with the clean core level concept. Each extension is rated on how it is built, how decoupled it is from the core and how safely it survives an upgrade. If you read older SAP material that talks about tiers, this is what superseded it.

Level ALevel BLevel CLevel D

What it usesLevel APublicly released, stable interfaces onlyLevel BAlso SAP's classic APIsLevel CSAP internal objectsLevel DModifications, writes to SAP tables, implicit enhancements

Upgrade riskLevel ALowest, backed by stability contractsLevel BGenerally upgrade-stableLevel CNeeds checking at each upgradeLevel DHighest

What to decideLevel AThe default for anything newLevel BAccept, with the reason recordedLevel CAccept with a reason, recheck each upgradeLevel DRemove first, or move it to B or C

Source: SAP clean core level concept, SAP News, August 2025

Level A uses only publicly released interfaces with stability contracts, built with SAP Build, ABAP Cloud or BTP. Level B adds SAP's classic APIs. Level C touches SAP internal objects, and SAP plans a changelog for those to help with upgrade planning.

Level D is modifications, writes to SAP tables, implicit enhancements and other techniques SAP does not recommend. This is more useful than the old "clean or not clean" debate, because it lets you set a target per object. Moving your level D objects to B or C before an upgrade is already a real reduction in risk.

ABAP Cloud is SAP's cloud-ready ABAP development model. Developers use the "ABAP for Cloud Development" language version and can only build on released objects, public APIs and extension points. It started in the SAP BTP ABAP environment and is now available in every S/4HANA edition (SAP ABAP Cloud FAQ).

S/4HANA Cloud gives you three extension routes. Key user extensibility covers simple field, logic and UI changes without touching SAP code. Developer extensibility with ABAP Cloud handles tightly coupled logic, and side-by-side extensions on SAP BTP handle anything that should stay decoupled.

The edition decides how much choice you have:

	S/4HANA Cloud Public Edition	S/4HANA Cloud Private Edition and on-premise
ABAP development	ABAP Cloud only, mandatory for new customers since release 2208	ABAP Cloud recommended since 2022; classic ABAP still permitted
Changes to SAP code	Not possible	Possible, but they are level D
Key user and BTP side-by-side extensions	Available	Available
Who enforces clean core	The system	Your governance

My rule for Private Edition customers: treat it as if it were Public Edition for anything new. Classic ABAP is allowed, but every classic object you add today is a decision someone has to defend at the next upgrade.

Clean core decisions should be owned by a design authority made up of business and IT. IT alone will approve anything that is technically possible. The business alone will ask for its old process back.

This is how I would set it up:

1. Name the members. Business process owners for each major area, plus the solution architect and the lead developer. The business owners decide whether a requirement is real, and IT decides how it gets built.
2. Agree the order of preference before build starts. Standard process first, then key user extensibility, then level A on ABAP Cloud or BTP. Level B or C needs a written reason, and level D needs an exit plan.
3. Make every extension request carry an owner and a business reason. No owner, no build. The decision and the level accepted go into one register.
4. Put a technical gate in front of transports. Run the ABAP test cockpit's clean core checks on a schedule, and stop new level D code before it reaches production.
5. Review the register before every upgrade. Retire what nobody uses any more and move anything that can now reach a higher level.

The question at that table used to be "why can't this live on BTP?" Today I would ask "why can't this be level A?" If it can't, the next question is which level you are accepting and why.

The biggest clean core mistake I see is trying to make SAP work like Oracle. Adopt SAP's standard processes rather than rebuilding another system's logic in custom code. If you are still choosing between the two, I compare them in SAP vs Oracle.

Clean core is a change management problem before it is a technical one. Every custom object exists because somebody asked for it. Removing it means persuading that person the standard process is good enough.

That conversation goes better when the business sees the new process working, not a slide about it. It also goes better when you test the claim that a process is unique, because it often is not (see steps 4 and 5 below).

Skills matter as much as tools. An ABAP team that has not worked with ABAP Cloud or BTP will slow the programme down while it learns. One manufacturer I worked with ran a three-month internal BTP programme before its S/4HANA project started, and it paid off in fewer surprises during build.

Clean core compliance is how much of your system meets SAP's criteria across the five principles. You cannot manage it without numbers, and SAP gives you three places to get them.

1. The ABAP test cockpit. SAP's tool for code-level checks. It shows which custom objects use unreleased objects, modifications or direct table access.
2. The SAP Readiness Check. It comes with your maintenance agreement and shows what an S/4HANA move will touch before you commit.
3. The RISE with SAP Methodology dashboard, also known as the clean core dashboard. It runs in SAP Cloud ALM. Its system view checks your S/4HANA version, confirms data collection tools are active and reviews extensions ahead of an upgrade, and its operations view tracks operational KPIs.

The numbers I would put in front of the design authority every month are simple. How many custom objects sit at each level, and is level D falling? How many exceptions are open, and does each have an owner?

If you asked me to assess your system next month, this is the order I would follow.

1. Find out what is used. Run the SAP Readiness Check and collect usage data on your custom code. On one programme, analysis with smartShift took us from 18,000 custom objects to 3,200, because most of the rest was simply not used.
2. Classify what remains into levels A to D. Use the ABAP test cockpit for the code. If you are on RISE, the clean core dashboard tracks it from there.
3. Decide object by object. Retire it, move it to a released interface, rebuild it on BTP or keep it with a documented reason. Start with code that runs every day, because a report used twice a year by one regional team can wait.
4. Put the business in the room. A finance lead I worked with only understood their new Fiori app after a 45-minute walkthrough. That session saved two weeks of back-and-forth in UAT.
5. Challenge "our process is different". In a sales team workshop at a European industrial company in 2023, the "unique" process turned out to be 80% redundant legacy admin. Standard SAP improved their customer experience once the workarounds went.
6. Start data work early. A GCC retail client I worked with in 2024 had over 15,000 custom fields to sort through. In my experience data migration takes 30 to 40% of the implementation effort, and my SAP implementation cost guide shows where that lands in the budget.
7. Set the governance before go-live. Stand up the design authority described above and make it the only route for a new extension.

Three questions come up in almost every conversation I have about this.

Is clean core mandatory under RISE with SAP?

Not as a blanket rule. In Public Edition the system enforces it, while in Private Edition and on-premise you can still modify the core.

There, clean core is a governance choice that SAP tracks through the RISE methodology dashboard. If an SI tells you it is contractual, ask them to show you the clause.

How long do I have on ECC?

For SAP ERP 6.0 on enhancement packages 6 to 8, mainstream maintenance ends on 31 December 2027. Optional extended maintenance runs to 31 December 2030 at extra cost.

After that, the SAP ERP, private edition, transition option covers 2031 to 2033. It applies only to large systems already moved to SAP ERP, private edition on SAP HANA before the end of 2030.

Treat 2033 as an exception route, not a planning date. My ECC to S/4HANA migration guide covers the route choices.

Does clean core matter for AI?

Yes. Keeping SAP standard helps AI and Joule work better, and heavily modified processes are where they are hardest to adopt.

SAP builds its AI features, including Joule, on its standard processes and data model. Joule for developers generates ABAP Cloud code against released APIs. I cover how cloud, AI and clean core fit together in ERP modernisation.

The teams that skip clean core do not avoid the work. They defer it, and it comes back as blocked upgrades, regression testing marathons and custom code nobody understands.

Before you sign an S/4HANA or RISE contract, ask your SI to classify your current custom code into levels A to D. If they cannot produce one, that tells you something about the estimate. Book a call and we can look at your situation.

What is clean core in SAP?

Clean core means keeping S/4HANA close to SAP standard and building extensions only through interfaces SAP has released and committed to keep stable. Extensions run either on-stack with ABAP Cloud or side-by-side on SAP BTP. The goal is that upgrades do not break your custom logic.

What are the five principles of SAP clean core?

SAP's five guiding principles of clean core are processes, extensibility, data, integrations and operations. Processes stay close to standard, extensions use released APIs and data is kept clean under a governance model. Integrations use supported technologies, and operations covers the governance, people and tools that keep the other four in place.

What are SAP clean core levels A, B, C and D?

Since August 2025 SAP classifies extensions into four levels. Level A uses only publicly released, stable interfaces, level B also uses classic SAP APIs, and level C accesses SAP internal objects. Level D covers modifications, writes to SAP tables and implicit enhancements, and carries the highest upgrade risk.

Is clean core mandatory for RISE with SAP?

Not as a blanket rule. S/4HANA Cloud Public Edition only allows ABAP Cloud and released interfaces, so it enforces clean core technically. In Private Edition you can still modify the core, so clean core is a governance decision that SAP tracks through the RISE with SAP Methodology dashboard.

What is ABAP Cloud?

ABAP Cloud is SAP's cloud-ready ABAP development model. It allows only released objects, public APIs and extension points, which keeps custom code upgrade-stable. It is mandatory in S/4HANA Cloud Public Edition for new customers since release 2208 and recommended in Private Edition and on-premise since 2022.

How do you measure clean core?

Use the ABAP test cockpit for code-level checks and classify custom objects into levels A to D. RISE customers can track adoption in the RISE with SAP Methodology dashboard, also called the clean core dashboard, in SAP Cloud ALM. I track the count of objects at each level, the trend in level D and the number of open exceptions with an owner.

Who should own SAP clean core governance?

A design authority made up of business and IT should own every clean core decision. Business process owners decide whether a requirement is real, and IT decides how it is built and at which level. Every exception is recorded with an owner and reviewed before each upgrade.

When does SAP ECC support end?

For SAP ERP 6.0 on enhancement packages 6 to 8, mainstream maintenance ends on 31 December 2027, with optional extended maintenance to 31 December 2030 at extra cost. The SAP ERP, private edition, transition option runs to 2033 only for eligible large systems moved to SAP ERP, private edition on SAP HANA before the end of 2030.