SAP Clean Core: Levels, Principles, How to Get There

SAP clean core determines how quickly your S/4HANA landscape can take each upgrade and how quickly new SAP capabilities reach your business. This guide explains SAP’s clean core levels A to D and the five principles behind them. It also covers how to assess where your landscape stands today, and how to get clean and stay clean without disrupting critical processes.

Key Takeaways

• SAP clean core keeps the ERP core standard and upgrade-safe, with custom logic built on released APIs, ABAP Cloud, or SAP BTP.
• SAP’s clean core level concept rates every extension from Level A (clean, the strategic direction) to Level D (not clean core), and it replaced the three-tier extensibility model in August 2025.
• Clean core rests on five principles: processes, extensibility, data, integration, and operations.
• A clean core shortens every S/4HANA upgrade and gives the business faster access to SAP’s continuous innovation, including embedded AI.
• SAP frames the work as “get clean” and “stay clean”: reach a clean core object by object, then keep it clean change by change after go-live.

What Is SAP Clean Core?

SAP clean core is an approach that keeps the S/4HANA core as close to standard as possible, with custom logic moved into upgrade-safe extensions built on released APIs, ABAP Cloud, or SAP BTP. Clean core keeps your customization outside the core, so the differentiating logic your business depends on stays in place.

SAP describes clean core as a set of guiding principles for continuous business transformation, and it names five of them:

• Processes: stay as close as possible to the SAP standard to reduce complexity.
• Extensibility: decouple extensions from the core with released APIs, using governance to choose between on-stack and side-by-side options on SAP BTP.
• Data: keep data clean and compliant through continuous effort and an established data governance model.
• Integration: connect systems through reliable, standardized, and future-ready approaches.
• Operations: embed best practices in governance, people, processes, and tools.

SAP also splits the work into two phases. “Get clean” is the one-time effort to bring existing custom code and modifications to a clean state, and “stay clean” is the continuing practice that keeps new changes inside the same boundaries. The rest of this guide follows that structure.

To see how these ideas apply, suppose a consumer goods group has three regional ECC systems, each carrying a decade of custom code, and plans to merge them into one S/4HANA system through RISE with SAP. Before the scope is signed, the head of SAP asks the architecture team how much of the group’s custom code can come across as it is. The example is illustrative, and we will follow it through the rest of the guide, starting with how SAP rates custom code.

What Are the SAP Clean Core Levels A to D?

SAP rates every extension from Level A to Level D based on upgrade safety and architectural integrity. Levels A and B count as clean core, Level C is conditionally clean, and Level D is not clean core.

SAP Note 3578329 is SAP’s single source of truth for the levels, so it is the reference your architects and SI will point to. The level concept replaced the earlier three-tier extensibility model in August 2025.

In our group, the promotion pricing enhancement reads an internal SAP table, so it sits at Level C, while the trade promotion settlement report writes straight into standard tables, so it sits at Level D. The next section shows how they were found.

Level C exists so customers can move at their own pace. Teams keep governing and documenting legacy code at that level while they remediate it, and SAP provides a changelog for SAP objects so upgrade impacts on Level C objects are visible in advance.

Why Does SAP Clean Core Pay Off for S/4HANA Upgrades?

A clean core turns each S/4HANA upgrade into routine maintenance and gives the business faster access to SAP’s continuous innovation, including embedded AI. The benefits show up in upgrade effort, AI readiness, and the RISE with SAP methodology.

• Upgrade cadence: SAP moved S/4HANA to a base release every two years, starting with S/4HANA 2023, with feature packs planned about every six months during the first two years of a release. Every Level C or Level D object is a candidate for retesting at each of those steps.
• AI readiness: a July 2026 SAPinsider contributor post argues that AI depends on clean data models, standardized processes, and predictable system behavior, which makes clean core the foundation for SAP’s AI roadmap. That is the author’s view, and SAP has not published it as a requirement.
• AI in practice: the DSAG Investment Report 2026, covering nearly 200 companies in Germany, Austria, and Switzerland, found that 77% of productive AI scenarios run on non-SAP solutions. DSAG’s CEO links getting SAP-based scenarios to full value with a “clean core ready” landscape, as CIO.com reports.
• RISE with SAP: clean core is built into the RISE with SAP methodology, with quality gates at the end of every project phase that review whether the clean core principles were followed, and a success plan in SAP Cloud ALM.
• ECC timeline: with ECC mainstream maintenance ending in 2027 and optional extended maintenance to 2030, as covered in Lightrun’s SAP AMS guide, the migration is the natural point to set clean core boundaries.

For our group, that is why the question comes before the scope is signed: the merge decides which custom objects enter the new system, so it is the cheapest moment to set the boundaries.

How Do You Run an SAP Clean Core Assessment?

An SAP clean core assessment looks at four things for every custom object: its clean core level, whether it is used, what depends on it, and how critical the business process it supports is. Together they show where the landscape stands today and where to start.

The tools for the first two checks are already in most SAP teams’ hands:

• ABAP Test Cockpit (ATC): SAP’s tool for checking custom code and spotting upgrade-breaking changes in advance, which makes it the main code-level instrument for clean core governance.
• SAP Readiness Check: an overview of custom code volume and compatibility ahead of a migration.
• Usage data from SCMON and SUSG: which objects run in production across a full business cycle, so unused code is visible. Lightrun’s Migration and Clean Core agent ranks custom code by production usage, integration dependencies, and business risk, which turns that usage data into a keep, change, or retire decision.

Dependencies come next, because an object that looks unused can still feed an integration, a master data job, or a downstream partner. Our S/4HANA migration guide explains how operational context, meaning how SAP and connected systems, integrations, and processes behave right now, shows those dependencies.

Back in our group, to answer the head of SAP, the architecture team spends one week on assessment, and four objects stand out:

• Promotion pricing enhancement: it runs on every sales order and reads an internal SAP table, so it is Level C on the order-to-cash process.
• Trade promotion settlement report: finance relies on it each month, and it writes straight into standard SAP tables, so it is Level D.
• Shipping notice interface: it feeds a carrier the group stopped using after a regional exit, and it shows no calls across a full year.
• Batch split program: a home-built routine that S/4HANA now covers as standard.

The team measured usage across a full year because the group’s volumes peak in Q4, so seasonal code shows up in the data.

Close the assessment with a scorecard that gives leadership one view of the landscape:

How Do You Get to a Clean Core in Your S/4HANA Landscape?

Each custom object takes one of four paths, chosen by its level, its usage, and its business risk: back to standard, rebuilt on released APIs, moved side-by-side to SAP BTP, or retired. This is SAP’s “get clean” phase, and it works through the landscape object by object.

In our group, the architecture team takes the four objects through the decision table, and each one lands on a different path. The pricing enhancement is used on every order, so it gets changed: the team rebuilds the logic on a released API and tests it against the order-to-cash flow well before the Q4 change freeze.

The settlement report is Level D on a finance process, so it gets redesigned first. The direct table writes move to a released interface, and the finance controller signs off only after a full month-end close on the new version. The shipping interface is retired once the dependency and audit check confirms nothing downstream reads its output, and the batch split program returns to standard so the team stops maintaining code that SAP now provides.

The order of work follows risk. High-usage, high-dependency objects on revenue-critical processes go first and get the most testing, while unused objects go through the retire checklist in parallel.

The choice between on-stack and side-by-side depends on where the logic belongs:

• On-stack with ABAP Cloud: fits logic that needs close access to core data and runs inside the S/4HANA system, built on released objects.
• Side-by-side on SAP BTP: fits logic that serves several systems, needs its own lifecycle, or connects to external services. For clean core on SAP BTP, SAP asks customers to apply governance when choosing between the two.

How Do You Maintain a Clean Core After Go-Live?

Treat clean core as a governance practice: set clean core boundaries in every design, check every change before it reaches production, and review the level mix after each release. This is SAP’s “stay clean” phase, and it is where most guidance stops.

Four practices keep the core clean change by change:

• A design authority: clean core boundaries written into every specification, so new requirements start inside the boundaries.
• ATC clean core checks as transport gates: every transport is checked before it moves toward production.
• Change risk review for any change touching Level C objects: a named reviewer sees the dependencies before approval, supported by a risk-scored briefing such as the one Lightrun’s Change Risk Analyzer prepares.
• A level mix review after each release: the share of Level A and B objects is tracked over time and reported to the business.

The operations principle supports all four. Stable operations and monitoring keep the core trusted, so changes can be made with confidence. Our guides to application management services and SAP AMS cover what operations after go-live involve.

Six months after go-live, the group tests the practice. A few weeks before the Q4 peak, the commercial team asks for a new discount rule for a major retailer. The design authority writes the clean core boundary into the specification before any code exists, so the developer, whose first idea was an implicit enhancement in a standard pricing program (a Level D change), is steered to a released extension point instead.

The change then moves as a transport, which is SAP’s package of changes traveling from development toward production. The ATC check runs on that transport, and the change risk review shows that the promotion output also feeds retailer invoicing and trade settlement, so those teams test before approval. The change ships ahead of the freeze, and the level mix after the next release shows no new Level D objects.

The loop below shows the four checks that make this repeatable:

How Do Lightrun’s Transformation Agents Support Clean Core?

Lightrun’s Transformation agents help teams get clean with evidence, and Lightrun’s Reliability agents help keep the core clean in daily operations. Both prevent failures before a change ships and resolve them faster when something breaks, drawing on SAP applications, custom code, configurations, integration data, and operational context such as production usage.

The Solution Design Assistant designs changes that stay clean:

• Requirements Analysis: turns incomplete business requirements into clear, actionable specifications.
• Landscape Impact Review: shows how a proposed solution will affect the existing SAP landscape, mapping process and technical dependencies across SAP systems and integrations.
• Solution Specification: prioritizes standard SAP capabilities over custom development, and defines clean core boundaries, failure behavior, tests, and approval gates.

The Migration & Clean Core agents get the landscape clean:

• Clean Core Initiatives: reduces custom code and modifications while preserving critical business behavior. It moves custom logic to standard SAP capabilities or supported SAP BTP extensions, and retires unused enhancements after checking usage, dependencies, and audit needs.
• S/4HANA Upgrades: finds incompatible custom code, maps it to released BAdIs and APIs, and defines ATC checks and regression tests to validate each upgrade, supporting the stay clean phase.
• ECC to S/4HANA Migration: ranks custom code by production usage, integration dependencies, and business risk to decide what to keep, change, or retire in S/4HANA.

Reliability agents keep the core clean:

• Change Risk Analyzer: analyzes transports and dependencies to produce a risk-scored change advisory board briefing before every change.

In our group’s example, two Transformation agents and one Reliability agent show up at three points. 

1. During the assessment, the Migration & Clean Core agent gives the architecture team usage and dependency evidence for the four objects, so the keep, change, and retire calls rest on production data. 
2. Before the pricing rebuild, the Solution Design Assistant maps the interfaces and downstream processes it touches to run a Landscape Impact Review. 
3. When the retailer discount request arrives after go-live, Change Risk Analyzer produces the risk-scored briefing that the change advisory board can review before the transport moves.

Lightrun’s Forward Deployed Engineers customize the agents to each landscape, connecting them to legacy systems, legacy code, and non-API platforms. Agents are read-only by default; write actions require explicit approval, and permission settings, RBAC, and audit logs keep your team in control.

How Do You Build Lasting Clean Core Discipline?

Clean core is reached object by object and kept clean change by change. The levels give you a shared language, the assessment shows where you stand, and the stay-clean practices keep each upgrade routine and each new SAP capability within reach.

The group’s four objects went four different ways, and each decision came from the same three inputs: level, usage, and dependencies. The same governance then kept the core clean through the first Q4 peak on S/4HANA. Teams that treat both phases as one program carry that discipline through every release, from the next S/4HANA upgrade to the AI scenarios the board is asking about.