SAP Clean Core — Strategy Behind Every S/4HANA Build Decision

Ask how a custom requirement was handled in any SAP implementation from the last fifteen years and the answer is usually the same. Someone wrote a Z-program, modified a standard include, or added logic directly inside a user exit without giving much thought to what the next upgrade would cost. It worked. The business got what it needed. The technical debt quietly accumulated.

SAP Clean Core is the framework that forces that conversation to happen up front rather than during the next transformation programme. It defines not just what should stay standard, but how custom logic should be built when it genuinely cannot be avoided. Every build decision on a modern S/4HANA project — on-premise, private cloud or public cloud — now runs through this framework, whether the team knows it or not.

If you have heard the term in project meetings without getting a clear explanation, this post gives you the model. If you already know the basics, the extensibility levels and the AI angle are worth reading.

🔗 Foundation posts

Clean Core is the architectural discipline that makes S/4HANA transformation sustainable. For background on S/4HANA itself, start with SAP S/4HANA vs ECC — The Real Difference . For the platform where clean extensions live, see SAP BTP — The Platform Explained.

What Clean Core actually means

The principle is straightforward: keep the S/4HANA system as close to SAP standard as possible, and push any custom logic outward — to approved extension points, released APIs, or the SAP Business Technology Platform. The core stays untouched. Innovation happens around it, not inside it.

What catches people out is the word modifications. In SAP, a modification is not the same as an extension. Modifying a standard SAP object — changing delivered ABAP source code, for example — creates something that SAP’s upgrade process has to work around. It is the root cause of the painful, expensive, high-risk upgrades that have defined SAP implementations for decades.

An extension, built through a released API or a defined enhancement point, is different. SAP owns the contract for that interface. When SAP ships an upgrade, the interface is preserved. Your extension continues to work. That distinction — modification versus extension — is what Clean Core is built on.

📌 The one rule

Zero modifications to SAP standard objects. Extensions are built using released APIs, extension points, and approved tools — not by changing what SAP delivered.

Why the old way broke upgrades

In ECC, the standard approach to a gap between SAP standard and business requirement was a Z-program or a core modification. ABAP was accessible, the tools were familiar, and the short-term result was a system that did exactly what the business needed.

The cost arrived at upgrade time. Every modification had to be reviewed, re-tested and often rewritten. Custom programs that accessed internal SAP tables by name broke when SAP restructured those tables. Interfaces built on BAPIs and RFCs that were never officially released behaved unpredictably across releases. The more custom code a system carried, the longer the upgrade project, the higher the risk, and the more likely the business would defer the upgrade — which made the next one even harder.

This pattern has a name in the industry: the dirty core. A system so laden with undocumented modifications and tightly-coupled custom logic that every SAP update becomes a renegotiation with the past. I have seen it on projects where the custom code inventory ran to tens of thousands of objects, many of them undocumented, and the ECC-to-S/4HANA migration estimate tripled once the true scope of remediation was understood.

⚠️ The ECC deadline

SAP mainstream maintenance for ECC ends 31 December 2027, with extended maintenance available until 2030 at additional cost. Every organisation still on ECC with a heavy modification footprint is carrying that technical debt into a mandatory transformation. The dirtier the core, the harder and more expensive that transition will be.

IMAGE BLOCK — Dirty Core vs Clean Core

The six dimensions of Clean Core

Clean Core is not just about custom code. SAP defines six dimensions — six areas where the same principle of standardisation and decoupling applies. Fixing the ABAP and ignoring the others leaves a system that is partially clean and still expensive to upgrade.

Dimension	The principle	What it means in practice
Software Stack & Core	Keep S/4HANA on a current, supported release	Run on a release SAP actively maintains. Defer upgrades indefinitely and the clean core journey becomes more expensive each time.
Processes	Adopt SAP standard processes where possible — minimise variants	The more process variants you build custom logic around, the more that logic has to be maintained. Fit-to-standard first, extend only where genuinely necessary.
Extensibility	Build custom logic using released extension points and APIs only	No modifications to standard objects. Extensions must be upgrade-stable — meaning SAP has committed to maintaining the interface.
Integration	Connect systems via standard APIs and event-driven patterns	Replace BAPI and RFC interfaces with released OData or SOAP APIs where alternatives exist. Pre-built content from SAP Business Accelerator Hub reduces custom integration development.
Data	Keep data clean, complete and governed	Incomplete, duplicate and corrupted data creates pressure for compensating custom logic. Data governance is a precondition for a clean core — not a separate workstream.
Operations	Embed Clean Core governance into the ongoing delivery lifecycle	Clean Core is not a one-time migration state. It is maintained through ongoing governance — review processes, tooling, and KPIs tracked in the RISE with SAP Methodology Dashboard.

💡 The dimension most teams ignore

Integration debt gets far less attention than custom code, but it generates the same upgrade risk. Every interface built on an unreleased BAPI or direct RFC is a liability that needs remediation before moving to S/4HANA Cloud. Address integration alongside extensibility — not after.

Where your custom logic belongs — the extension options

Clean Core does not mean no customisation. It means customisation in the right place, using the right tools. SAP provides two primary extension models, and both are considered clean when used correctly.

On-stack extensibility — inside S/4HANA with ABAP Cloud

On-stack extensions are built directly within the S/4HANA system, using the ABAP Cloud development model. ABAP Cloud is a restricted, cloud-optimised version of ABAP that enforces Clean Core compliance through syntax checks — the system simply will not let you access unreleased SAP objects. You use released APIs, CDS views, BAdIs and defined extension points. Nothing more.

On-stack is the right choice when the extension has a tight transactional dependency on the core — when the logic genuinely needs to run inside the same process as the SAP standard code. Key user extensibility tools (Custom Fields and Logic, UI Adaptations, Business Rules) sit in this category too, requiring no developer knowledge at all.

Side-by-side extensibility — on SAP BTP

Side-by-side extensions run outside S/4HANA entirely, on the SAP Business Technology Platform. The extension communicates with S/4HANA through released APIs — OData or event-based — and has no direct access to the core system. SAP Build, the unified development environment on BTP, supports both low-code and pro-code (ABAP Cloud, CAP, Java, JavaScript) approaches.

Side-by-side is the right choice for standalone applications, process automation, and anything that does not require in-process execution. It offers the strongest decoupling — which means the least upgrade exposure — and is SAP’s preferred direction, often described as BTP-first.

✅ The BTP-first principle

When both on-stack and side-by-side can solve the problem, default to side-by-side on BTP. Decoupled extensions are easier to upgrade, easier to test independently, and cleaner to maintain. On-stack is the right answer when tight transactional coupling genuinely requires it — not as the default.

The A–D extensibility levels — the governance tool

Until 2025, SAP used a three-tier model to classify extensions. Tier 1 was clean (ABAP Cloud and released APIs), Tier 2 was a transitional bridge, and Tier 3 was classic ABAP — not clean. The model was useful but binary. It treated all classic ABAP the same way, which did not reflect reality. Some classic patterns carry minimal upgrade risk. Others are genuinely dangerous.

In 2025, SAP replaced this with the clean core level concept — a four-level maturity model (A, B, C, D) that gives a more precise picture of where each extension sits. Think of it like an energy efficiency rating for custom code: Level A is the modern, future-ready choice; Level D is the legacy liability.

Level	Classification	What it means	Examples
A	Fully compliant — recommended	Built on publicly released, stable SAP APIs with formal stability contracts. On-stack via ABAP Cloud or side-by-side on BTP. Upgrade-safe.	ABAP Cloud on-stack, SAP Build on BTP, Key User Extensibility, CAP extensions
B	Conditionally acceptable	Uses SAP’s classic APIs — well-documented and generally stable, but not under the same formal stability contract as Level A. Acceptable with governance.	Classic released APIs, stable function modules with documented interfaces
C	Partially compliant — manage actively	Accesses SAP internal objects. Some upgrade risk. SAP plans to provide changelogs to help identify impact early. Requires a documented remediation roadmap.	Custom logic accessing non-released SAP internal tables or structures
D	Not recommended — highest risk	Uses explicitly non-recommended objects or techniques. Modifications to SAP standard code, write access to SAP tables, implicit enhancements. Significant technical debt.	Core modifications, write access to SAP-delivered tables, implicit enhancements on standard programs

The levels are not just a classification exercise. They are a governance instrument. Setting a policy — no new D-level code, all C-level code requires a remediation plan within twelve months — is how you stop Clean Core from being a slide-deck principle and turn it into an operational standard.

The ABAP Test Cockpit (ATC) is the tool that makes this measurable. ATC on SAP BTP is SAP’s recommended approach for private cloud and on-premise landscapes — it runs automated checks against your custom code and classifies objects against the clean core levels. The results feed into the RISE with SAP Methodology Dashboard, which tracks Clean Core KPIs across the landscape.

💡 Practical governance approach

Treat the A–D ratings like a credit score for your SAP landscape. Run ATC regularly, aim to increase A and B extensions over time, keep C-level code on a documented remediation schedule, and enforce zero tolerance for new D-level development. That is how the model becomes a living practice rather than a one-time audit.

What Clean Core enables that a dirty core cannot

The usual case for Clean Core is framed around what it prevents: painful upgrades, high maintenance costs, remediation projects. That is all true. But the more important case is what it enables forward.

Continuous innovation from SAP

SAP ships S/4HANA Cloud Private Edition updates on a roughly two-year major release cycle. Public Cloud customers receive continuous updates. A clean core means you can consume those updates without a remediation project each time. New functionality, new Fiori apps, new process capabilities — available without first untangling years of modifications. A dirty core turns every SAP release into a negotiation.

AI readiness — Joule depends on it

SAP’s AI copilot Joule works through released APIs and standard process flows. It does not know your Z-programs. It cannot navigate custom logic built inside standard ABAP includes. For Joule to be useful on a process, that process needs to be clean — running on standard flows, accessible via released APIs, with data that is complete and consistent.

As of 2026, Joule is currently available to RISE with SAP and GROW with SAP customers. Classic on-premise deployments are not included in the current Joule rollout. That is an access gate, and the technical gate underneath it is Clean Core. Organisations with dirty cores are not just facing upgrade risk — they are locked out of SAP’s AI roadmap until they address it.

📝 Joule for Developers

Joule for Developers, embedded in ABAP Development Tools (ADT) in Eclipse and SAP Business Application Studio, flags Clean Core violations in real time as developers write ABAP. It suggests released APIs instead of deprecated function modules and correct CDS views instead of direct table reads. It is a practical governance tool built into the development environment itself.

Lower total cost of ownership

Every modification that is removed from the core is a maintenance obligation that disappears. Every extension moved to BTP is an object that does not need to be re-tested at the next S/4HANA upgrade. The TCO argument for Clean Core compounds over time — the cleaner the system becomes, the cheaper each subsequent change and upgrade cycle gets.

At a glance — SAP Clean Core

Concept	One-line summary
SAP Clean Core	Keep S/4HANA standard and upgrade-stable by building extensions outside the core, not inside it
Dirty core	A system weighed down by modifications and tightly coupled custom logic — expensive to upgrade and unable to consume SAP innovation cleanly
Modification vs extension	A modification changes SAP standard code — upgrade risk. An extension uses a released interface — upgrade-safe
Six dimensions	Software stack, Processes, Extensibility, Integration, Data, Operations — Clean Core applies across all six, not just custom code
On-stack extensibility	Custom logic built within S/4HANA using ABAP Cloud and released APIs — clean, upgrade-stable, for tight transactional dependencies
Side-by-side extensibility	Custom apps and logic built on SAP BTP, communicating with S/4HANA via released APIs — maximum decoupling, SAP’s preferred direction
Level A	Fully compliant — built on released APIs using ABAP Cloud or SAP Build on BTP
Level B	Conditionally acceptable — classic stable APIs with governance in place
Level C	Partially compliant — accesses internal objects, requires a documented remediation plan
Level D	Not recommended — modifications, implicit enhancements, write access to SAP tables. Highest technical debt.
ABAP Test Cockpit (ATC)	The tool that measures Clean Core compliance — classifies custom code against the A–D levels, feeds results into the RISE with SAP Methodology Dashboard
BTP-first	SAP’s recommended default: when on-stack and side-by-side can both solve the problem, choose BTP
Joule dependency	SAP’s AI copilot works through released APIs and standard flows — a dirty core locks organisations out of SAP’s AI roadmap

What to take away

Clean Core is not a purity standard. It is an optionality strategy. The organisations investing in it now are not doing it because they love architecture principles — they are doing it because they want to be able to move when SAP ships something they actually need, without first spending six months untangling the modifications from the last project.

The A–D levels make this concrete. Run the ABAP Test Cockpit, understand where your custom code sits today, and set a governance policy around it. The goal is not to reach Level A everywhere overnight — that is neither realistic nor necessary. The goal is to stop adding Level D, start reducing Level C, and make Level A the default for anything new.

Every build decision on an S/4HANA project is now a Clean Core decision. The question is no longer just can we build this — it is where should this logic live, and will it survive the next upgrade. Get that question into your project governance early, and the rest follows.

🔗 Related posts

SAP S/4HANA vs ECC — The Real Difference — Clean Core is the architectural discipline behind every S/4HANA transformation. Start here for the broader context.
SAP S/4HANA Migration — Greenfield, Brownfield, Bluefield — the migration path choice determines how clean your S/4HANA starting point will be.
SAP BTP — The Platform Explained — BTP is where side-by-side extensions live. This post explains the platform, its services, and how it connects to S/4HANA.
CDS Views and the VDM in SAP S/4HANA Explained — On-stack Clean Core extensions are built on CDS views and the RAP framework. This post explains the data model underneath.
OData Protocol in SAP — V2, V4 and How It Works — Released OData APIs are the integration interface Clean Core extensions must use. V4 is the current standard for new development.

Published on rakeshnarayan.com — Articles

URL: https://rakeshnarayan.com/articles/sap-clean-core-strategy-behind-every-s4hana-build-decision/