The most common reaction to Clean Core in established SAP systems: “We have twenty years of custom development in the system – where should we even start?” The answer is unspectacular but effective: with a clean inventory. Before anything is migrated, replaced, or rebuilt, you need transparency about what actually exists in the system, how it is distributed across Clean Core levels A–D – and what is actually still being used.
Step 1: What Exists in the System?
The ABAP Test Cockpit (ATC) provides everything you need for this. With the Cloud Readiness Checks, all custom code can be automatically examined to identify which objects use non-released SAP interfaces, directly access SAP tables, or are based on modifications. Additionally, the Cloudification Repository shows which standard objects are released – the foundation for assigning findings to levels.
The result is not weeks of tedious manual work, but an overnight run: a complete list of all findings, categorized by object and severity. This means the question “How much Level D code do we have in our system?” is no longer an estimate, but a report.
Step 2: What Is Actually Being Used?
The second view is at least as valuable as the first: usage data. Through Usage Procedure Logging (SUSG/SCMON), you can track over several months which custom developments are actually being called. Experience from our projects is remarkably consistent: a significant portion of custom code – often 30 to 60 percent – is simply no longer used.
This insight changes the entire calculation. Dead code does not need to be classified or migrated; it only needs to be decommissioned. Anyone who skips the usage analysis is planning migration effort for objects that no one would miss.
Step 3: Prioritize Along the Levels
From findings, level assignments, and usage data, a clear action plan emerges. Unused code is decommissioned – regardless of level. Used B-objects remain as they are; they only need to be kept clean. Used C-objects are not hastily migrated, but transferred into a controlled review process: before each upgrade, they are checked against the change history of the used SAP objects – making them “conditionally clean.” And the D-objects – modifications and serious violations – are prioritized by business criticality on the actual replacement roadmap.
This is the key difference from big-bang thinking: Clean Core in Brownfield is not a project with an end date, but a directional decision with prioritized execution. Each upgrade becomes measurably less expensive – and the system becomes future-proof step by step.
The Realistic Timeframe
A reliable inventory including level evaluation typically takes a few days to two weeks – usage measurement runs in parallel in the background. The result is not a hundred-page concept, but a prioritized list with effort indication. This is exactly what management needs to treat Clean Core not as a matter of faith, but as an investment decision.
secat conducts Clean Core assessments with ATC, level, and usage analysis as a compact fixed-price package. Contact us – we will show you where your system stands today.
SAP S/4HANA System Conversion – Custom Code Adaptation Process
Custom Code Adaptation for SAP S/4HANA – FAQ
SUSG: How to Aggregate and Analyze the Results of SCMON ABAP Call Statistics
ABAP Extensibility Guide – Clean Core for SAP S/4HANA Cloud – August 2025 Update