Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 1 of 5

Clean core and testing economics

10 min

Listen to this lesson

0:00 / 7:38

Every extension is a promise to keep working after the next SAP release. Clean core is SAP's name for keeping those promises cheap: extensions built on stable, documented interfaces survive upgrades with little effort, while extensions that reach into SAP internals have to be found, analyzed and retested every time. For a test lead, clean core is not an architecture slogan. It is the main driver of how much regression each upgrade costs.

The clean core levels

In August 2025 SAP described a four-level model for judging extensions (SAP News Center). The levels describe how an extension is built and how closely it is coupled to SAP's internals:

LevelWhat it meansTesting consequence
A: Extend with SAP BuildFully compliant. Only publicly released, stable SAP interfaces with formal stability contracts, on-stack with ABAP Cloud or side-by-side on SAP BTPTargeted regression of the extension's behavior; interface breakage is unlikely by design
B: Leverage classic APIsCompliant. Also uses SAP's classic APIs, which are documented and generally upgrade-stableRegression plus watch for changes to the classic APIs used
C: Accesses internal objectsPartially compliant. Uses SAP internal objects, mainly in legacy scenarios; SAP provides a changelog for SAP objectsImpact analysis every upgrade; retest wherever an internal object changed
D: Not recommendedNot clean. Modifications, write access to SAP tables, implicit enhancementsHighest risk: adjust and retest on every upgrade, plan to remediate

SAP's clean core levels, summarized from SAP News Center (August 2025), with the testing consequence for each.

The level is set by the weakest dependency an extension has, so one table read or modification pulls an otherwise clean extension down.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402
Remediate or retireLevel C/D, low value: cheapest to remove or rebuild
Top regression priorityLevel C/D, critical: test every upgrade, fund remediation
Light touchLevel A/B, low value: automated developer tests only
Automate end to endLevel A/B, critical: stable target for full regression automation
Clean core level and business criticality together decide where regression effort goes.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

Why levels change the regression bill

A released API comes with a stability contract: SAP commits to keeping it compatible. When an upgrade arrives, an extension that only uses released APIs needs its own behavior retested, but you don't have to investigate whether SAP changed the objects it depends on. An extension that reads internal tables or implements a modification has no such promise. Each upgrade, someone must find out whether the objects it touches changed, adjust the code (for modifications, through the modification adjustment tools), and retest. Multiply that by hundreds of objects from twenty years of ECC development and the upgrade cost is mostly custom code analysis and retesting.

  1. Upgrade announcedNew S/4HANA release or feature pack stack
  2. Level A extensionsRun automated tests; no dependency analysis needed
  3. Level B extensionsCheck the classic APIs used; run tests
  4. Level C extensionsAnalyze changed internal objects; adapt; targeted retest
  5. Level D extensionsAdjust modifications and enhancements; full retest of affected processes
The lower the level, the more work each upgrade triggers before testing can even start.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

Contoso's starting point

Contoso's system conversion carried its ECC custom code into S/4HANA. Kenji's team found the full spread: a new RAP-based app for core return agreements built in ABAP Cloud (level A), interfaces calling BAPIs (level B), custom reports reading SAP tables directly (level C), and an old modification in sales order pricing (level D). The conversion itself is not the moment to rebuild everything; the program's job is to convert safely. But the clean core level of each object should be recorded now, because it decides how much every future upgrade will cost Priya's team.

Contoso's converted code spans all four clean core levels, and recording each object's level now sets the cost of every future upgrade.
The Sign-Off Table · thesignofftable.com/academy/sap-tst-402

What would you do?

Grace asks Priya to estimate regression effort for the first feature pack stack after go-live. Kenji's inventory of the 7,500 in-scope objects shows 1,200 at level A, 4,000 at level B, 2,000 at level C and 300 at level D. What should Priya base her estimate on?

Key points
  • SAP's clean core levels A–D describe how tightly an extension is coupled to SAP internals.
  • Released APIs come with stability contracts; internal objects and modifications do not.
  • The lower the level, the more analysis, adjustment and retest each upgrade triggers.
  • Clean core reduces upgrade risk but does not replace testing the extension's own logic.

Check your understanding · not graded

Lesson check

  1. 1. Which clean core level covers modifications and write access to SAP tables?

  2. 2. Why does a level A extension usually need less upgrade effort?

  3. 3. What characterizes level C?

  4. 4. Does clean core compliance remove the need to test an extension?