SAP has been formalising its Clean Core strategy progressively since 2023, then reinforced it at SAP Sapphire 2026 with the announcement of an official certification programme for BTP extensions. For CIOs mid-migration to S/4HANA, or still in the scoping phase, the question is no longer whether Clean Core applies — it does — but how to integrate it into your transformation programme without underestimating the remediation effort on existing custom code.
This guide covers the SAP doctrine as it stands in 2026: the 5 Clean Core dimensions, the extensibility level model, the custom code audit methodology, and the strategic trade-offs between Greenfield, Brownfield and BTP.
What is SAP Clean Core? The Official Doctrine Explained
Definition: an unmodified standard core, extensible only through published APIs
SAP Clean Core refers to an S/4HANA system whose application core has not been directly modified. No SAP table is manually altered, no standard programme is overridden, and no unpublished internal object is called from client code. All extensions run exclusively through APIs officially published by SAP and documented in the SAP Business Accelerator Hub.
The principle sounds straightforward. In practice, years of custom development — Z objects, BADI modifications, overrides of standard programmes — have left deep marks in virtually every existing SAP ECC system. Moving to Clean Core therefore implies a remediation programme, not merely an architectural decision.
The 5 dimensions of Clean Core
SAP structures its doctrine around five interdependent dimensions, published in its official whitepaper “5 guiding principles of clean core” from December 2025:
-
Processes: business processes follow SAP standards as closely as possible. Every deviation must be justified and documented. The goal is to reduce complexity and accelerate core updates.
-
Extensions: all extensions rely exclusively on published APIs. Client code must not call SAP internal objects. Extensions use either ABAP Cloud (on-stack) or SAP BTP (side-by-side).
-
Data: data governance must be formalised. A continuous quality model is required to ensure consistency, compliance, and reliability of business data.
-
Integrations: all new interfaces use published APIs (OData, SOAP) via SAP Integration Suite, rather than BAPIs or direct RFC calls to internal objects.
-
Operations: maintaining Clean Core over time requires automated transport controls, structured regression testing, and continuous governance through compliance KPIs.
Why SAP is pushing this strategy: the economics of public cloud
The Clean Core strategy responds to a business imperative for SAP: making automatic updates of the S/4HANA Cloud Public Edition core technically feasible. In a shared SaaS model, SAP cannot deliver regular updates if every customer has a personalised core. SAP CEO Christian Klein confirmed at SAP Sapphire 2026 that the cloud transformation of its customer base drives growth through 2030.
For public cloud customers (SAP S/4HANA Cloud Public Edition, RISE with SAP), Clean Core is a de facto constraint: the system technically prevents direct modifications to the standard. For private cloud or on-premise customers, it remains recommended but not technically enforced — even though SAP makes it a prerequisite on its support roadmap.
Clean Core does not mean zero custom development
A common pitfall in migration projects is conflating Clean Core with the complete absence of bespoke development. This misreading leads to blanket refusals of legitimate development requests, followed by manual workarounds that generate undocumented technical debt.
Clean Core permits custom development, provided it goes through the official channels: ABAP Cloud for on-stack extensions, SAP BTP CAP or Kyma for side-by-side extensions. The extensibility surface is broad. What changes is the route, not the capability to develop.
The SAP Extension Ecosystem: What Is Permitted in 2026
SAP BTP: the core building blocks
SAP Business Technology Platform (BTP) is the official extension platform. It brings together several development environments:
- SAP Cloud Application Programming Model (CAP): a Node.js and Java framework for building data-centric business applications. This is the recommended path for rewriting complex ABAP extensions that cannot remain on-stack.
- Kyma: an open-source Kubernetes environment hosted on BTP. Preferred for stateless microservices and asynchronous integrations with third-party systems.
- SAP Integration Suite: the official successor to SAP Process Orchestration (PO/PI). All new interfaces must run through Integration Suite, using published APIs.
- SAP Build: a low-code environment for creating Fiori applications or workflows without ABAP code, accessible to less technical teams.
ABAP Cloud vs ABAP Legacy: released APIs vs unreleased objects
ABAP Cloud is the successor to classic ABAP in a Clean Core context. The fundamental difference: ABAP Cloud syntactically allows only APIs officially released by SAP (source: SAP Community, Clean Core Extensibility). Any attempt to call an unreleased object produces a compile-time error.
Released APIs are documented in the SAP Business Accelerator Hub (api.sap.com). They constitute the official, verifiable, and SAP-maintained extensibility surface between releases.
Classic ABAP (referred to as “Legacy”) continues to work in existing systems, but all new extensions should use ABAP Cloud to remain within the Clean Core perimeter.
The A, B, C, D level model (published August 2025)
In August 2025, SAP formalised a four-level model to qualify the Clean Core compliance degree of an extension or system:
- Level A: full compliance. The core remains standard; all innovations operate outside the kernel via ABAP Cloud or BTP. This is the target level for public cloud projects.
- Level B: partial compliance, BTP side. Extensions have been moved to SAP BTP, but some legacy calls remain. Acceptable in private cloud; to be rationalised progressively.
- Level C: rationalisation in progress. Part of the code has been cleaned, but legacy code persists with incompatibility risks during upgrades.
- Level D: non-compliant. The system accumulates years of unmanaged customisation, including direct modifications to the standard. Upgrades are blocked or prohibitively expensive.
This model replaces the older binary “clean / not clean” framing and enables progressive governance. For project teams, it serves as a communication tool with business and finance stakeholders: Level D is a programmatic risk; Level A is a governance objective.
Side-by-side vs in-app extensions: when to use which
In-app extensions (on-stack) via ABAP Cloud: recommended when the extension must operate within the S/4HANA transaction, access SAP data directly, or be deployed without network latency. Typical examples: business data validations, transaction-exit trigger logic, lightweight Fiori extensions.
Side-by-side extensions via BTP: recommended when the extension is a genuine functional subsystem, involves third-party cloud services (AI, IoT, OCR, e-signature), or needs to evolve independently of the SAP release cycle. Examples: supplier portal, advanced configuration engine, bespoke analytical reporting tool.
The choice between the two is not binary. A mid-scale migration project typically mobilises both extension types, with a case-by-case trade-off based on criticality, latency, and dependency on real-time SAP data.
Impact on SAP ECC to S/4HANA Cloud Public Migrations
Inventorying existing Z objects: how to classify them
Before any migration, a full audit of custom code is essential. SAP provides two integrated tools for this work:
- SAP Readiness Check: available via the READINESS_CHECK transaction or through the cloud. It analyses the existing ECC system, identifies impactful S/4HANA simplifications, and lists Z objects that call structures or functions removed or altered in S/4HANA.
- SAP Custom Code Migration App: a standard Fiori application available in the BTP catalogue. It scans unreleased ABAP objects, classifies them by risk level, and recommends remediation paths (retire, migrate to ABAP Cloud, rewrite on BTP).
The standard classification taxonomy has four categories:
- Objects to retire: obsolete code, never executed in production, or replaced by S/4HANA standard functionality.
- Objects to rewrite on BTP: complex functionality that must evolve independently of the core.
- Objects to migrate to ABAP Cloud: legitimate on-stack extensions that must move to published APIs.
- Objects to retain temporarily: code still needed, pending a standard or BTP equivalent.
In practice, a significant share of Z objects identified in the audit corresponds to code that has never been called in production or to functions now covered by the S/4HANA standard. Systematically processing these reduces the migration scope before development work even begins.
Which modules carry the highest custom code burden
The modules most likely to carry substantial custom code are those that historically received the most bespoke development:
- FI/CO: custom reporting layouts, period-close logic, integrations with external consolidation tools.
- MM/SD: procurement approval workflows, complex pricing condition management, legacy EDI interfaces.
- PP: custom planning logic, MES/SCADA interfaces, atypical production order handling.
Payroll (PY) modules and HR-core developments often carry the heaviest technical debt, owing to regulatory complexity and the frequency of local adaptations.
The real cost of custom code remediation
The cost of a Clean Core programme is difficult to generalise. It depends directly on the volume of Z objects identified, their complexity, and the available ABAP Cloud and BTP expertise.
What project experience shows consistently: projects that underestimate clean-up work in the scoping phase pay for it through project overruns or deferred technical debt. A rigorous audit using the Custom Code Migration App, conducted before the migration scope is contractually defined, is the best preventive investment.
Global systems integrators with BTP specialisation — Capgemini, Accenture, Deloitte, IBM, Wipro — publish case studies that provide order-of-magnitude estimates by system size and industry. These ranges remain estimates to be refined by each organisation’s own audit.
Greenfield vs Brownfield vs Bluefield: does Clean Core change the recommendation?
Clean Core influences advice on migration strategy:
- Greenfield (full reimplementation): naturally aligned with Clean Core, since you start from the standard with no inherited technical debt. It requires redefining all business processes — a complete transformation project.
- Brownfield (technical conversion of the existing system): Clean Core adds a mandatory up-front remediation step. Without it, the converted system remains non-compliant and the public cloud benefits are inaccessible.
- Bluefield (selective, partial data and process migration): well-suited when you want to combine Brownfield speed with Greenfield cleanliness. Clean Core integrates naturally into the selection of processes to migrate.
For mid-market and enterprise organisations targeting public cloud, Greenfield or Bluefield remain the most coherent approaches given Clean Core constraints. Brownfield alone, without a serious remediation programme, frequently produces superficial compliance that becomes costly at the first major upgrade.
A Step-by-Step Methodology for Adopting Clean Core
Step 1: Audit your existing custom code
Run SAP Readiness Check and the Custom Code Migration App on the production system (or a recent copy). These tools provide a comprehensive map of Z objects, classified by S/4HANA incompatibility risk and by type of access to unreleased APIs.
Do not delegate this audit entirely to the systems integrator: the internal team must validate the identified object list with business process owners, to distinguish business-critical code from dead code.
Step 2: Functional classification and remediation decision
For each identified object, decide: retire, migrate to ABAP Cloud, rewrite on BTP, or retain temporarily. This decision is as much functional as technical. It must involve process owners, not just developers.
Build a decision register with the owner of each object, the justification for the choice, and the planned treatment date. This register becomes the Clean Core programme’s governance tool.
Step 3: Build on BTP or migrate to ABAP Cloud
For extensions to be developed on BTP:
- BTP CAP (Node.js or Java) for business applications with a Fiori interface or REST API.
- Kyma for microservices, asynchronous processing, and integrations with third-party cloud services.
- SAP Integration Suite to replace all existing RFC/BAPI interfaces with published APIs.
For extensions to be maintained on-stack: migrate to ABAP Cloud Developer Tools and replace unreleased calls with APIs documented in the Business Accelerator Hub.
Step 4: Regression testing
The move to Clean Core modifies technical behaviour even when functional logic is preserved. A regression test plan must cover all migrated extensions, with validation by business teams, not only IT.
Automating regression tests (ABAP Unit Tests, Fiori automation tooling) is a sound investment: it reduces the cost of future release cycles and provides the essential safety net for automatic core upgrades.
Step 5: Long-term governance via Custom Code Management
Clean Core is not a one-time state achieved permanently. SAP offers Custom Code Management as a continuous discipline: regular monitoring of new development, integration of compliance controls into CI/CD pipelines, and reporting into a centralised dashboard.
At SAP Sapphire 2026, SAP announced the Clean Core Certification Programme, which formally certifies BTP extensions as compatible with S/4HANA Cloud updates across a minimum of three consecutive release cycles. This certification is becoming a selection criterion for partner solutions and a governance argument for IT leadership.
Concrete Benefits of a Clean Core System
The benefits observed across projects that have reached Level A or B in the compliance model:
Automatic core updates: SAP can deliver new capabilities — including the 50+ Joule assistants announced at Sapphire 2026 — without being blocked by standard modifications. This is the most direct benefit of the public cloud model.
Lower custom code maintenance cost: Z code well-encapsulated in BTP CAP is simpler to test, document and evolve than Z code embedded in the core. The maintenance budget for custom code decreases as the BTP registry matures.
Faster adoption of embedded AI: at SAP Sapphire 2026, Joule Studio 2.0 was announced GA with capabilities for suggesting extension refactoring. These features are prioritised for Clean Core public cloud systems. A Level D system will not have access.
Reduced risk in security audits: an unmodified standard core is simpler to audit and certify (SOC 2, ISO 27001) than a system with direct SAP code modifications. The attack surface is more predictable.
Better readability for teams and integrators: a clear BTP extension register is transferable during integrator changes or when new members join the IT team.
Common Objections and How to Address Them
Four objections arise consistently during the scoping phase:
“BTP costs too much on top of S/4HANA licence fees.” This is a legitimate concern. BTP costs — licences, compute, integration — do add to the TCO. They must be factored into the business case from the scoping phase, not after contractualisation. An incomplete TCO for BTP is one of the most frequent sources of mid-project budget revisions.
“Some business requirements cannot be covered by BTP.” In the majority of cases, this objection reflects insufficient analysis of the available published APIs. The Business Accelerator Hub lists several thousand published APIs covering every SAP module. Verify what exists before concluding that BTP cannot respond.
“Our systems integrator is not trained in BTP CAP.” This is a real risk. BTP CAP and Kyma skills are still unevenly distributed across the integrator ecosystem. Partner selection for a migration must explicitly include a BTP skills assessment, with references from comparable projects measured by number of Z objects treated.
“We lose control over core evolution if SAP can update it.” This risk is managed through published APIs: SAP makes a contractual commitment to maintain the compatibility of released APIs across versions. Extensions that use exclusively published APIs do not break during upgrades. This is precisely the benefit of the model, formalised in the Clean Core Certification Programme.
Clean Core and RISE with SAP: the All-in-One Package
RISE with SAP is SAP’s commercial offering that bundles S/4HANA Cloud Public Edition, BTP, infrastructure management, and transformation services into a single contract.
Within the RISE framework, Clean Core is not optional: the public cloud environment technically enforces the use of published APIs. SAP includes Clean Core governance tools in RISE: Custom Code Migration App, SAP Readiness Check, and access to SAP Signavio for business process analysis.
GROW with SAP is the variant for mid-market organisations (with less complex processes and lower SAP footprints): Clean Core constraints are identical, but the volume of Z objects to treat is generally smaller and migration timelines are shorter.
For large enterprises with legacy ECC systems and significant volumes of custom code, RISE is not a shortcut. The Clean Core remediation programme precedes the migration, and its cost must be budgeted separately from RISE licences. Organisations that integrate this into the initial business case avoid the most common budget surprises.
For a deeper look at evaluating your dependency on the SAP ecosystem before signing a RISE contract, read our guide on ERP vendor lock-in: how to assess your dependency and plan your exit strategy.
To go further, read our SAP S/4HANA vs Oracle Cloud ERP 2026 comparison and our analysis of why S/4HANA migration is urgent for mid-market organisations in 2026.
