Blog Details

SAP clean core is the design discipline of keeping your SAP system standard, upgrade-stable, and addressable through released APIs, so the capabilities SAP ships (including its AI) run the way they were built. Custom code that breaks clean-core principles can become a significant barrier to adopting and reliably operating SAP’s AI capabilities. 

For years, custom code was filed under “technical debt”: something to clean up eventually, tolerated because it kept the business running. That framing is out of date. In an S/4HANA and SAP Business AI world, unmanaged custom code is not just debt you service later. It is the thing standing between you and every AI capability SAP is now shipping.

This guide is for Solution Architects, Heads of SAP, and development leads who have heard “keep the core clean” repeated in every SAP roadmap deck and want the actual mechanism: what a clean core is, why SAP custom code blocks AI, and what an ABAP remediation effort looks like in practice.

What is SAP clean core?

A clean core is an SAP system where standard functionality stays standard, extensions are built to SAP’s extensibility model, data and integrations are governed, and the whole thing stays upgrade-stable. The phrase “keep the core clean” means one rule above all others: do not modify SAP standard objects, and do not reach into internals SAP has not released. A clean core SAP system follows that rule everywhere, which is what keeps it upgrade-stable and open to automation.

SAP defines clean core across six dimensions, not one:

• Software: stay on standard, stay current, avoid modifications.
• Extensions: build only through the SAP extensibility model.
• Data: keep the data model clean, governed, and archived.
• Integrations: connect through released APIs and standard interfaces.
• Processes: keep processes aligned to standard where possible.
• Operations: run with clear governance and monitoring.

Code sits inside the software and extensions dimensions, and it is where most SAP estates fail the test. Twenty or thirty years of ECC development leaves thousands of Z-objects, enhancement implementations, and modifications, much of it undocumented and some of it duplicating standard behaviour that now ships in the box. That accumulated SAP custom code is exactly what a clean core strategy is designed to contain.

A quick clarification that matters to architects: clean core does not mean “no custom code.” It means custom code that lives in the right place, built the right way, so it survives upgrades and stays out of SAP’s way. The distinction between a clean extension and a dirty modification is the whole game.

Why does custom code block AI adoption?

Because SAP’s AI reasons and acts through released APIs, and custom code that bypasses them is invisible or unpredictable to it.

Here is the mechanism. SAP Business AI (Joule, the growing set of Joule agents, and embedded AI) is delivered on the cloud editions of SAP Cloud ERP through RISE and GROW. On-premise and classic ABAP-heavy landscapes are excluded from these capabilities entirely. When a Joule agent books a goods receipt, updates a sales order, or reads a costing result, it does so through the standard process and its released API contract. That contract is stable, versioned, and something SAP guarantees.

Now introduce custom code that modified that process. A Z-enhancement that changes how the sales order behaves, a modification to a standard object, or an interface reading a non-released internal table gives the AI agent no stable surface to act on. SAP cannot guarantee the outcome, so the automation either fails or produces results you cannot trust. The agent is not “blocked” by a permission setting. It is blocked because the ground under it has moved and SAP no longer knows the shape of it.

This is why SAP clean core has quietly become an AI-readiness question. The released API surface is the same surface upgrades depend on and the same surface AI depends on. Keep the core clean and that surface stays intact. Break it, and you lose both upgrade stability and AI adoption in one move.

The scale of the gap is worth sitting with. DSAG’s 2026 data puts SAP Business AI in production at roughly 3% of customers, against a wave of Joule agents and thousands of skills released through early 2026. The capability is shipping far faster than customers can adopt it. For most estates, the bottleneck is not the AI model or the licence. It is a core too modified for the AI to act on.

Clean core is not only about code

If you treat SAP clean core as a pure ABAP problem, you will fix half of it and wonder why the AI still struggles. Two of SAP’s six dimensions are data and integrations, and both gate AI as hard as code does.

AI agents ground their reasoning on the process and data they can see. A bloated, poorly governed data model gives them a noisy, unreliable surface to work from. A core carrying decades of dead transactional data is also expensive: HANA is licensed in step increments, so every uncontrolled terabyte of growth eventually triggers a jump to the next licence tier. Archiving that data out of the live database cuts HANA licensing cost and shrinks the core before any code work begins.

This is where a clean core strategy and SAP data management meet. Archiving reduces the live data footprint. Decommissioning legacy ECC after go-live ends the duplicate licensing you pay when you keep the old system alive “for reference.” Clean data is not a separate initiative from clean core. It is one of its six dimensions, and it is often the fastest cost win in the whole programme.

How do you move to a clean core strategy?

You extend through SAP’s extensibility model instead of modifying the core. SAP extensibility comes in three tiers, and the tier you choose decides whether your logic is AI-ready or not.

All three consume released APIs, which is what keeps them AI-addressable. The failure mode is not “we wrote custom code.” It is “we wrote custom code that modified the standard core or reached into internals.” Key-user extensibility, ABAP Cloud, and BTP extensions are the sanctioned routes; classic modifications are the ones a clean core strategy is built to eliminate.

For development leads, the concrete shift is ABAP Cloud: a restricted ABAP language scope that only allows released objects and public APIs, with governance enforced through the ABAP Test Cockpit. If your code passes the ABAP Cloud readiness checks, it is clean by construction. If it does not, that is your remediation backlog.

What does ABAP remediation involve?

ABAP remediation is the structured process of getting your existing custom code from wherever it is now to a clean-core-compliant state. It starts with analysis, not rewriting.

Run SAP’s Custom Code Migration app and the ABAP Test Cockpit with the S/4HANA and ABAP Cloud readiness variants across your estate. That gives you a full inventory of custom objects and flags every non-compliant pattern. From there, every object gets one of three verdicts.

• Keep. Standard config and key-user extensions that are already cloud-safe. Confirm against the readiness checks and leave them in place.
• Adapt. Custom logic that touches the standard core but has a clean rebuild path. Rebuild it in ABAP Cloud or as a side-by-side BTP extension using released APIs.
• Retire. Redundant, obsolete, or dead code with no business owner. Decommission it. The cheapest object to remediate is the one you delete instead of carrying into S/4HANA.

The retire column is usually larger than teams expect, and it is where the fastest progress hides. Most ECC estates carry duplicate Z-reports, one-off fixes, and enhancements whose original purpose no one can name. Cutting them shrinks the remediation backlog before a single line is rewritten.

Where clean core and your S/4HANA migration meet

The cheapest time to reach an SAP clean core is during your S/4HANA migration, not after it. A brownfield conversion that carries the full custom-code estate across unremediated simply moves the problem into a more expensive system. Every terabyte and every dirty object removed before cut-over compresses infrastructure cost, cloud subscription fees, and the go-live timeline.

Two dates make this urgent rather than theoretical. The Compatibility Pack for S/4HANA on-premise customers expired on 31 May 2026, closing functional gaps for those who moved to S/4HANA but not to cloud. And ECC mainstream maintenance ends on 31 December 2027, which means most estates are in migration planning now. Clean core is not a separate programme to schedule for later. It is a set of decisions you make inside the migration you are already planning.

For organisations already live on S/4HANA who carried the mess across, the sequence is reversed but the work is the same: remediate before you try to adopt AI, because the AI will keep failing on the objects you never cleaned.

Recommendations

• Treat SAP clean core as an AI-readiness prerequisite, not a tidy-up. Frame it to the business as the gate on every Joule and SAP Business AI capability you have licensed.
• Run a custom code assessment first. You cannot plan remediation without the Custom Code Migration and ATC inventory that tells you the size and shape of the estate.
• Sort every object into keep, adapt, or retire before writing anything. Delete aggressively; the retire column is your fastest win.
• Route all new development through key-user extensibility, ABAP Cloud, or BTP extensions. Ban modifications to the standard core as policy, not preference.
• Clean the data, not just the code. Archive dormant data and decommission legacy systems to shrink the core and cut HANA licensing cost.
• Do the code and data work inside your S/4HANA migration where the economics are best, not as a bolt-on afterwards.

Book an Assessment

Want to know which of your custom objects an AI agent could actually use today? A custom code assessment inventories the estate, sorts every object into keep, adapt, or retire, and tells you what reaching an SAP clean core will take before you commit to the work.