Clean Core Principles
The foundational philosophy behind SAP's approach to S/4HANA extensibility — keep the core clean, extend through released APIs, and ensure every customisation survives the next upgrade.
Three-Tier Extensibility Model
SAP's clean core extensibility model separates standard SAP code (Tier 1 — read-only) from in-system extensions (Tier 2 — released extension points) and side-by-side extensions (Tier 3 — BTP, released APIs only). Each tier has a strict API contract.
Executive Summary
Every S/4HANA system accumulates customisations over time. Without governance, those customisations use undocumented SAP internals that break during upgrades. Clean Core replaces ad-hoc customisation with a governed, API-first extensibility model backed by SAP's 10-year API stability contracts (C1 release). The result: upgrades become routine operations, not multi-year projects.
The 5 Dimensions of Clean Core
All five dimensions must be addressed. Cleaning only extensions while leaving RFC-based integrations in place is not clean core — it is partial compliance that will still cause upgrade failures.
Use SAP Best Practice processes. Avoid "shadow IT" workarounds. Map custom processes to available SAP standard processes before building extensions.
Clean master data (no duplicate Business Partners, consistent material master). Data quality gates before migration. SAP Migration Cockpit compliance.
Replace all point-to-point RFC/IDoc with released APIs and Integration Suite. Retire all ALEREMOTE user destinations. Use event-driven integration (Business Events).
Only Tier 1/2/3 extensibility model. Zero modifications to SAP standard objects. ATC (ABAP Test Cockpit) CI/CD gate enforces this.
SAP Cloud ALM for change management. No manual transport editing. Automated testing via ABAP Unit and OPA5 (Fiori tests).
SAP API Release Contracts
Every SAP API, class, method, and CDS view is assigned a release contract. The contract determines whether customer code may use it. Only C1-released APIs are permitted in clean core extensions.
| Contract | Code | Description | Safe to Use |
|---|---|---|---|
| Released | C1 | SAP guarantees this API for 10+ years | Yes — Tier 1 |
| System-internal | C0 | SAP internal only — not for customer use | Never |
| Deprecated | X | Will be removed in a future release | Migrate away |
| Not released | (none) | No contract — can change anytime | Never |
Enterprise Example: DEWA Clean Core Journey
- Total custom ABAP objects assessed
- 8,000
- Already clean (C1 API usage)
- 23%
- In-system extensions (released BAdIs)
- 51%
- Tier 3 candidates (move to BTP)
- 26%
- Assessment tool used
- SAP Clean Core Assessment
- S/4HANA version
- 2023 OP
DEWA's roadmap migrates the 26% Tier 3 candidates to CAP over three release cycles (2023 OP → 2025 OP → 2027 OP). Each cycle targets the highest-complexity extensions first, using fit-to-standard workshops to eliminate extensions where SAP standard now covers the requirement.
Best Practices
Run Clean Core Assessment before every S/4HANA upgrade project to establish a compliance baseline.
Set ATC (ABAP Test Cockpit) as mandatory CI/CD gate in ADT and transport management — block transports on BLOCKER findings.
Create a Clean Core governance board with SAP Basis + Development + Architecture representation.
Distinguish between "technical" clean core (API compliance) and "business" clean core (process standardisation) — both matter.
SAP Activate embeds clean core checks at every phase gate — do not skip fit-to-standard workshops.
Never grant SE80 modification access to developers in production-ready landscapes.