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

Clean Core Levels A–D: How to Classify Your Custom ABAP

Warum ein neues Modell?

Das alte Tier-Modell war im Kern eine binäre Entscheidung: sauber oder nicht sauber. Für Neuentwicklungen funktioniert das gut. Für ein gewachsenes System mit tausenden Z-Objekten ist es aber wenig hilfreich, wenn 80 Prozent des Codes pauschal in „Tier 3″ landen – ohne Unterscheidung, ob ein Objekt nur einen klassischen BAdI nutzt oder den SAP-Standard modifiziert. Genau diese Differenzierung liefert das Level-Modell: Es bewertet, wie nah jede einzelne Erweiterung an den Clean-Core-Prinzipien liegt, und ermöglicht damit eine schrittweise Transformation im eigenen Tempo.

Level A: Der Zielzustand

Level A umfasst die saubersten Erweiterungen – gebaut entweder on-stack mit dem ABAP-Cloud-Entwicklungsmodell direkt im S/4HANA-System oder side-by-side auf der SAP BTP, etwa mit ABAP Cloud, CAP oder Low-Code-Werkzeugen aus SAP Build. Gemeinsamer Nenner: Es werden ausschließlich freigegebene APIs und Erweiterungspunkte genutzt, für die SAP Stabilitätszusagen gibt. Fehlt eine benötigte API, kommt das bewährte Wrapper-Konzept zum Einsatz – die Kapselung des nicht freigegebenen Zugriffs hinter einer eigenen Schnittstelle bleibt der saubere Übergangspfad. Level-A-Erweiterungen sind maximal upgrade-stabil und Public-Cloud-ready.

Level B: Classic ABAP nach den Regeln

Level B ist neu – und für Bestandssysteme die vielleicht wichtigste Stufe. Hier landet klassisches ABAP, das den SAP-Entwicklungsempfehlungen folgt und die als klassische APIs angebotenen Frameworks nutzt: BAdIs, freigegebene Funktionsbausteine, dokumentierte Erweiterungstechniken. Kein ABAP Cloud, aber diszipliniert gebaut. Die Botschaft dahinter ist bemerkenswert pragmatisch: Gut gemachtes Classic ABAP ist kein Sanierungsfall. Es muss nicht zwingend migriert werden, um als weitgehend clean zu gelten.

Level C: Bedingt sauber – mit Prüfpflicht

Level C enthält Erweiterungen, die auf beliebige SAP-interne Objekte zugreifen – also das, was in gewachsenen Systemen den Löwenanteil ausmacht: direkte Selects auf SAP-Tabellen, Aufrufe nicht freigegebener Bausteine. Der interessante Punkt: Diese Objekte gelten als „conditionally clean“, wenn vor jedem Release-Upgrade dedizierte Prüfungen gegen die Änderungshistorie der genutzten SAP-Objekte laufen. Aus einem diffusen Risiko wird damit ein kontrollierter Prozess – vorausgesetzt, man weiß, welche Objekte betroffen sind.

Level D: Der eigentliche Handlungsbedarf

Level D ist nicht Clean Core. Hier liegen Erweiterungen mit schweren Verstößen gegen die SAP-Entwicklungsempfehlungen: Modifikationen am Standard, nicht empfohlene Objekte und abgekündigte Erweiterungstechnologien. Das ist der Bereich, der bei jedem Upgrade zuverlässig Aufwand und Fehler produziert – und auf den sich eine Clean-Core-Roadmap zuerst konzentrieren sollte.

Was heißt das praktisch?

Für Neuentwicklungen bleibt die Regel einfach: Level A zuerst, BTP-first wo sinnvoll, Wrapper wo APIs fehlen. Für den Bestand verändert das Modell die Rechnung grundlegend: Statt „alles muss irgendwann nach ABAP Cloud“ lautet die Aufgabe jetzt, D-Objekte gezielt abzulösen, C-Objekte in einen kontrollierten Prüfprozess zu überführen und B-Objekte schlicht sauber zu halten. Das ist deutlich realistischer – setzt aber voraus, dass man weiß, wie sich der eigene Custom Code auf die vier Levels verteilt.

Sie möchten wissen, wie Ihr Custom Code auf die Levels A–D verteilt ist? Mit unserem Clean-Core-Assessment schaffen wir in wenigen Tagen Transparenz – sprechen Sie uns an.

Quellen

• ABAP Extensibility Guide – Clean Core for SAP S/4HANA Cloud – August 2025 Update
• Business Excellence with SAP’s New Clean Core Extensibility Levels: Why, What and How
• How to Extend SAP S/4HANA Cloud the Right Way
• Clean Core Levels A–D: How to Classify Your Custom ABAP

Die kurze Antwort: Nein. Aber es lohnt sich, genau hinzuschauen.

Was bedeutet Clean Core?

Clean Core bedeutet, den SAP-Kern frei von Modifikationen zu halten. Statt Kerncode anzupassen – was Updates erschwert, Upgrades verteuert und die Systemstabilität gefährdet – werden Erweiterungen über offizielle SAP-Mechanismen realisiert: freigegebene APIs, BAdIs, oder Erweiterungen auf der Business Technology Platform (BTP).

Das Ziel: Ein SAP-System, das updatefähig, wartungsarm und zukunftssicher bleibt.

Warum ist das gerade jetzt relevant?

Mit dem Ende des Mainstream-Supports für SAP ECC stehen viele Unternehmen vor der Migration nach S/4HANA. Wer dabei seinen gewachsenen Modifikationsberg mitschleppt, zahlt doppelt: einmal bei der Migration, und immer wieder bei jedem Update danach.

Clean Core ist kein Nice-to-have – es ist die Grundlage dafür, dass S/4HANA langfristig wirtschaftlich betreibbar bleibt.

Der erste Schritt: Wissen, wo man steht

Viele Unternehmen wissen gar nicht, wie viele Modifikationen sie tatsächlich haben – und wie kritisch diese wirklich sind. Das ist kein Versagen, sondern das Ergebnis von Jahren gewachsener Systeme.

Der erste konkrete Schritt ist deshalb immer: die Clean Core Analyse im eigenen System aktivieren und auswerten. Erst dann wird klar, womit man es wirklich zu tun hat – und was tatsächlich dringend ist.

Aus unserer Erfahrung gilt: Nicht jedes Finding ist gleich. Die Gesamtzahl klingt oft erschreckend. Die wirklich kritischen Fälle sind meist deutlich weniger – aber die haben es in sich.

Drei häufige Fehler, die wir in Projekten sehen

Modifikationen werden unreflektiert übernommen. Ohne zu prüfen, ob der SAP-Standard inzwischen dieselbe Funktion bietet. In vielen Fällen tut er das – die Eigenentwicklung ist schlicht nicht mehr nötig.

Eigenentwicklungen landen im Kern. Obwohl Side-by-Side-Erweiterungen oder BTP die bessere Wahl wären. Oft aus Gewohnheit, manchmal aus Zeitdruck.

Clean Core wird als Einmalaufgabe verstanden. Dabei ist es ein kontinuierlicher Ansatz. Wer einmal aufräumt und dann weitermacht wie bisher, hat das Prinzip nicht verinnerlicht.

Was wir selbst gelernt haben

Wir bei secat gehen diesen Weg mit unserem eigenen Produkt QPPD gerade selbst. Als wir unsere Codebasis erstmals einer vollständigen Clean Core-Prüfung unterzogen haben, standen wir vor knapp 9.000 kritischen Findings.

Was geholfen hat: strukturiert vorgehen, automatisiert analysieren, priorisieren – und nicht alles auf einmal angehen wollen. Die größte technische Herausforderung war das Ablösen klassischer SAP-GUI-Technologien wie ALV Tree und ALV Grid, die wir durch UI5 ersetzt haben.

Wir sind noch nicht fertig. Aber wir wissen genau, wie sich jede Phase dieses Prozesses anfühlt – und was wirklich hilft.

Wie secat Sie dabei unterstützt

Wir begleiten Unternehmen auf dem Clean Core-Weg – von der ersten Analyse bis zur konkreten Umsetzung. Mit Paketen, die klar umrissen sind und ohne versteckte Folgekosten starten:

• Clean Core Assessment (3–5 Tage, remote): Wir aktivieren die Analyse in Ihrem System, werten die Findings aus und präsentieren Ihnen die Ergebnisse.
• Clean Core Roadmap (5–10 Tage): Auf Basis des Assessments entwickeln wir einen priorisierten Fahrplan mit realistischer Aufwandseinschätzung.
• Clean Core Quick Win (ab 5 Tagen): Wir lösen eine konkrete Modifikation gemeinsam ab – von der Auswahl bis zur Übergabe.

Mehr zu unseren Clean Core Paketen

Sie möchten wissen, wo Ihr System steht? Sprechen Sie uns an – der erste Schritt ist einfacher als gedacht.

Jetzt Kontakt aufnehmen