SAP-Clean-Core-Strategie: Bedeutung und Umsetzung

Clean Core entscheidet darüber, ob ein S/4HANA-Upgrade sechs Wochen oder sechs Monate dauert. Ist Ihr System voll von Modifikationen an SAP-Standardobjekten, wird jedes Release zu einem Regressionsprojekt. Liegt Ihre kundeneigene Logik hinter freigegebenen Schnittstellen, werden Upgrades zur Routinewartung.

Ich habe Unternehmen erlebt, die ihre Upgrade-Zeitpläne um 40 % verkürzt haben, indem sie Clean-Core-Prinzipien anwandten, bevor ihr S/4HANA-Programm begann. Ein Konsumgüterunternehmen ersetzte veraltete Preislogik durch eine modulare Fiori-App außerhalb des Kerns, und seine Upgrades brachen diese Logik nicht mehr.

Seit ich das im April 2025 zum ersten Mal geschrieben habe, hat sich viel getan. SAP beschreibt Clean Core heute über fünf Leitprinzipien und ordnet seit August 2025 jede Erweiterung einem von vier Leveln zu. Auch die ECC-Fristen sind klarer. Diese Fassung bildet das ab.

Clean Core bedeutet, Ihr S/4HANA-System so nah am SAP-Standard zu halten, wie Ihr Geschäft es zulässt, und alles Zusätzliche so zu bauen, dass es Upgrades übersteht.

Sie dürfen weiterhin anpassen. Die Anpassung muss aber Schnittstellen nutzen, die SAP freigegeben hat und stabil zu halten verspricht. SAP bietet dafür zwei Wege:

• On-stack, mit ABAP Cloud. Erweiterungen laufen innerhalb von S/4HANA, nutzen aber nur freigegebene APIs und Erweiterungspunkte.
• Side-by-side, auf SAP BTP. Erweiterungen laufen als eigenständige Anwendungen und sprechen über APIs oder Events mit S/4HANA.

SAP selbst empfiehlt, je Anwendungsfall zu entscheiden, mit BTP an erster Stelle. Nach meiner Erfahrung kommt es weniger darauf an, wo der Code läuft, als darauf, ob die Anforderung überhaupt Code braucht.

Ein Dirty Core sieht für jeden vertraut aus, der ECC betrieben hat: modifizierte Standardprogramme, direkt beschriebene Z-Tabellen, Schnittstellen, die SAP-Interna lesen, implizite Erweiterungen, die niemand dokumentiert hat. Nichts davon war falsch, als es gebaut wurde. Es war nur nicht für ein System gebaut, das alle ein bis zwei Jahre ein Upgrade bekommt.

SAP gliedert Clean Core um fünf Leitprinzipien. Die frühere Fassung dieses Artikels führte andere Überschriften auf. Das sind die, die SAP verwendet, jeweils mit dem, worauf ich zuerst schaue:

Prinzip	Was SAP darunter versteht	Was ich zuerst prüfe
Prozesse	So nah wie möglich am SAP-Standardprozess bleiben	Welche Prozessvarianten nur existieren, weil „wir es schon immer so gemacht haben“
Erweiterbarkeit	Erweiterungen, die über freigegebene APIs vom Kern entkoppelt sind, mit Governance darüber, welche Option genutzt wird	Wie viel Custom Code es gibt, wie viel davon genutzt wird und auf welchem Level er liegt
Daten	Saubere, regelkonforme Daten mit etabliertem Governance-Modell	Doppelte und unvollständige Stammdaten, kundeneigene Felder, die niemand erklären kann
Integrationen	Standardisierte, sichere Verbindungen auf Basis unterstützter Technologien	Punkt-zu-Punkt-Schnittstellen, die Tabellen direkt lesen
Betrieb	Governance, Menschen, Prozesse und Werkzeuge, die die anderen vier absichern	Wer eine Erweiterung freigibt und was die nächste Modifikation verhindert

Die meisten Teams beginnen und enden bei der Erweiterbarkeit, weil sie sich am leichtesten messen lässt. Nach meiner Erfahrung verursachen Prozesse und Daten mehr Verzögerung. Custom Code ist meist das Symptom. Der Prozess dahinter ist die Ursache.

Im August 2025 hat SAP sein früheres dreistufiges Erweiterbarkeitsmodell durch das Clean-Core-Level-Konzept ersetzt. Jede Erweiterung wird danach bewertet, wie sie gebaut ist, wie stark sie vom Kern entkoppelt ist und wie leicht sie sich upgraden lässt.

Level	Beschreibung von SAP	Was es für Ihr Upgrade bedeutet
A	Erweitern mit SAP Build. Nur öffentlich freigegebene, stabile Schnittstellen, on-stack mit ABAP Cloud oder side-by-side auf BTP	Geringstes Risiko. SAP sichert diese Schnittstellen mit Stabilitätszusagen ab
B	Nutzt zusätzlich die klassischen APIs und Technologien von SAP	In der Regel upgradestabil, aber außerhalb des Cloud-Entwicklungsmodells
C	Greift auf SAP-interne Objekte zu	Teilweise konform. Jedes Upgrade muss geprüft werden; SAP plant ein Änderungsprotokoll für interne Objekte
D	Nicht empfohlen: Modifikationen, Schreibzugriffe auf SAP-Tabellen, implizite Erweiterungen, ausdrücklich nicht empfohlene Objekte	Die technische Schuld, die Sie zuerst abbauen sollten

Das ist nützlicher als die alte Debatte „sauber oder nicht sauber“. Sie können damit ein Ziel je Objekt festlegen. Nicht alles muss Level A erreichen. Level-D-Objekte vor einem Upgrade auf B oder C zu bringen, senkt das Risiko bereits spürbar.

Level ALevel BLevel CLevel D

Was genutzt wirdLevel ANur öffentlich freigegebene, stabile SchnittstellenLevel BZusätzlich die klassischen APIs von SAPLevel CSAP-interne ObjekteLevel DModifikationen, Schreibzugriffe auf SAP-Tabellen, implizite Erweiterungen

Upgrade-RisikoLevel AAm geringsten, durch Stabilitätszusagen abgesichertLevel BIn der Regel upgradestabilLevel CBei jedem Upgrade zu prüfenLevel DAm höchsten

Was zu entscheiden istLevel AStandard für alles NeueLevel BAkzeptieren, mit dokumentiertem GrundLevel CMit Grund akzeptieren, bei jedem Upgrade neu prüfenLevel DZuerst entfernen oder auf B oder C bringen

Quelle: Clean-Core-Level-Konzept von SAP, SAP News, August 2025

Wenn Sie mich bäten, Ihr System im nächsten Monat zu bewerten, würde ich in dieser Reihenfolge vorgehen.

1. Herausfinden, was genutzt wird. Führen Sie den SAP Readiness Check durch, der zu Ihrem Wartungsvertrag gehört, und erheben Sie Nutzungsdaten zu Ihrem Custom Code. In einem Programm brachte uns die Analyse mit smartShift von 18.000 Custom-Objekten auf 3.200. Der Großteil des Rests wurde schlicht nicht genutzt.
2. Den verbleibenden Bestand in die Level A bis D einordnen. Das ABAP Test Cockpit ist das Werkzeug von SAP für Prüfungen auf Code-Ebene. Unter RISE zeigt das Dashboard der RISE with SAP Methodology den Clean-Core-Umsetzungsgrad an.
3. Objekt für Objekt entscheiden. Abschalten, auf eine freigegebene Schnittstelle umstellen, auf BTP neu bauen oder mit dokumentiertem Grund behalten. Beginnen Sie mit Code, der täglich läuft. Ein Report, den ein regionales Team zweimal im Jahr nutzt, kann warten.
4. Den Fachbereich an den Tisch holen. Ein Finanzleiter, mit dem ich gearbeitet habe, verstand seine neue Fiori-App erst nach einem 45-minütigen Walkthrough. Diese Sitzung ersparte zwei Wochen Hin und Her im UAT.
5. „Unser Prozess ist anders“ hinterfragen. In einem Workshop mit einem Vertriebsteam stellte sich der „einzigartige“ Prozess als zu 80 % redundante Altverwaltung heraus. Der SAP-Standard verbesserte die Kundenerfahrung des Teams, sobald die Behelfslösungen weg waren.
6. Datenarbeit früh beginnen. Ein Handelskunde hatte über 15.000 kundeneigene Felder zu sichten. Nach meiner Erfahrung beansprucht die Datenmigration 30 bis 40 % des Einführungsaufwands, und das ist der Teil, den die meisten Pläne unterschätzen. Warum das so ist, steht in meinem Beitrag warum die SAP-Datenmigration scheitert.
7. Die Governance vor dem Go-live festlegen. Eine Design Authority sollte jede neue Erweiterung prüfen. Die Standardfrage lautete früher: „Warum kann das nicht auf BTP laufen?“ Heute würde ich fragen: „Warum kann das nicht Level A sein, und wenn nicht, welches Level akzeptieren wir und warum?“

Kompetenzen zählen genauso viel wie Werkzeuge. Ein ABAP-Team, das noch nicht mit ABAP Cloud oder BTP gearbeitet hat, bremst das Programm aus, während es lernt. Ein Hersteller, mit dem ich gearbeitet habe, führte vor dem Start seines S/4HANA-Projekts ein dreimonatiges internes BTP-Programm durch, und das zahlte sich in weniger Überraschungen während der Umsetzung aus.

Drei Fragen kommen in fast jedem Gespräch zu diesem Thema auf.

Ist Clean Core unter RISE with SAP verpflichtend? Nicht als pauschale Regel. In S/4HANA Cloud Public Edition können Sie nur über freigegebene Schnittstellen erweitern, das System erzwingt es also. In der Private Edition und On-Premise können Sie den Kern weiterhin modifizieren. Clean Core ist dort eine Governance-Entscheidung, und SAP verfolgt sie über das Methodology-Dashboard von RISE. Sagt Ihnen ein SI, es sei vertraglich vorgeschrieben, bitten Sie ihn, Ihnen die Klausel zu zeigen.

Wie lange habe ich noch Zeit mit ECC? Für SAP ERP 6.0 auf den Enhancement Packages 6 bis 8 endet die Standardwartung am 31. Dezember 2027. Die optionale erweiterte Wartung läuft gegen Aufpreis bis zum 31. Dezember 2030, und SAP bittet die Kunden, sie bis zum dritten Quartal 2027 zu bestellen. Frühere Enhancement Packages sind Ende 2025 aus der Standardwartung ausgelaufen. Nach 2030 deckt die Übergangsoption für SAP ERP, Private Edition die Jahre 2031 bis 2033 ab. Sie gilt nur für große Systeme, die vor Ende 2030 bereits auf SAP ERP, Private Edition auf SAP HANA umgezogen sind, und nur mit dem Max Success Plan von SAP. Behandeln Sie 2033 als Ausnahmeroute, nicht als Planungstermin. Mein Leitfaden zur Migration von ECC auf S/4HANA behandelt die Routenwahl.

Spielt Clean Core für KI eine Rolle? SAP baut seine KI-Funktionen, darunter Joule, auf seinen Standardprozessen und seinem Standarddatenmodell auf. Joule for developers erzeugt ABAP-Cloud-Code gegen freigegebene APIs. Meine Arbeitsthese ist einfach: Je näher Ihre Prozesse und Daten am Standard liegen, desto weniger Anpassung brauchen Sie, bevor diese Funktionen für Sie nützlich sind. Bei stark modifizierten Prozessen lassen sich KI-Funktionen am schwersten einführen.

Teams, die Clean Core überspringen, sparen sich die Arbeit nicht. Sie schieben sie auf, und sie kommt zurück als blockierte Upgrades, Regressionstest-Marathons und Custom Code, den niemand mehr versteht.

Wenn Sie kurz vor der Unterzeichnung eines S/4HANA- oder RISE-Vertrags stehen, bitten Sie Ihren SI um eine Einordnung Ihres aktuellen Custom Codes in die Level A bis D, bevor Sie den Umfang vereinbaren. Kann er keine liefern, sagt das etwas über die Schätzung aus. Sie können Ihre Migrationsoptionen mit meiner Bewertung der Migration von ECC auf S/4HANA prüfen oder ein Gespräch buchen, und wir schauen uns Ihre Situation an.

Was ist SAP Clean Core?

Clean Core bedeutet, S/4HANA nah am SAP-Standard zu halten und Erweiterungen nur über Schnittstellen zu bauen, die SAP freigegeben hat und stabil zu halten zusagt. Erweiterungen laufen entweder on-stack mit ABAP Cloud oder side-by-side auf SAP BTP. Ziel ist, dass Upgrades Ihre kundeneigene Logik nicht beschädigen.

Was sind die fünf Dimensionen von SAP Clean Core?

SAP nennt sie die fünf Leitprinzipien von Clean Core: Prozesse, Erweiterbarkeit, Daten, Integrationen und Betrieb. Prozesse bleiben nah am Standard. Erweiterungen nutzen freigegebene APIs. Daten werden unter einem Governance-Modell sauber gehalten. Integrationen nutzen standardisierte, unterstützte Technologien. Der Betrieb umfasst die Governance, die Menschen und die Werkzeuge, die die anderen vier absichern.

Was sind die SAP-Clean-Core-Level A, B, C und D?

Seit August 2025 ordnet SAP Erweiterungen in vier Level ein. Level A nutzt nur öffentlich freigegebene, stabile Schnittstellen. Level B nutzt zusätzlich klassische SAP-APIs. Level C greift auf SAP-interne Objekte zu und muss bei jedem Upgrade geprüft werden. Level D umfasst Modifikationen, Schreibzugriffe auf SAP-Tabellen, implizite Erweiterungen und andere nicht empfohlene Techniken und stellt das höchste Risiko dar.

Ist Clean Core bei RISE with SAP verpflichtend?

Nicht als pauschale Regel. S/4HANA Cloud Public Edition erlaubt Erweiterungen nur über freigegebene Schnittstellen und erzwingt Clean Core daher technisch. In der Private Edition können Sie den Kern weiterhin modifizieren, daher ist Clean Core dort eine Governance-Entscheidung. SAP weist die Clean-Core-Umsetzung über das Dashboard der RISE with SAP Methodology aus.

Wann endet der Support für SAP ECC?

Für SAP ERP 6.0 auf den Enhancement Packages 6 bis 8 endet die Standardwartung am 31. Dezember 2027, mit optionaler erweiterter Wartung bis zum 31. Dezember 2030 gegen Aufpreis. Frühere Enhancement Packages sind Ende 2025 aus der Standardwartung ausgelaufen. Die Übergangsoption für SAP ERP, Private Edition reicht nur für berechtigte große Systeme bis 2033, die vor Ende 2030 auf SAP ERP, Private Edition auf SAP HANA umgezogen sind.

Wie bewerte ich die Clean-Core-Reife meines SAP-Systems?

Beginnen Sie mit dem SAP Readiness Check und Nutzungsdaten zu Ihrem Custom Code. Ordnen Sie das, was noch genutzt wird, in die Level A bis D ein und nutzen Sie für Prüfungen auf Code-Ebene das ABAP Test Cockpit. Entscheiden Sie dann je Objekt, ob Sie es abschalten, auf eine freigegebene Schnittstelle umstellen, auf SAP BTP neu bauen oder mit dokumentiertem Grund behalten. Prüfen Sie parallel Prozesse und Daten, denn sie erklären meist, warum der Code existiert.

Welche Rolle spielt SAP BTP in einer Clean-Core-Strategie?

Auf SAP BTP laufen die Side-by-side-Erweiterungen. Anwendungen auf BTP verbinden sich über APIs und Events mit S/4HANA, sodass der Kern unangetastet bleibt. SAP empfiehlt einen BTP-first-Ansatz, mit On-stack-Erweiterungen in ABAP Cloud dort, wo die Logik nah an den Daten oder der Transaktion liegen muss.