Clean Core and the Released API Extension Model
Clean core means custom code extends S/4HANA only through APIs, CDS views, and extension points that SAP has formally released and guarantees stable across upgrades. Direct table access, modification of standard objects, and calls to internal (unreleased) function modules are no longer supported extension methods and are flagged by custom code checks as errors or warnings depending on system type.
This page covers how extension practice changes from ECC's open access model to S/4HANA's released-API contract, what breaks in custom reports and interfaces when that contract is enforced, and the order in which a conversion project must find and remediate non-compliant code. It focuses on what a technical team actually has to fix, not on the marketing case for clean core.
Published 16 Sept 2026· 1,049 words
Classic ECC behaviour
In ECC there was no formal boundary between what a developer was allowed to touch and what was internal to SAP. Custom ABAP routinely issued direct SELECTs against base tables such as BSEG, VBAK, or MARA, joined them freely with custom Z-tables, and called standard function modules regardless of whether they were meant for external use. BAPIs existed as the documented interface layer but using them was a convention, not an enforced rule; plenty of interfaces and reports bypassed them for performance or because the BAPI did not expose a needed field. Modifications to standard programs were made via user exits, customer includes, and in some shops outright core modification managed through SPAU and SPDD adjustments at every upgrade. Authorisations were built around transaction and table access, not around an interface contract. The result over years was tight coupling between custom code and SAP's internal implementation, invisible until an upgrade touched a table structure or a function module signature and something downstream silently stopped working.
S/4HANA behaviour
S/4HANA introduces a formal distinction between released and unreleased objects. Released APIs, CDS views, BAPIs, RAP-based services, and events are marked with a stable contract: SAP commits to backward compatibility for them across upgrades, with any deprecation communicated and given a transition period. Unreleased objects carry no such guarantee and can change or disappear without warning. ABAP Development Tools and the custom code check tooling can identify an object's release status directly, and system types built on the ABAP Cloud model enforce it as a hard error rather than a style preference. Extensibility is expected to happen through one of three supported channels: in-app extensibility for key users, on-stack developer extensibility using the ABAP RESTful Application Programming Model against released interfaces, or side-by-side extensions running on BTP that consume APIs rather than touching the database directly. Direct table access and calls into internal, unreleased modules are treated as clean core violations. The practical shift is that a developer can no longer assume that anything visible in SE11 or SE37 is fair game; visibility and permission to use are now two different things, and the tooling checks the second one explicitly.
Project impact
The effect lands hardest on code written under the old assumption that anything reachable was usable.
- Custom reports and month-end programs built on direct joins across finance or logistics tables fail or return wrong results once underlying structures change, because there was never a compatibility promise for those tables.
- Interfaces built on unreleased BAPIs or RFCs need redesign; teams discover this only when the custom code check runs, not before.
- Authorisation concepts tied to table and transaction access do not map cleanly onto API-based extension, forcing a parallel redesign of the authorisation model.
- Developers accustomed to debugging or patching via direct table access lose that reflex and need retraining on the extensibility model.
- Custom code check results routinely surface thousands of findings across a mature ECC landscape, most owned by teams who have not touched the code in years.
- Business-owned Z-reports maintained outside central IT governance are frequently the last ones found, because nobody currently tracks who built them or why.
Migration actions
Remediation has to be sequenced, not tackled as one undifferentiated backlog.
- Run the custom code check against the released API allowlist early, well before the technical conversion, and treat the error-severity findings as a hard gate rather than a nice-to-have.
- Classify findings by severity and by business criticality of the object they sit in, separating true blockers from cosmetic warnings.
- Replace direct table reads with the nearest released CDS view or BAPI equivalent, checking for functional gaps where the released interface does not expose the same fields as the raw table.
- Redesign custom interfaces built on unreleased RFCs, moving them to released services or to a side-by-side extension on BTP where appropriate.
- Rebuild authorisation checks that were tied to table or transaction access so they align with the API-based extension model.
- Retrain the ABAP team on the extensibility channels available under the ABAP Cloud model before assigning new remediation work, otherwise fixes reintroduce the same coupling in a new form.
- Regression test every remediated interface and report under realistic volume, not just functionally, before cutover.
- Put governance in place afterward so new custom development is checked against the released API list at build time, not discovered at the next upgrade.
Whose problem this is
Primarily a technical problem, owned by the ABAP development and architecture team, since it concerns which interfaces custom code is permitted to call. The decision about which non-compliant objects to fix versus retire is a joint call between architecture governance and the functional owners who rely on the affected reports and interfaces.
Common pitfalls
Several failure modes show up consistently on real projects.
- Custom code check findings get treated as informational and deferred, then turn into blocking errors when the target system type enforces the ABAP Cloud restrictions strictly.
- Individual interface fixes pass unit testing but fail under month-end concurrency because the released API equivalent has different rate limits or lacks a bulk variant the old direct-table logic relied on.
- A released API that looks equivalent to the old table access sometimes returns a subtly different data set, for example excluding records visible via direct access but filtered by the API's own business logic, producing silent reconciliation differences after go-live.
- Long-tail reports maintained by business users rather than IT are missed during scoping and only surface once they break in production.
- Teams assume released status is permanent; SAP can still deprecate a released API with a notice period, so a one-time scan before go-live is not sufficient and periodic re-scanning needs to become routine.
Related SAP objects
Reviewed pages this object connects to in the ERPClimb knowledge graph.
Source: ERPClimb — https://erpclimb.com/sap-s4hana-changes/clean-core-and-the-released-api-model-for-extensionsERPClimb is an independent platform and is not affiliated with SAP SE. Reference pages are written and reviewed by SAP consultants for learning and troubleshooting.