Custom Code ist eines der größten Risiken bei der S/4HANA Migration – und wird oft unterschätzt. Erfahren Sie, wie Sie Budget- und Zeitrisiken frühzeitig vermeiden.
In vielen bestehenden ECC-Systemen machen Eigenentwicklungen 20 bis 40 Prozent des gesamten Codes aus. Über Jahre hinweg entstanden individuelle Reports, Schnittstellen, Modifikationen und Z-Programme, die tief in geschäftskritische Prozesse integriert sind. Genau hier liegt eines der größten S/4HANA Conversion Risiken.
Warum?
Weil sich mit SAP S/4HANA zentrale Datenstrukturen, Tabellenlogiken und Performance-Mechanismen grundlegend verändern. Was unter SAP ECC stabil lief, kann unter SAP HANA inkompatibel, ineffizient oder sogar funktionsunfähig werden. Ohne systematische Analyse wird Custom Code bei der S/4HANA Migration schnell zum Kostentreiber – und im schlimmsten Fall zum Projektstopper.
Für Entscheidungsträger bedeutet das:
Die zentrale Frage lautet daher nicht, ob Custom Code geprüft werden sollte – sondern wie früh, wie strukturiert und mit welcher Methodik.
In diesem Artikel zeigen wir,
Sichern Sie Ihre S/4HANA Conversion frühzeitig ab.
S/4HANA-Risiko bewerten
Custom Code ist kein grundsätzliches Problem. Viele Eigenentwicklungen entstanden aus berechtigten fachlichen Anforderungen – etwa zur Abbildung komplexer Geschäftslogik, regulatorischer Besonderheiten oder branchenspezifischer Prozesse.
Zum Risiko wird Custom Code jedoch dann, wenn sich die technologische Grundlage des Systems fundamental verändert – wie bei der Conversion von SAP ECC auf SAP S/4HANA.
Im Folgenden die zentralen Risikofaktoren:
Mit SAP S/4HANA wurden zahlreiche Tabellen zusammengeführt, vereinfacht oder vollständig ersetzt – im Rahmen der sogenannten Simplification Items.
Beispiele:
Custom Code, der direkt auf alte Tabellen zugreift oder spezifische Datenbanklogiken nutzt, funktioniert nach der Migration häufig nicht mehr wie vorgesehen. Ohne vorherige Analyse entsteht hier ein erhebliches S/4HANA Conversion Risiko.
SAP HANA basiert auf einer In-Memory-Datenbankarchitektur. Viele ältere ABAP-Programme wurden jedoch für klassische, zeilenbasierte Datenbanken entwickelt.
Typische Probleme:
Was früher „ausreichend performant“ war, kann unter HANA zu massiven Laufzeitproblemen führen – insbesondere bei Reports, Batch-Jobs oder Schnittstellenverarbeitungen.
In gewachsenen ECC-Systemen ist oft unklar:
Ohne saubere Analyse besteht die Gefahr, dass:
Gerade in internationalen Systemlandschaften mit mehreren Rollouts erhöht sich dadurch die Projektkomplexität erheblich.
Eines der häufigsten Probleme in S/4HANA-Conversion-Projekten:
Custom Code wird zu spät bewertet.
Wenn Eigenentwicklungen erst während der technischen Conversion auffallen, führt das zu:
Damit wird Custom Code schnell zum zentralen Treiber für Termin- und Budgetüberschreitungen.
Unternehmen, die ihren bestehenden Code nahezu 1:1 übernehmen, riskieren langfristig:
Eine ungeprüfte Übernahme von Custom Code steht häufig im direkten Widerspruch zu einer Clean-Core-Strategie.
Custom Code ist nicht per se problematisch – aber ungeprüfter Custom Code ist eines der größten Risiken bei der S/4HANA Conversion.
Die entscheidende Frage lautet daher:
Wie lässt sich systematisch unterscheiden zwischen
Genau hier setzt eine strukturierte Custom-Code-Analyse an.
Nicht jede Eigenentwicklung stellt das gleiche Risiko dar. In der Praxis zeigt sich, dass bestimmte Arten von Custom Code im Rahmen einer S/4HANA Conversion deutlich anfälliger für technische oder fachliche Probleme sind.
Eine strukturierte Bewertung nach Typ und Risiko-Level ist daher essenziell.
Direkte Modifikationen am SAP-Standard gehören zu den kritischsten Altlasten in bestehenden Systemen.
Warum problematisch?
Bei der Migration auf SAP S/4HANA müssen diese Modifikationen meist vollständig neu bewertet oder zurückgebaut werden. Sie stehen im direkten Widerspruch zur Clean-Core-Strategie.
Risiko-Level: Sehr hoch
Klassische Z-Reports greifen häufig direkt auf Tabellen zu, die in S/4HANA nicht mehr existieren oder strukturell verändert wurden.
Typische Risiken:
Besonders bei Finanz- oder Logistikreports kann dies zu funktionalen Fehlern oder Laufzeitproblemen führen.
Risiko-Level: Hoch
Erweiterungen über User Exits oder BAdIs sind grundsätzlich upgrade-freundlicher als Modifikationen. Dennoch können sie problematisch werden, wenn:
Diese Erweiterungen müssen funktional und technisch geprüft werden.
Risiko-Level: Mittel bis hoch
Viele ECC-Systeme sind über Jahre gewachsen und tief in die Systemlandschaft integriert.
Eigenentwicklungen betreffen häufig:
Bei einer S/4HANA Migration können sich Datenformate, Felder oder Prozesslogiken ändern – mit direkten Auswirkungen auf externe Systeme.
Risiko-Level: Mittel bis hoch (abhängig von Systemlandschaft)
Custom Code im Finanzwesen oder in der Materialwirtschaft ist besonders sensibel.
Beispielsweise durch:
Hier kann eine unzureichende Analyse nicht nur ein technisches, sondern auch ein Compliance-Risiko darstellen.
Risiko-Level: Hoch
| Typ der Eigenentwicklung | Technisches Risiko | Fachliches Risiko | Empfehlung |
| Modifikationen im Standard | Sehr hoch | Hoch | Rückbau & Neuimplementierung prüfen |
| Z-Reports | Hoch | Mittel | HANA-Optimierung oder Ablösung |
| User Exits / BAdIs | Mittel | Mittel | Funktionale Bewertung erforderlich |
| Schnittstellen-Logik | Mittel | Hoch | End-to-End-Analyse durchführen |
| FI/CO-Entwicklungen | Hoch | Sehr hoch | Frühzeitige Fachbereichseinbindung |
Die größte Gefahr bei Custom Code in der S/4HANA Migration besteht nicht im Code selbst – sondern in fehlender Priorisierung.
Unternehmen, die alle Eigenentwicklungen gleich behandeln, verlieren Zeit und Budget.
Erfolgreiche Projekte unterscheiden klar zwischen:
Die Grundlage dafür ist eine systematische Analyse.
Custom Code strategisch bewerten statt unkontrolliert migrieren.
Jetzt Bewertung anfragen
Eine erfolgreiche S/4HANA Migration beginnt nicht mit der technischen Systemkopie – sondern mit einer strukturierten Analyse der bestehenden Eigenentwicklungen.
Ziel ist es, Transparenz zu schaffen und Custom Code systematisch zu bewerten:
Für diese Bewertung stehen mehrere Werkzeuge und Methoden zur Verfügung.
Der SAP Readiness Check liefert eine erste technische Bestandsaufnahme des Systems.
Er identifiziert unter anderem:
Der Readiness Check ersetzt jedoch keine detaillierte Custom-Code-Analyse – er bildet lediglich die Ausgangsbasis.
Das ABAP Test Cockpit (ATC) ist eines der wichtigsten Werkzeuge zur Bewertung von Custom Code im Kontext von SAP S/4HANA.
Mit ATC lassen sich:
ATC ermöglicht eine technische Risikoklassifizierung – ersetzt jedoch keine fachliche Bewertung.
In vielen Unternehmen existieren tausende Z-Programme – doch ein erheblicher Teil davon wird nicht mehr aktiv genutzt.
Eine Usage Analysis beantwortet zentrale Fragen:
Erfahrungsgemäß lassen sich dadurch 15–30 % des Custom Codes vor Projektstart eliminieren.
Das reduziert Komplexität, Testaufwand und Projektkosten signifikant.
Der Simplification Item Check prüft, ob Eigenentwicklungen von strukturellen Änderungen in S/4HANA betroffen sind.
Besonders relevant bei:
Ohne diesen Schritt besteht ein erhebliches funktionales Risiko.
Technische Kompatibilität allein reicht nicht aus.
Ein strukturierter Bewertungsprozess sollte zusätzlich klären:
Hier zeigt sich häufig:
Was technisch migrierbar ist, ist fachlich nicht mehr sinnvoll.
Eine professionelle Custom-Code-Analyse erfolgt in fünf Schritten:
Dieses strukturierte Vorgehen minimiert das S/4HANA Conversion Risiko deutlich – und schafft eine belastbare Grundlage für Projektplanung und Budgetierung.
Custom Code sollte nicht „nebenbei“ bewertet werden.
Er ist ein eigenständiger Workstream in jeder professionellen S/4HANA Conversion.
Je früher Transparenz geschaffen wird, desto besser lassen sich:
Die Analyse schafft Transparenz – doch der eigentliche Mehrwert entsteht erst durch klare Entscheidungen.
Nicht jeder Custom Code muss entfernt werden.
Aber jeder Custom Code muss bewertet werden.
Im Rahmen einer strukturierten S/4HANA Migration haben sich vier strategische Handlungsoptionen bewährt.
Ein erheblicher Anteil historischer Eigenentwicklungen wird im Tagesgeschäft nicht mehr genutzt.
Typische Kandidaten:
Das gezielte Entfernen nicht genutzter Objekte reduziert:
Gerade im Kontext einer Clean-Core-Strategie ist dieser Schritt essenziell.
Mit SAP S/4HANA wurden zahlreiche Funktionen in den Standard integriert, die früher nur über Eigenentwicklungen abbildbar waren.
Beispiele:
Statt Custom Code technisch anzupassen, kann es strategisch sinnvoller sein, auf Standardprozesse umzusteigen.
Vorteil:
Geschäftskritische Logiken lassen sich nicht immer eliminieren oder standardisieren.
In diesen Fällen ist Refactoring die richtige Option:
Ziel ist nicht bloß „Lauffähigkeit“, sondern langfristige Performance- und Wartungsfähigkeit.
Bestimmte individuelle Anforderungen gehören nicht mehr in den ERP-Kern.
Hier bietet sich ein Side-by-Side-Ansatz auf der SAP Business Technology Platform an.
Vorteile:
Dieser Ansatz gewinnt insbesondere bei Unternehmen mit internationaler Systemlandschaft an Bedeutung.
Die Kernfrage lautet nicht:
„Wie migrieren wir unseren Custom Code?“
Sondern:
„Welche Rolle soll individuelle Logik in unserer zukünftigen Systemarchitektur spielen?“
Ein strukturierter Entscheidungsbaum hilft:
Richtig umgesetzt wird die Custom-Code-Bereinigung nicht nur zur Risikominimierung – sondern zum strategischen Hebel:
Damit wird aus einem klassischen S/4HANA Conversion Risiko eine Chance zur nachhaltigen Systemmodernisierung.
Schaffen Sie eine belastbare Entscheidungsgrundlage für Ihre S/4HANA-Migration.
In der Praxis scheitern S/4HANA-Conversion-Projekte selten an der Technologie selbst.
Die größten Probleme entstehen durch falsche Priorisierung und mangelnde Struktur im Umgang mit Custom Code.
Die folgenden Fehler treten besonders häufig auf:
Einer der gravierendsten Fehler ist es, die Bewertung von Eigenentwicklungen erst während der technischen Conversion zu starten.
Konsequenzen:
Custom Code muss als eigener Workstream bereits in der Projektvorbereitungsphase berücksichtigt werden.
Aus Zeitdruck entscheiden sich manche Unternehmen dafür, nahezu den gesamten Custom Code unverändert zu migrieren.
Kurzfristig mag dies Aufwand sparen.
Langfristig führt es jedoch zu:
Eine S/4HANA Migration ist keine reine technische Transformation – sie ist eine Chance zur Systemvereinfachung.
ATC-Checks und Syntaxanalysen liefern wichtige Informationen – ersetzen aber keine fachliche Bewertung.
Ein häufiger Fehler:
Code wird technisch als „kompatibel“ eingestuft, obwohl:
Ohne Einbindung der Fachbereiche bleibt Optimierungspotenzial ungenutzt.
Custom Code ist oft tief in Schnittstellen-Logiken eingebettet.
Werden Änderungen isoliert betrachtet, können unerwartete Nebeneffekte auftreten:
Eine End-to-End-Sicht auf die Systemlandschaft ist daher unerlässlich.
Selbst wenn die Bereinigung erfolgreich war, entsteht ein neues Risiko, wenn keine Governance-Struktur definiert wird.
Ohne klare Regeln für zukünftige Eigenentwicklungen droht:
Eine nachhaltige Custom-Code-Strategie endet nicht mit der Conversion.
Fehler im Umgang mit Custom Code wirken sich nicht nur technisch aus.
Sie beeinflussen:
Damit wird Custom Code zu einem zentralen Hebel für den Erfolg oder Misserfolg der gesamten S/4HANA Conversion.
Custom Code ist kein isoliertes Technikthema.
Er betrifft Architektur, Prozesse, Governance und strategische Ausrichtung gleichermaßen.
Unternehmen, die strukturiert vorgehen, verwandeln ein potenzielles S/4HANA Conversion Risiko in einen klar steuerbaren Modernisierungsschritt.
Die erfolgreiche Transformation von SAP ECC zu SAP S/4HANA erfordert mehr als eine technische Analyse einzelner Programme. Entscheidend ist ein ganzheitlicher Ansatz, der Technologie, Fachbereich und Zielarchitektur zusammenführt.
In unseren S/4HANA-Conversion-Projekten behandeln wir Custom Code als eigenständigen strategischen Workstream – mit klar definierten Phasen und Entscheidungspunkten.
Bereits in der Vorstudienphase führen wir eine strukturierte Custom-Code-Analyse durch:
Das Ziel: belastbare Entscheidungsgrundlagen für Budget- und Ressourcenplanung.
Reine Kompatibilitätsprüfungen reichen nicht aus.
Deshalb verbinden wir:
So wird klar unterschieden zwischen:
Unser Ziel ist nicht die bloße Migration von Custom Code, sondern eine langfristig wartbare Systemarchitektur.
Dabei verfolgen wir drei Prinzipien:
Dieser Ansatz unterstützt eine nachhaltige Clean-Core-Strategie und erleichtert zukünftige Releases und Innovationen.
Auf Basis der Analyse erstellen wir:
Damit wird das Thema Custom Code nicht zum unkalkulierbaren Risiko – sondern zu einem planbaren Modernisierungsschritt.
Gerade bei globalen Systemlandschaften mit mehreren Mandanten oder Ländern ist die Komplexität hoch.
Unsere Projektpraxis zeigt:
Ein strukturierter Bewertungsrahmen verhindert, dass sich Altlasten in neue Systemgenerationen übertragen.
Unternehmen, die Custom Code frühzeitig und strukturiert angehen,
Custom Code ist damit kein Nebenthema – sondern ein zentraler Erfolgsfaktor der gesamten Transformation.
Vermeiden Sie Budget- und Zeitrisiken durch strukturierte Vorbereitung.
Jetzt unverbindlich prüfen
Nein. Nicht jede Eigenentwicklung stellt ein Risiko dar. Entscheidend ist eine strukturierte Bewertung.
Geschäftskritischer Code kann optimiert oder modernisiert werden, während veraltete oder ungenutzte Objekte eliminiert werden sollten. Ziel ist nicht maximale Reduktion, sondern strategische Architekturklarheit.
Custom Code gehört zu den häufigsten Ursachen für Verzögerungen und Budgetüberschreitungen.
Besonders kritisch sind Modifikationen im SAP-Standard, direkte Tabellenzugriffe und nicht HANA-optimierte Programme. Ohne frühzeitige Analyse entsteht ein erhebliches S/4HANA Conversion Risiko.
Für die technische Bewertung werden unter anderem eingesetzt:
Diese Werkzeuge identifizieren technische Inkompatibilitäten, ersetzen jedoch keine fachliche Bewertung.
Die Dauer hängt von der Systemgröße und Anzahl der Eigenentwicklungen ab.
In mittelgroßen Systemlandschaften kann eine erste strukturierte Bewertung innerhalb weniger Wochen erfolgen. Entscheidend ist eine klare Priorisierung nach Business Impact.
Teilweise ja.
Allerdings müssen Programme auf Kompatibilität mit dem neuen Datenmodell und der HANA-Architektur geprüft werden. In vielen Fällen ist Refactoring oder eine Ablösung durch Standardfunktionen sinnvoller.
Ja – wenn er bewusst gesteuert wird.
Eine Clean-Core-Strategie bedeutet nicht vollständigen Verzicht auf Individualisierung, sondern eine klare Trennung zwischen Kernprozessen und Erweiterungen. Moderne Erweiterungen können beispielsweise Side-by-Side umgesetzt werden.