Object Classification A–D
SAP grades clean-core extensions A, B, C or D by API release status, upgrade safety and extensibility compliance — superseding the older Tier 1/2/3 model. 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's own published object data — the Cloudification Repository release states plus SAP's classicAPI/noAPI classification file — so a graded object is a lookup, not an estimate. It gives a clearer way to assess custom code and plan upgrade-safe SAP development than a binary clean/not-clean view.
From Tier 1/2/3 to A/B/C/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. The community has moved from the older Tier 1/2/3 wording to a clearer four-grade cloud-readiness scheme:
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.
A–D across everything SAP publishes
Applying the rules above to SAP’s own two repository files grades 32,103 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 | released | 23,139 | 72.1 % |
| BClassic OK | classicAPI | 7,936 | 24.7 % |
| CInternal | deprecated with successor | 69 | 0.2 % |
| DReplace | noAPI · notToBeReleased · deprecated without successor | 959 | 3.0 % |
Sources, so the figures can be reproduced: objectReleaseInfoLatest.json (sha256 fb0df9f2, fetched 2026-07-01) and objectClassifications_SAP.json (sha256 0081fb9c, fetched 2026-08-26), both from the SAP Cloudification Repository (Apache-2.0). Counted by Clean-Core.io v2.7.0. 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 is a lookup: 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 Tier 1/2/3 to A/B/C/D?
SAP's Cloudification Repository governs which technical objects are clean-core ready. The classification of released/recommended objects moved from the older Tier 1/2/3 wording to a four-grade cloud-readiness scheme — 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.