How the A–D level is derived
SAP publishes two files that answer two different questions. The level is a merge of both, and the order the merge happens in decides the answer for 32 objects where the two files disagree. That order is written out here, in the sequence the code checks it, with every count taken from the catalog rather than typed in.
levels 3c38976c5841 · latest@407843e4 · classifications-sap@70a9e6f4
The first part is the rule, the two after it are the data. The fingerprint is a hash over every one of the 640 inputs this derivation can tell apart and the level it returns for each, so changing one branch of the table below changes this string — and reordering branches without changing an answer does not. The pairs that follow are SAP’s own files, each named by the release we synced and the first eight characters of the checksum of the bytes SAP served. Quote the whole line when you quote a level.
The release file. If SAP will not release an object for ABAP Cloud but has named a successor for it, the level is not B — level B means 'acceptable where no level A path exists', and a named successor is that path. Of the 32 objects in this position, 31 carry a named successor, including CL_BCS and CL_HTTP_CLIENT.
The two files
Both come from SAP’s Cloudification Repository. They are near-disjoint: 190 of 33,877 objects appear in both, so the second file is additional coverage rather than a second opinion on the first.
Can ABAP Cloud use this object?
States released, deprecated and notToBeReleased, and the successors SAP names for the objects it is retiring.
25,467
objects
objectReleaseInfoLatest.json
latest@407843e4 · 25,467 entries · synced 2026-10-01
What does classic ABAP using it count as?
States classicAPI and noAPI — whether SAP considers the object fair game for classic extensions, or not for customer use at all.
8,600
objects
objectClassifications_SAP.json
classifications-sap@70a9e6f4 · 8,600 entries · synced 2026-10-01
Synced from the repository; catalog as of 2026-10-01. Those two checksums are the ones shortened into the rule version at the top of this page, so a level quoted with its version can be traced back to the exact bytes it was derived from.
The rule, in the order it is checked
Each row is one branch. The first one that matches decides, so a row only sees the objects the rows above it did not claim — which is what makes the order a decision rather than a formatting choice.
| # | SAP state | Level | Why |
|---|---|---|---|
| 1 | SAP statereleased | LevelA | WhySAP has released it for ABAP Cloud. This wins outright, including for the objects the classic file also names. |
| 2 | SAP statenotToBeReleased | LevelD | WhySAP will not release it. There is no level A path through this object, and in almost every case SAP names what to use instead. For a table the code only reads, see the access rules below. |
| 3 | SAP statedeprecated + successor | LevelC | WhyOn its way out, but SAP has named the replacement — usable while you migrate, with a deadline attached. |
| 4 | SAP statedeprecated, no successor | LevelD | WhyOn its way out with nothing named to replace it. Anything built on it has to be re-thought, not re-pointed. |
| 5 | SAP stateclassicAPI | LevelB | WhySAP classifies it as fair game for classic ABAP, and no release-file state has claimed it above. |
| 6 | SAP statenoAPI | LevelD | WhySAP classifies it as not intended for customer use. |
| 7 | SAP statea state neither file’s vocabulary covers | LevelUnknown | WhySAP keeps the state verbatim and can publish one this rule does not map. The file then says something rather than nothing, so the row below — which reads "listed nowhere" — does not describe it, and no level follows until the state is read and mapped on purpose. |
| 8 | SAP statelisted in neither file | LevelC | WhyAn SAP object with no published classification is what the level C definition describes — internal, usable with a changelog check before each upgrade. |
A customer object (Z*, Y*) carries no SAP classification at all, and neither does a namespaced object SAP does not list — those fall through to the engine’s own evidence and are labelled as estimated rather than looked up, with the one exception below.
When the code’s access changes the level
The table above grades an object by its name. An analysis also knows what the code does with a table — reads it, writes to it, or depends on its type without touching a row — and in the cases below that decides the level it shows. Everywhere else the access changes nothing, and the object keeps the level above. Where a row moves the level, the object’s own level is still shown beside it. These rows are part of the rule version at the top of this page.
| Object and access | Level | Why |
|---|---|---|
| notToBeReleased, read | LevelC | WhyReading a table or view SAP will not release, and that the classic file does not name, is using an internal SAP object — conditionally clean, with a changelog check before each upgrade. The successor SAP names is where to look, not a drop-in replacement. |
| notToBeReleased, written | LevelD | WhyWriting to it directly bypasses the application that owns the data. The level stays D, and a read successor is no write path. |
| notToBeReleased, referenced as a type | LevelC | WhyTABLES kna1, DATA … TYPE kna1, INCLUDE STRUCTURE kna1, SELECT-OPTIONS … FOR kna1-kunnr: the code depends on SAP’s internal structure without reading or writing a row. That is the same dependency on an internal object a read has, so it is the same level — not D, which says the application that owns the rows was bypassed. The read successor is no answer here: a CDS view does not replace a structure type. |
| SAP object, written directly | LevelD | WhyINSERT, UPDATE, MODIFY or DELETE on an SAP table or view — FROM TABLE included, and a dynamic name once the source resolves it — bypasses the application that owns the rows. That is level D whatever the object is on its own: a release is permission to use the object, not to change its rows behind the application, and an internal object is no cleaner for being written than for being read. The object’s own level is kept beside the D. Writing through SAP’s own path — EML on a business object, a BAPI, a released class — is not a direct write and keeps the level of what it calls. |
| customer table, read or written | LevelB | WhyYour own table or view (Z*, Y*). SAP’s files do not classify it, and the analysis has seen the whole dependency, so it is not Unknown: classic ABAP working on its own data is level B. A customer function or class the code only calls is not covered — its implementation was not read. |
Each level belongs to one object and one access. There is no level here for a program as a whole: a report that only reads released views still runs as classic ABAP.
What that produces, counted
Every pairing that occurs in the data, with the level it produces. Computed from the artifacts when this page was built — not maintained by hand.
| Pairing | Level | Objects |
|---|---|---|
| released | LevelA | Objects24,735 |
| classicAPI | LevelB | Objects7,937 |
| noAPI | LevelD | Objects473 |
| notToBeReleased | LevelD | Objects284 |
| deprecated | LevelD | Objects183 |
| released + classicAPI | LevelA | Objects158 |
| deprecated | LevelC | Objects75 |
| notToBeReleased + classicAPI files disagree | LevelD | Objects31 |
| deprecated + classicAPI files disagree | LevelC | Objects1 |
The 32 objects that look like a bug
Take CL_BCS, the classic class for sending mail. The classification file calls it classicAPI — an API classic ABAP may use, which on its own is level B. The release file calls it notToBeReleased and names CL_BCS_MAIL_MESSAGE as its successor. We publish D.
That reads as the release state wrongly overruling SAP’s own classification, and it is the reading two independent code reviews of this project arrived at in September 2026. The answer is in what level B means: acceptable where no level A path exists. Where SAP has named a successor, a level A path does exist, and calling the old object “SAP-recommended” would tell you to keep writing against something SAP has already replaced. Of the 32 objects in this position, 31 carry an explicit successor and one does not.
Reasonable people can disagree with that call — it is an interpretation of SAP’s level definitions, not a quotation of them. What should not happen is disagreeing with it by accident, which is why the object pages now show both files side by side and why this page exists at all.
What this level is not
- Not an ATC verdict. Each level carries an ATC severity in our data, and it is labelled as our reading rather than SAP doctrine. We have not found an SAP source that states the mapping outright. ADT/ATC against your target release is the authority; this is preparation for that check, not a substitute.
- Not part of the signed audit pack. The level is an orientation aid. A wrong grade must never become signed material, so it is deliberately excluded from what the signature covers.
- Not a guess when the data is missing. A state SAP publishes that the rule does not map, and a namespaced object neither file lists, return Unknown rather than a plausible-looking letter. An SAP object neither file lists is level C, because that is what SAP’s level C definition describes (see the rule table above).