span 1 span 2 span 3

How to Implement SAP Clean Core: Practical Steps for Migration

Many IT teams are already familiar with the clean core concept. Yet they often struggle to pin down where to start and in what order. As the SAP ECC deadline nears, Z objects pile up with no clear plan. This article lays out practical steps for implementing clean core during a migration to S/4HANA. It also complements the SAP Clean Core guidance, complete with the names of the official audit tools.

SAP Clean Core is the principle of keeping the SAP S/4HANA core standard and easy to upgrade by moving customizations outside the core. Customizations are usually moved to the SAP Business Technology Platform (BTP) or to ABAP Cloud. During a migration, putting it into practice covers auditing custom code. It also includes setting targets per dimension, choosing an upgrade-safe extension model, and ongoing management.

What steps do you need to take to implement SAP Clean Core during a migration?

Implementing clean core consists of five sequential steps that run alongside migrating the ERP to the cloud. Those steps include adopting standard processes (fit-to-standard), auditing and classifying custom code, setting targets per dimension, choosing an extension model that is safe to upgrade, and ongoing management. The audit is done before cutover. Governance keeps running after go-live.

1. Fit-to-standard

Adopt SAP standard processes first; customize only for real gaps

Fit-to-standard workshop / SAP Best Practices

2. Audit custom code

Inventory Z objects; separate what is used from what is not

SAP Readiness Check, SAP Custom Code Migration app, ABAP Test Cockpit (ATC)

3. Set targets

Goals per clean core dimension: process, extensions, integration, data, operations

Target level per dimension (a measurable baseline)

4. Choose an extension model

In-app (key-user) vs side-by-side (SAP BTP) vs on-stack ABAP Cloud

Extend via released APIs, prioritize levels A/B

5. Governance

Prevent new dirty customizations after go-live

ATC + extensibility guidelines

Steps 1-2: Audit Custom Code and Set Targets

Before starting on extensions, run fit-to-standard and audit custom code with SAP’s three official tools. Use SAP Readiness Check to map the impact of simplification and the objects affected. Use SAP Custom Code Migration app to separate used from unused objects based on usage data. Use ABAP Test Cockpit (ATC) to check clean core compliance on each object. Most legacy code is no longer in use. Industry findings put roughly 40-60% of legacy custom code as unused and safe to delete during migration. For that reason, the first step is often not moving code but retiring dead code. According to SAP Custom Code Migration Guide, unused objects are identified from usage data and can be removed through a deletion transport during conversion.

The remaining objects fall into four decisions. An object can be retired, rewritten on SAP BTP, migrated to ABAP Cloud, or kept temporarily. This step produces a priority list and clean core targets per dimension as a measurable baseline. In practice, projects often stall because the audit is delayed. The obstacle does not come from the extension technology.

How do you choose between In-App and Side-by-Side Extensibility?

Use in-app (key-user) extensibility for small adjustments that stay within the stack, such as custom fields or Fiori UI adaptations. Choose side-by-side extensibility on SAP BTP for complex logic, custom UIs, or integrations that need to sit apart from the core. Both use released APIs to stay safe through upgrades.

Since August 2025, SAP has rated extension cleanliness with a four-tier model, A, B, C, and D. This model replaces the older three-tier one. According to SAP News Center, the tiers are graded:

  • Level A: the cleanest, only SAP’s official released APIs. Delivered through on-stack ABAP Cloud or side-by-side on SAP BTP.
  • Level B: classic ABAP with documented official SAP APIs and frameworks that usually stay stable through upgrades.
  • Level C: can access SAP internal objects. Partly rule-compliant, and still flexible for legacy scenarios.
  • Level D: not clean core. These are modifications or objects that are not recommended, carrying the highest risk and technical debt.

The rule of thumb when running SAP Clean Core is to favor Levels A and B first. Use Level C only when needed. Block Level D patterns through ATC.

Does All Custom Code Have to Be Clean Before Migration?

No. Clean core is a gradual approach. You do not have to reach it 100% before cutover. Prioritize by how important each item is to the business. Move the relevant customizations into upgrade-safe extensions. Keep some customizations if they are truly needed. The target is a measurable Level A or B, not perfection right away.

How mandatory it is depends on the edition. SAP S/4HANA Cloud Public Edition is built around the clean core concept. Core modifications are not available, so this is effectively mandatory. Private Edition and on-premise are more flexible. Even so, SAP still recommends the clean path through ABAP Cloud and SAP BTP.

Time for migration is running short. Mainstream maintenance for SAP ECC ends on December 31, 2027. Extended maintenance is optional, at an extra 2 percent, through 2030. Delaying only raises the cost. Governance is also an ongoing process. Keeping the core clean after go-live matters as much as cleaning it during migration.

FAQ (Frequently Asked Questions)

Do all customizations have to be removed to implement clean core?

No. Most legacy code can be retired. Industry findings show that roughly 40-60% of legacy custom code is no longer in use. The rest, still relevant, is not deleted. That code is moved into upgrade-safe extensions on SAP BTP or ABAP Cloud. The goal is to move customizations outside the core, not to delete everything.

What tools are used to assess custom code before migration?

SAP provides three official tools used in sequence. SAP Readiness Check assesses conversion readiness and maps the objects affected. SAP Custom Code Migration app sorts used from unused objects based on usage data. ABAP Test Cockpit (ATC) validates clean core compliance on each object.

Is this mandatory for every SAP deployment?

Not for all. SAP S/4HANA Cloud Public Edition runs clean core as standard. Updates run automatically and core changes cannot be made, so clean core becomes mandatory. Private Edition and on-premise are looser. Classic extensibility can still be used, though SAP still recommends the clean path through ABAP Cloud and SAP BTP.

Conclusion

Implementing clean core is not one big project. The process consists of several steps: fit-to-standard, audit, setting targets, choosing upgrade-safe extensions, then managing the governance that runs alongside the S/4HANA migration and continues afterward. As an SAP Platinum Partner through United VARs, with experience since 1998, Soltius runs S/4HANA migrations and applies clean core principles, from custom-code audit to placing extensions on SAP BTP, backed by Application Management Services (AMS).

To discuss implementing clean core in your SAP environment, visit soltius.co.id.

Other News

Nov 18, 2026
Employee Central SAP SuccessFactors: Functions and Advantages
Nov 16, 2026
What Is Human Capital Management (HCM)? A Complete Guide