Clean core extensibility explained: tiers, released APIs and classic modifications

The idea behind clean core

A clean core means that the SAP standard is not modified and that extensions only use stable, documented interfaces. The benefit is predictable upgrades: when an extension depends only on released objects, a new release is far less likely to break it.

The tier model

SAP has described extensions in a tiered model:

• Tier 1 — cloud-ready extensions. Developed with ABAP Cloud (restricted language version) or side-by-side, using only released APIs and extension points.
• Tier 2 — cloud API enablement. Wrappers around classic, not-yet-released functionality that expose it to tier 1 code in a controlled way.
• Tier 3 — classic ABAP extensions. Classic development that may access unreleased objects or modify standard code. This is where upgrade risk concentrates.

SAP has since refined this guidance into more granular clean core levels. Always check the current SAP documentation for the classification that applies to your release.

Typical findings in existing code

• Direct database writes to SAP standard tables instead of using released APIs.
• Use of objects without a release contract, which can change without notice.
• Modifications and implicit enhancements in standard code.
• Dependencies on objects that are deprecated in the target release.

How to assess your landscape

1. Build an inventory of custom objects and their dependencies on SAP objects.
2. Classify each dependency by release status (released, deprecated, not released).
3. Prioritise objects with direct table mutations and modifications.
4. Plan successors: released CDS views, released APIs or extension points.

ERP Preflight's Clean Core Object Guard classifies custom code and its dependencies deterministically and records each finding with file, line and hash evidence. See Migration & Clean Core.