Die häufigste Reaktion auf Clean Core in gewachsenen SAP-Systemen: „Bei uns liegen zwanzig Jahre Eigenentwicklung im System – wo sollen wir da überhaupt anfangen?“ Die Antwort ist unspektakulär, aber wirkungsvoll: mit einer sauberen Bestandsaufnahme. Denn bevor irgendetwas migriert, abgelöst oder neu gebaut wird, braucht es Transparenz darüber, was tatsächlich im System liegt, wie es sich auf die Clean-Core-Levels A–D verteilt – und was davon überhaupt noch genutzt wird.
Schritt 1: Was liegt im System?
Das ABAP Test Cockpit (ATC) bringt dafür alles mit, was man braucht. Mit den Cloud-Readiness-Checks lässt sich der gesamte Custom Code automatisiert daraufhin prüfen, welche Objekte nicht freigegebene SAP-Schnittstellen nutzen, direkt auf SAP-Tabellen zugreifen oder auf Modifikationen basieren. Ergänzend zeigt das Cloudification Repository, welche Standardobjekte freigegeben sind – die Grundlage, um Findings den Levels zuzuordnen.
Das Ergebnis ist keine Fleißarbeit für Wochen, sondern ein Lauf über Nacht: eine vollständige Liste aller Findings, kategorisiert nach Objekt und Schweregrad. Damit ist die Frage „Wie viel Level D liegt bei uns im System?“ keine Schätzung mehr, sondern ein Report.
Schritt 2: Was wird überhaupt genutzt?
Der zweite Blick ist mindestens so wertvoll wie der erste: die Nutzungsdaten. Über das Usage Procedure Logging (SUSG/SCMON) lässt sich über mehrere Monate mitschreiben, welche Eigenentwicklungen tatsächlich aufgerufen werden. Die Erfahrung aus unseren Projekten ist dabei erstaunlich konstant: Ein erheblicher Teil des Custom Codes – oft 30 bis 60 Prozent – wird schlicht nicht mehr verwendet.
Diese Erkenntnis verändert die gesamte Rechnung. Toter Code muss nicht klassifiziert und nicht migriert werden, er muss nur stillgelegt werden. Wer die Nutzungsanalyse überspringt, plant Migrationsaufwand für Objekte, die niemand vermissen würde.
Schritt 3: Priorisieren entlang der Levels
Aus Findings, Level-Zuordnung und Nutzungsdaten entsteht ein klarer Handlungsplan. Ungenutzter Code wird stillgelegt – unabhängig vom Level. Genutzte B-Objekte bleiben, wie sie sind; sie müssen nur sauber gehalten werden. Genutzte C-Objekte werden nicht hektisch migriert, sondern in einen kontrollierten Prüfprozess überführt: Vor jedem Upgrade wird gegen die Änderungshistorie der genutzten SAP-Objekte geprüft – so werden sie „conditionally clean“. Und die D-Objekte – Modifikationen und schwere Verstöße – landen priorisiert nach fachlicher Kritikalität auf der eigentlichen Ablöse-Roadmap.
Das ist der zentrale Unterschied zum Big-Bang-Denken: Clean Core im Brownfield ist kein Projekt mit Enddatum, sondern eine Richtungsentscheidung mit priorisierter Abarbeitung. Jedes Upgrade wird dadurch messbar günstiger – und das System Schritt für Schritt zukunftsfähig.
Der realistische Zeitrahmen
Eine belastbare Bestandsaufnahme inklusive Level-Auswertung dauert erfahrungsgemäß wenige Tage bis zwei Wochen – die Nutzungsmessung läuft parallel im Hintergrund mit. Am Ende steht kein hundertseitiges Konzept, sondern eine priorisierte Liste mit Aufwandsindikation. Genau das braucht die Geschäftsführung, um Clean Core nicht als Glaubensfrage, sondern als Investitionsentscheidung zu behandeln.
secat führt Clean-Core-Assessments mit ATC-, Level- und Nutzungsanalyse als kompaktes Festpreispaket durch. Sprechen Sie uns an – wir zeigen Ihnen, wo Ihr System heute steht.
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