Object Classification A–D
SAP grades clean-core extensions A, B, C or D by API release status, upgrade safety and extensibility compliance — the clean core level concept, which replaced SAP’s earlier three-tier extensibility model in 2025. Here is the model, the full distribution across SAP’s published data, and how Clean-Core.io derives a grade for your custom code.
It is SAP's cloud-readiness classification for technical objects. A = released SAP APIs and extension points; B = classic SAP APIs, SAP-recommended; C = internal SAP APIs, conditionally clean; D = not-recommended objects and technologies, to be replaced. Clean-Core.io derives the grade from SAP-published states — the Cloudification Repository release states plus SAP's classicAPI/noAPI classification file — under a versioned rule of its own; it is an orientation, and ABAP Test Cockpit stays the authority. Only your own Z/Y objects, which SAP has not classified, get a heuristic estimate, labelled as one. It gives a clearer way to assess custom code and plan upgrade-safe SAP development than a binary clean/not-clean view.
From the three-tier model to levels A–D
The Cloudification Repository is the key governance tool for SAP Clean Core analysis. It classifies technical objects by API release status, upgrade safety and extensibility compliance. SAP’s clean core level concept replaced the earlier three-tier extensibility model with four levels:
Released SAP APIs & extension points
ATC (our reading): No messageReleased SAP APIs (local & remote) and extension points — ABAP Cloud on-stack, or side-by-side on SAP BTP. Fully supported and upgrade-stable.
Classic SAP APIs — SAP-recommended
ATC (our reading): Priority 3 · infoClassic SAP APIs and extension points that follow SAP recommendations — used where no Level A path is available.
Internal SAP APIs — conditional
ATC (our reading): Priority 2 · warningUses internal SAP objects/APIs — conditionally clean if verified via the changelog-for-SAP-objects approach before each upgrade.
Not recommended — replace
ATC (our reading): Priority 1 · errorNot-recommended objects & technologies — modifications, implicit enhancements, direct table writes, non-released access. Not clean; replace before upgrade.
The classification flow is simple: object identification → repository lookup → grade classification → remediation decision → Clean Core alignment.
The repository lookup merges two SAP files that answer different questions, and the order of that merge is a decision rather than a detail. The precedence rule is published in full, with the counts behind each branch and the objects where the two files disagree.
A–D across everything SAP publishes
Applying the rules above to SAP’s own two repository files grades 33,877 objects. This is a census of SAP’s published data — not a benchmark of any customer’s custom code, where the mix looks very different.
| Level | SAP state | Objects | Share |
|---|---|---|---|
| ACloud-ready | SAP statereleased | Objects24,893 | Share73.5 % |
| BClassic OK | SAP stateclassicAPI | Objects7,937 | Share23.4 % |
| CInternal | SAP statedeprecated with successor | Objects76 | Share0.2 % |
| DReplace | SAP statenoAPI · notToBeReleased · deprecated without successor | Objects971 | Share2.9 % |
Sources, so the figures can be reproduced: objectReleaseInfoLatest.json (sha256 407843e4, fetched 2026-10-01) and objectClassifications_SAP.json (sha256 70a9e6f4, fetched 2026-10-01), both from the SAP Cloudification Repository (Apache-2.0). Counted by Clean-Core.io v3.0.19. Objects appearing in both files are counted once, with the released state taking precedence.
How Clean-Core.io applies it
Catalog-backed · two-tierEvery grade carries its provenance, because the two are not equally strong. Where SAP has published a state for an object, the grade follows from that state under a fixed, versioned rule of Clean-Core.io's: released → A, classicAPI → B, noAPI and notToBeReleased → D, deprecated → C with a successor and D without. An SAP object listed in neither file is graded C, which is what the clean core level concept defines level C to be — SAP-internal, not classified for customer use. Only your own Z/Y objects, which SAP cannot have classified, fall back to a heuristic over access type, risk and object type, and they are labelled as estimated wherever they appear.
It remains not an authoritative SAP ATC classification and is not part of the signed audit pack. Verify every grade with SAP ADT / ATC for your specific target release — a grade is release-dependent, and an object released in 2025 is still unreleased against a 2023 target.
Used that way it speeds up first-pass triage and the technical-debt conversation — a starting point for the defensible A–D remediation plan you then confirm against SAP's own tooling.
For a hands-on walkthrough of the A–D model — how to classify each object and what to do with grade C and D code — see our SAP Community post: Clean Core Levels A–D: how to classify your custom ABAP ↗.
Why it matters
- Faster custom-code assessment
- Clear technical-debt control
- Upgrade-stable development
- Defensible A–D remediation plan
Frequently Asked Questions (FAQ)
What changed from the three-tier model to levels A/B/C/D?
SAP's Cloudification Repository governs which technical objects are clean-core ready. In 2025 SAP replaced its earlier three-tier extensibility model with the clean core level concept — four levels, A, B, C, D — driven by API release status, upgrade safety and extensibility compliance. It makes assessing custom code faster and technical-debt control clearer.
How does Clean-Core.io assign an A–D grade?
As an experimental preview estimate. It is a heuristic derived from the evidence the engine already computes — access type, risk level, object type and whether the object is custom. It is a fast orientation aid, not an authoritative SAP ATC classification, and it is not part of the signed audit pack. Every grade should be verified with SAP ADT/ATC for your target release.
What should I do with grade D objects?
Grade D objects (unreleased dependencies, direct writes to standard tables, kernel or dynpro usage) are the upgrade blockers. They should be replaced — mapped to a released API/CDS view, wrapped behind a clean interface, or re-architected — before the code can be considered Clean Core.