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

Lesson 5 of 5

Clean core and why it matters to testers

9 min

For decades, SAP customers changed the standard system freely: modifying SAP’s own code, adding fields to SAP tables, and writing custom programs that read SAP’s internal tables directly. It worked, until the next upgrade. Every upgrade then became a project to find out what broke. SAP’s answer is the clean core principle.

What clean core means

Clean core means keeping the SAP standard system as close to standard as practical, and building company-specific logic in ways that SAP promises to keep stable across upgrades. In practice, that covers several things: following standard processes where they fit, keeping master and transactional data clean, integrating through documented interfaces, and, above all, extending the system only through released APIs and extension points.

A released API or extension point is one that SAP has published for customer use and committed to keep compatible. Code built only on those can survive an upgrade without rework. Code that reaches into SAP’s internal objects or modifies SAP’s own code has no such promise.

Three ways to extend without breaking the core

Key user extensibilityBusiness experts add custom fields, adapt forms and screens, or add simple logic with in-app tools, without traditional programming.
Developer extensibility (on-stack)Developers write ABAP Cloud code inside S/4HANA, using only released APIs and extension points.
Side-by-side extensibilitySeparate applications on SAP Business Technology Platform (SAP BTP) connect to S/4HANA through released APIs and events.
SAP’s extensibility model: three ways to add company logic while keeping the core upgrade-stable.

Clean core levels

In 2025, SAP published a clean core level concept that grades extensions from A to D instead of calling them simply clean or not. Level A uses only released APIs and extension points and is the target for new work. Lower levels use classic or internal SAP objects, with growing upgrade risk, and level D covers the riskiest techniques such as modifying SAP code. An extension is only as clean as its least clean part. Exact definitions are refined over time, so check SAP’s current documentation when your team classifies an extension.

Extension at ContosoApproachUpgrade risk
Custom field "Fleet contract ID" on sales ordersKey user extensibility (custom field)Low: SAP keeps the extension point stable
Validation that blocks orders above a fleet credit limitABAP Cloud logic in a released extension pointLow to moderate: test the logic, not the platform
Dealer portal for spare-parts ordersSide-by-side app on SAP BTP using released APIsLow for the core; test the interface at each upgrade
Old ECC program that writes directly to SAP tablesClassic code touching internal objectsHigh: may break at any upgrade and must be retested every time

How Contoso’s extensions line up against clean core

Read the levels as a ladder of risk. Level B adds SAP’s classic APIs, which are documented and generally stable but carry no formal cloud-style stability contract. Level C reaches into SAP internal objects, which can change without notice; SAP has said it will publish change information for such objects to help teams plan. Level D includes modifications, direct writes to SAP tables and implicit enhancements. Most long-running ECC customers arrive in S/4HANA with a mix of all four.

Why testers should care

Clean core is often presented as an architect’s topic, but its biggest payoff lands on testing. Every modification and every piece of code that reads SAP internals is something that might break at the next upgrade and must be regression tested. A clean core shrinks that list. Instead of retesting hundreds of custom objects, the team can focus on the company’s key business processes and its released extensions.

Critical and fragileTest first at every upgrade; plan to rebuild on released APIs.
Critical and stableKeep in the core regression set; usually passes, but too important to skip.
Minor and fragileCandidate for retirement; test if still used.
Minor and stableLight, periodic checks are enough.
Using clean core to prioritize regression testing.

The benefit is greatest in Public Edition, where the twice-yearly upgrade will happen anyway and only upgrade-stable extensions are allowed. In Private Edition and on-premise, Contoso has more freedom, but every exception to clean core is a line item on the regression list at each upgrade.

What would you do?

Contoso’s sales team asks IT to change an SAP standard program so that fleet orders skip a credit check. IT says they can do it quickly by modifying SAP code. You are the order-to-cash key user. What do you recommend?

Key points
  • Clean core keeps SAP standard close to standard and extends it only through released, upgrade-stable interfaces.
  • Three extension styles: key user, developer (ABAP Cloud on-stack) and side-by-side on SAP BTP.
  • SAP’s clean core levels grade extensions A (released only) to D (riskiest, such as modifications).
  • A cleaner core means a smaller, more predictable regression test at each upgrade.

Check your understanding · not graded

Lesson check

  1. 1. What is a released API?

  2. 2. Which clean core level is the target for new extensions?

  3. 3. Why does a clean core reduce regression testing?