What is SAP Clean Core? A Practical Guide for S/4HANA Projects
Clean core is SAP's strategic mandate for S/4HANA. This guide explains what it means, why it matters for migration projects, and how to measure your clean core compliance.
SAP clean core is the most important architectural concept for any S/4HANA project — and the most commonly misunderstood.
What clean core means
Clean core means keeping the SAP digital core free of modifications. All customisations must use:
- Released SAP APIs with C1 release status
- Approved extension points — BAdIs, enhancement spots, released CDS extension includes
- Side-by-side extensions on BTP for complex logic
The goal: a core that can be upgraded without re-testing every custom object, because no custom code reaches into SAP’s internals.
Why it matters
ECC-era ABAP development had no such constraint. Direct table reads, internal FM calls, core modifications, and Y-copies of standard programs were all common practice. This worked — until every upgrade became a project.
S/4HANA’s architecture enforces clean core through ABAP Cloud: a restricted language variant where attempts to access non-released objects fail at compile time. Migrating to S/4HANA is an opportunity to pay off this technical debt permanently.
The three-tier extensibility model
SAP’s clean core extensibility has three tiers:
Tier 1 — Key-User extensibility In-app customising: custom fields via the Custom Fields app, custom logic via the Custom Business Objects app, BAdI implementations. No ABAP required.
Tier 2 — Developer extensibility (ABAP Cloud)
On-stack ABAP development, but constrained to released APIs only. Objects developed with the ABAP for Cloud Development language version cannot access unreleased APIs at compile time.
Tier 3 — Side-by-side extensibility (BTP) Extensions built on SAP BTP that consume S/4HANA via released OData V4 APIs. Fully decoupled — no on-stack code.
How to measure clean core compliance
A clean core assessment should produce:
- Released API usage %: what proportion of your custom code’s object references point to C1-released APIs
- Modification count: direct modifications to SAP standard objects
- Deprecated object references: usage of objects removed or replaced in S/4HANA
- Extension-point compliance: custom exits and enhancements using approved extension points
s4ready.ai’s A1 Readiness Scan produces a Clean Core Score — a 0–100 composite with object-level breakdown and prioritised remediation steps.
Common clean core violations
| Violation | Example | Clean core replacement |
|---|---|---|
| Direct table read (deprecated) | SELECT * FROM MARA | I_Material CDS view |
| Internal FM call | CALL FUNCTION 'BAPI_*' without checking release status | C1-released BAPI or OData API |
| Core modification | Y-copy or enhancement to standard report | BAdI or side-by-side extension |
| Pool/cluster JOIN | JOIN on BSEG | I_GLAccountLineItem or ACDOCA |
The remediation path
For each violation type:
- Identify — A1 Readiness Scan flags every violation with the specific object and line
- Classify — determine the correct replacement (released CDS view, approved API, BTP extension)
- Remediate — A2 Auto-Remediation rewrites the flagged code to the released API, verified against your target system
- Test — A3 generates ABAP Unit tests for the remediated object
- Document — A4 produces updated technical documentation
SAP, S/4HANA, ABAP Cloud and related marks are trademarks of SAP SE.