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:

• Verzögerungen in der Projektlaufzeit
• Ungeplante Budgetsteigerungen
• Risiken für Abschluss- und Reportingprozesse
• Performance-Einbußen im Echtbetrieb
• Einschränkungen bei zukünftigen Innovationen (Clean Core, Cloud-Strategie)

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,

• welche Risiken Eigenentwicklungen konkret verursachen,
• wie Unternehmen Custom Code vor der S/4HANA Conversion systematisch analysieren,
• welche Bereinigungsstrategien sich bewährt haben,
• und wie sich langfristig eine wartbare, zukunftsfähige Systemarchitektur sichern lässt.

Sichern Sie Ihre S/4HANA Conversion frühzeitig ab.
S/4HANA-Risiko bewerten

Warum wird Custom Code bei der S/4HANA Migration zum Risiko?

Warum wird Custom Code bei der S/4HANA Migration zum Risiko?

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:

1. Technische Inkompatibilitäten durch verändertes Datenmodell

Mit SAP S/4HANA wurden zahlreiche Tabellen zusammengeführt, vereinfacht oder vollständig ersetzt – im Rahmen der sogenannten Simplification Items.

Beispiele:

• Wegfall klassischer FI-Tabellen
• Neue Universal Journal-Logik (ACDOCA)
• Änderungen in Material- und Logistikstrukturen

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.

2. Performance-Probleme unter SAP HANA

SAP HANA basiert auf einer In-Memory-Datenbankarchitektur. Viele ältere ABAP-Programme wurden jedoch für klassische, zeilenbasierte Datenbanken entwickelt.

Typische Probleme:

• Unoptimierte SELECT-Schleifen
• Mehrfachzugriffe auf große Datenmengen
• Fehlende Nutzung von HANA-optimierten Views

Was früher „ausreichend performant“ war, kann unter HANA zu massiven Laufzeitproblemen führen – insbesondere bei Reports, Batch-Jobs oder Schnittstellenverarbeitungen.

3. Fehlende Transparenz und Dokumentation

In gewachsenen ECC-Systemen ist oft unklar:

• Welche Eigenentwicklungen tatsächlich noch genutzt werden
• Welche Programme geschäftskritisch sind
• Wo Modifikationen im Standard vorgenommen wurden

Ohne saubere Analyse besteht die Gefahr, dass:

• Unnötiger Code mit migriert wird
• Kritischer Code übersehen wird
• Abhängigkeiten zwischen Modulen unterschätzt werden

Gerade in internationalen Systemlandschaften mit mehreren Rollouts erhöht sich dadurch die Projektkomplexität erheblich.

4. Budget- und Zeitrisiken im Projektverlauf

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:

• Ungeplanten Anpassungsaufwänden
• Verzögerungen im Testing
• Mehrfachem Re-Design von Prozessen
• Nachverhandlungen von Projektbudgets

Damit wird Custom Code schnell zum zentralen Treiber für Termin- und Budgetüberschreitungen.

5. Strategische Einschränkungen (Clean Core & Innovationsfähigkeit)

Unternehmen, die ihren bestehenden Code nahezu 1:1 übernehmen, riskieren langfristig:

• Erhöhte Wartungskosten
• Komplexere Release-Wechsel
• Einschränkungen bei Cloud-Strategien
• Geringere Innovationsgeschwindigkeit

Eine ungeprüfte Übernahme von Custom Code steht häufig im direkten Widerspruch zu einer Clean-Core-Strategie.

Zwischenfazit

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

• geschäftskritischer Logik, die erhalten bleiben muss,
• unnötigen Altlasten, die entfernt werden sollten,
• und Optimierungspotenzial, das im Zuge der Migration genutzt werden kann?

Genau hier setzt eine strukturierte Custom-Code-Analyse an.

Welche Arten von Custom Code sind bei der S/4HANA Migration besonders kritisch?

Welche Arten von Custom Code sind bei der S/4HANA Migration besonders kritisch?

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.

1. Modifikationen im SAP-Standard (höchstes Risiko)

Direkte Modifikationen am SAP-Standard gehören zu den kritischsten Altlasten in bestehenden Systemen.

Warum problematisch?

• Standardobjekte wurden verändert
• Updates werden erschwert oder blockiert
• Hoher Anpassungsaufwand bei der Conversion

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

2. Z-Programme und kundenspezifische Reports

Klassische Z-Reports greifen häufig direkt auf Tabellen zu, die in S/4HANA nicht mehr existieren oder strukturell verändert wurden.

Typische Risiken:

• Zugriff auf obsolete Tabellen
• Nicht-HANA-optimierte SELECT-Logik
• Veraltete Performance-Patterns

Besonders bei Finanz- oder Logistikreports kann dies zu funktionalen Fehlern oder Laufzeitproblemen führen.

Risiko-Level: Hoch

3. User Exits, BAdIs und Enhancements

Erweiterungen über User Exits oder BAdIs sind grundsätzlich upgrade-freundlicher als Modifikationen. Dennoch können sie problematisch werden, wenn:

• Geschäftslogiken stark von alten Datenstrukturen abhängen
• Neue Prozessmodelle in S/4HANA greifen
• Fiori-basierte Prozesse andere Logiken verwenden

Diese Erweiterungen müssen funktional und technisch geprüft werden.

Risiko-Level: Mittel bis hoch

4. Schnittstellen-Logik und Integrationen

Viele ECC-Systeme sind über Jahre gewachsen und tief in die Systemlandschaft integriert.

Eigenentwicklungen betreffen häufig:

• IDoc-Verarbeitungen
• RFC-Verbindungen
• Batch-Schnittstellen
• Individuelle Middleware-Logiken

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)

5. Individuelle Entwicklungen in FI/CO und Logistik

Custom Code im Finanzwesen oder in der Materialwirtschaft ist besonders sensibel.

Beispielsweise durch:

• Umstellung auf das Universal Journal
• Neue Bewertungslogiken
• Vereinfachte Lager- und Bestandsstrukturen

Hier kann eine unzureichende Analyse nicht nur ein technisches, sondern auch ein Compliance-Risiko darstellen.

Risiko-Level: Hoch

Übersicht: Risikobewertung nach Custom-Code-Typ

Entscheidender Punkt

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:

• geschäftskritisch
• technisch kritisch
• obsolet
• strategisch ersetzbar durch Standard

Die Grundlage dafür ist eine systematische Analyse.

Custom Code strategisch bewerten statt unkontrolliert migrieren.
Jetzt Bewertung anfragen

Wie analysiert man Custom Code vor der S/4HANA Conversion?

Wie analysiert man Custom Code vor der S/4HANA Conversion?

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:

• Wird der Code überhaupt noch genutzt?
• Ist er mit SAP S/4HANA kompatibel?
• Lässt er sich durch Standardfunktionen ersetzen?
• Muss er technisch optimiert oder fachlich neu gedacht werden?

Für diese Bewertung stehen mehrere Werkzeuge und Methoden zur Verfügung.

1. SAP Readiness Check

Der SAP Readiness Check liefert eine erste technische Bestandsaufnahme des Systems.

Er identifiziert unter anderem:

• Obsolete Objekte
• Vereinfachungsrelevante Funktionen (Simplification Items)
• Technische Vorbedingungen für die Conversion

Der Readiness Check ersetzt jedoch keine detaillierte Custom-Code-Analyse – er bildet lediglich die Ausgangsbasis.

2. ATC (ABAP Test Cockpit)

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:

• Syntax- und Kompatibilitätsprüfungen durchführen
• Veraltete Datenbankzugriffe identifizieren
• HANA-relevante Performance-Probleme erkennen
• Verweise auf nicht mehr unterstützte Objekte aufdecken

ATC ermöglicht eine technische Risikoklassifizierung – ersetzt jedoch keine fachliche Bewertung.

3. Custom Code Usage Analysis

In vielen Unternehmen existieren tausende Z-Programme – doch ein erheblicher Teil davon wird nicht mehr aktiv genutzt.

Eine Usage Analysis beantwortet zentrale Fragen:

• Welche Programme wurden in den letzten 12–24 Monaten ausgeführt?
• Welche Reports sind geschäftskritisch?
• Welche Objekte können archiviert oder gelöscht werden?

Erfahrungsgemäß lassen sich dadurch 15–30 % des Custom Codes vor Projektstart eliminieren.

Das reduziert Komplexität, Testaufwand und Projektkosten signifikant.

4. Simplification Item Check

Der Simplification Item Check prüft, ob Eigenentwicklungen von strukturellen Änderungen in S/4HANA betroffen sind.

Besonders relevant bei:

• FI/CO-Logiken (Universal Journal)
• Material- und Lagerprozessen
• Kreditmanagement
• Business Partner-Konzept

Ohne diesen Schritt besteht ein erhebliches funktionales Risiko.

5. Fachliche Bewertung (Business Impact Assessment)

Technische Kompatibilität allein reicht nicht aus.

Ein strukturierter Bewertungsprozess sollte zusätzlich klären:

• Unterstützt die Entwicklung noch aktuelle Geschäftsprozesse?
• Gibt es inzwischen eine Standardfunktion in S/4HANA?
• Ist die Logik strategisch noch gewünscht?

Hier zeigt sich häufig:
Was technisch migrierbar ist, ist fachlich nicht mehr sinnvoll.

Empfohlene Vorgehensweise (Best Practice)

Eine professionelle Custom-Code-Analyse erfolgt in fünf Schritten:

1. Systemscan & technische Klassifizierung
2. Usage-Analyse
3. Fachliche Priorisierung
4. Risiko- und Aufwandsschätzung
5. Entscheidungslogik: Eliminieren, Optimieren oder Neu implementieren

Dieses strukturierte Vorgehen minimiert das S/4HANA Conversion Risiko deutlich – und schafft eine belastbare Grundlage für Projektplanung und Budgetierung.

Fazit dieses Abschnitts

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:

• Projektlaufzeiten realistisch planen
• Budgetrisiken vermeiden
• Clean-Core-Ziele umsetzen
• Innovationsfähigkeit sichern

Strategien zur Bereinigung von Custom Code bei der S/4HANA Migration

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.

1. Eliminieren: Technische Altlasten konsequent abbauen

Ein erheblicher Anteil historischer Eigenentwicklungen wird im Tagesgeschäft nicht mehr genutzt.

Typische Kandidaten:

• Alte Reports ohne aktive Nutzung
• Übergangslösungen aus früheren Projekten
• Doppelte Funktionalitäten
• Temporäre Schnittstellen

Das gezielte Entfernen nicht genutzter Objekte reduziert:

• Systemkomplexität
• Testaufwand
• Wartungskosten
• zukünftige Upgrade-Risiken

Gerade im Kontext einer Clean-Core-Strategie ist dieser Schritt essenziell.

2. Ersetzen durch SAP-Standard (Standardisierung nutzen)

Mit SAP S/4HANA wurden zahlreiche Funktionen in den Standard integriert, die früher nur über Eigenentwicklungen abbildbar waren.

Beispiele:

• Erweiterte Reporting-Möglichkeiten
• Vereinfachte Finanzprozesse
• Integrierte Analytics-Funktionen
• Optimierte Logistikprozesse

Statt Custom Code technisch anzupassen, kann es strategisch sinnvoller sein, auf Standardprozesse umzusteigen.

Vorteil:

• Upgrade-Sicherheit
• Geringere Wartung
• Schnellere Innovationszyklen

3. Refactoring: HANA-optimierte Neuentwicklung

Geschäftskritische Logiken lassen sich nicht immer eliminieren oder standardisieren.

In diesen Fällen ist Refactoring die richtige Option:

• Anpassung von SELECT-Logiken
• Nutzung von CDS Views
• Performance-Optimierung für In-Memory-Verarbeitung
• Modernisierung von ABAP-Code

Ziel ist nicht bloß „Lauffähigkeit“, sondern langfristige Performance- und Wartungsfähigkeit.

4. Side-by-Side-Ansatz auf SAP BTP

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:

• Entkopplung vom Core-System
• Cloud-native Erweiterungen
• Schnellere Innovationszyklen
• Unterstützung einer klaren Clean-Core-Architektur

Dieser Ansatz gewinnt insbesondere bei Unternehmen mit internationaler Systemlandschaft an Bedeutung.

Strategische Entscheidungslogik

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:

• Kein Business Value → Eliminieren
• Standard verfügbar → Ersetzen
• Geschäftskritisch → Refactoring
• Innovationsgetrieben → Side-by-Side

Von der Risiko-Reduktion zur Architektur-Strategie

Richtig umgesetzt wird die Custom-Code-Bereinigung nicht nur zur Risikominimierung – sondern zum strategischen Hebel:

• Reduktion technischer Schulden
• Vereinfachung der IT-Landschaft
• Beschleunigung zukünftiger Releases
• Grundlage für Cloud- und AI-Initiativen

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.

Erstberatung anfordern

Typische Fehler bei der Custom-Code-Bereinigung – und wie man sie vermeidet

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:

1. Custom Code wird zu spät analysiert

Einer der gravierendsten Fehler ist es, die Bewertung von Eigenentwicklungen erst während der technischen Conversion zu starten.

Konsequenzen:

• Ungeplante Anpassungsaufwände
• Verzögerungen im Testzyklus
• Nachträgliche Prozessanpassungen
• Budgetüberschreitungen

Custom Code muss als eigener Workstream bereits in der Projektvorbereitungsphase berücksichtigt werden.

2. „Lift-and-Shift“-Denken: Alles wird 1:1 übernommen

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:

• Erhöhter Komplexität
• Einschränkungen bei Releases
• Höheren Wartungskosten
• Verpasster Standardisierung

Eine S/4HANA Migration ist keine reine technische Transformation – sie ist eine Chance zur Systemvereinfachung.

3. Rein technische Bewertung ohne Business-Kontext

ATC-Checks und Syntaxanalysen liefern wichtige Informationen – ersetzen aber keine fachliche Bewertung.

Ein häufiger Fehler:

Code wird technisch als „kompatibel“ eingestuft, obwohl:

• Die zugrunde liegende Geschäftslogik veraltet ist
• Der Prozess inzwischen im Standard abgebildet werden kann
• Die Anforderung strategisch nicht mehr relevant ist

Ohne Einbindung der Fachbereiche bleibt Optimierungspotenzial ungenutzt.

4. Unterschätzung von Integrationsabhängigkeiten

Custom Code ist oft tief in Schnittstellen-Logiken eingebettet.

Werden Änderungen isoliert betrachtet, können unerwartete Nebeneffekte auftreten:

• Fehler in Drittsystemen
• Inkonsistente Datenflüsse
• Unterbrechungen im Echtbetrieb

Eine End-to-End-Sicht auf die Systemlandschaft ist daher unerlässlich.

5. Keine klare Governance nach der Migration

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:

• Wiederaufbau technischer Schulden
• Aufweichung der Clean-Core-Strategie
• Steigende Betriebskosten

Eine nachhaltige Custom-Code-Strategie endet nicht mit der Conversion.

Warum diese Fehler so teuer sind

Fehler im Umgang mit Custom Code wirken sich nicht nur technisch aus.

Sie beeinflussen:

• Projektlaufzeit
• Budgetplanung
• Stabilität von Finanz- und Logistikprozessen
• Innovationsfähigkeit der gesamten IT-Landschaft

Damit wird Custom Code zu einem zentralen Hebel für den Erfolg oder Misserfolg der gesamten S/4HANA Conversion.

Zwischenfazit

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.

Wie LeverX Custom-Code-Risiken in S/4HANA-Projekten strukturiert minimiert

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.

1. Frühzeitige Transparenz vor Projektstart

Bereits in der Vorstudienphase führen wir eine strukturierte Custom-Code-Analyse durch:

• Technische ATC-Bewertung
• Usage-Analyse zur Identifikation ungenutzter Objekte
• Simplification-Impact-Analyse
• Erste Aufwandsschätzung pro Objektklasse

Das Ziel: belastbare Entscheidungsgrundlagen für Budget- und Ressourcenplanung.

2. Kombination aus technischer und fachlicher Bewertung

Reine Kompatibilitätsprüfungen reichen nicht aus.

Deshalb verbinden wir:

• Systemarchitektur-Analyse
• Fachbereichs-Workshops
• Prozessbewertung
• Business-Impact-Scoring

So wird klar unterschieden zwischen:

• geschäftskritisch
• standardisierbar
• obsolet
• strategisch auslagerbar (z. B. Side-by-Side)

3. Clean-Core-orientierte Entscheidungslogik

Unser Ziel ist nicht die bloße Migration von Custom Code, sondern eine langfristig wartbare Systemarchitektur.

Dabei verfolgen wir drei Prinzipien:

• Standard vor Individualisierung
• Entkopplung nicht-kernrelevanter Logik
• Reduktion technischer Schulden

Dieser Ansatz unterstützt eine nachhaltige Clean-Core-Strategie und erleichtert zukünftige Releases und Innovationen.

4. Transparente Roadmap für Umsetzung und Testing

Auf Basis der Analyse erstellen wir:

• Priorisierte Umsetzungspläne
• Aufwandsschätzungen je Kategorie
• Testing-Strategien für geschäftskritische Logik
• Governance-Empfehlungen für die Post-Go-Live-Phase

Damit wird das Thema Custom Code nicht zum unkalkulierbaren Risiko – sondern zu einem planbaren Modernisierungsschritt.

5. Erfahrung aus internationalen Rollouts

Gerade bei globalen Systemlandschaften mit mehreren Mandanten oder Ländern ist die Komplexität hoch.

Unsere Projektpraxis zeigt:

• Custom Code variiert stark zwischen Regionen
• Lokale Compliance-Anforderungen spielen eine Rolle
• Rollout-Strategien müssen skalierbar sein

Ein strukturierter Bewertungsrahmen verhindert, dass sich Altlasten in neue Systemgenerationen übertragen.

Ergebnis: Von Risiko zu strategischer Architekturentscheidung

Unternehmen, die Custom Code frühzeitig und strukturiert angehen,

• reduzieren ihr S/4HANA Conversion Risiko,
• stabilisieren Projektlaufzeiten,
• schaffen Budgettransparenz,
• und legen die Grundlage für eine innovationsfähige ERP-Architektur.

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

🔵 FAQ – Häufige Fragen zu Custom Code bei der S/4HANA Migration

FAQ – Häufige Fragen zu Custom Code bei der S/4HANA Migration

Muss jeder Custom Code vor der S/4HANA Migration entfernt werden?

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.

Wie groß ist das Risiko von Custom Code bei einer S/4HANA Conversion?

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.

Welche Tools helfen bei der Analyse von Custom Code?

Für die technische Bewertung werden unter anderem eingesetzt:

• SAP Readiness Check
• ABAP Test Cockpit (ATC)
• Simplification Item Check
• Custom Code Usage Analysis

Diese Werkzeuge identifizieren technische Inkompatibilitäten, ersetzen jedoch keine fachliche Bewertung.

Wie lange dauert eine Custom-Code-Analyse?

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.

Kann Custom Code in S/4HANA weiterverwendet werden?

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.

Ist Custom Code mit einer Clean-Core-Strategie vereinbar?

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.