Die meisten produktiven SAP-Systeme enthalten mehr kundeneigenen Code, als viele Verantwortliche vermuten. Über Jahre sind Z-Reports, User-Exits, Implicit Enhancements und modifizierte Includes entstanden, die geschäftskritische Logik tragen: Preisfindung, Genehmigungsprozesse, branchenspezifische Abläufe. Genau dieser Code wird bei der Umstellung auf S/4HANA zum eigentlichen Aufwandstreiber, nicht der Standard.
Der Grund liegt in der veränderten Architektur. S/4HANA bringt ein anderes Datenmodell mit, geänderte Kern-Tabellen, das Business-Partner-Konzept und die In-Memory-Verarbeitung von SAP HANA. Code, der in ECC über Jahre zuverlässig lief, kann unter S/4HANA fehlerhafte Ergebnisse liefern oder stillschweigend falsche Werte produzieren, die erst im Monatsabschluss oder im Kundenprozess auffallen.
Custom-Code-Remediation ist kein einmaliger Migrationsschritt, sondern eine Investition in die dauerhafte Wartbarkeit. Jedes nicht bereinigte Z-Objekt bleibt ein Kostenpunkt bei jedem künftigen Release-Wechsel.
Warum Altcode unter S/4HANA bricht
Drei technische Verschiebungen sind für die meisten Anpassungsbedarfe verantwortlich:
- Verändertes Datenmodell: Tabellen wie BSEG oder Materialstamm-Strukturen wurden umgebaut. Direkte Zugriffe auf nicht mehr vorhandene oder umgewidmete Felder laufen ins Leere.
- Business-Partner-Zwang: Kunden- und Lieferantenstammdaten laufen über das BP-Konzept. Code, der noch direkt auf KNA1 oder LFA1 schreibt, verletzt die neue Datenhaltung.
- In-Memory-Paradigma: HANA belohnt spaltenorientierte, mengenbasierte Zugriffe. Zeilenweise Verarbeitung und fehlende
ORDER BYin SELECTs führen zu Performance-Einbrüchen und nicht-deterministischen Ergebnissen.
Besonders heikel sind Modifikationen am SAP-Standard und Implicit Enhancements. S/4HANA zieht hier klarere Grenzen: Solche Eingriffe können bei der Konversion ignoriert oder deaktiviert werden. Wer sie nicht rechtzeitig identifiziert und neu umsetzt, riskiert Regressionen in kritischen Abläufen.
Der reale Umfang: viel weniger Code ist nötig als vorhanden
Ein oft unterschätzter Hebel liegt in der Bereinigung vor der Migration. Erhebungen aus dem SAP-Umfeld zeigen, dass ein erheblicher Teil des kundeneigenen Codes in Altsystemen ungenutzt oder redundant ist. Dieser Anteil lässt sich vor der Umstellung stilllegen, statt ihn mitzuschleppen und anschließend aufwendig anzupassen.
Größenordnungen nach öffentlich verfügbaren Angaben aus dem SAP- und ASUG-Umfeld. Der konkrete Wert ist immer systemspezifisch zu ermitteln.
Werkzeuge: ATC und Custom Code Migration Worklist
Die technische Grundlage jeder Remediation ist der ABAP Test Cockpit (ATC) in den ABAP Development Tools für Eclipse. ATC prüft kundeneigenen Code gegen die S/4HANA-Readiness-Regeln und meldet Verstöße gegen Simplification Items. Ergänzend zeigt die Custom Code Migration Worklist, welche Z-Entwicklungen von wegfallenden Funktionen oder Compatibility-Scope-Bausteinen abhängen.
Wichtig ist eine realistische Erwartung an den Automatisierungsgrad: Die automatischen Quick-Fixes decken einen Teil der typischen Fälle ab, etwa Konflikte mit der MATNR-Feldlänge oder fehlende ORDER BY-Klauseln. Der verbleibende Teil erfordert manuelle Analyse und Umsetzung durch Entwickler, die sowohl die technische Verarbeitung als auch die dahinterliegende Geschäftslogik verstehen.
" Typischer ATC-Befund: nicht-deterministisches SELECT ohne ORDER BY
SELECT matnr, maktx FROM makt
INTO TABLE @DATA(lt_texte)
WHERE spras = @sy-langu.
" Unter HANA ist die Reihenfolge nicht garantiert -> Ergebnis kann variieren
" Remediiert: deterministisch und explizit
SELECT matnr, maktx FROM makt
INTO TABLE @DATA(lt_texte)
WHERE spras = @sy-langu
ORDER BY matnr.Clean Core als Zielbild
Remediation ist die Gelegenheit, das System dauerhaft wartbarer aufzustellen. Das Clean-Core-Prinzip bedeutet: Der SAP-Standard bleibt unmodifiziert, kundeneigene Logik wird über definierte Erweiterungspunkte oder als Side-by-Side-Extension ausgelagert. Statt tief in den Kern eingreifende Modifikationen entstehen entkoppelte, klar abgegrenzte Erweiterungen.
In der Praxis heißt das, jeden relevanten Custom-Code-Baustein einer von vier Kategorien zuzuordnen:
- Stilllegen: ungenutzte oder redundante Objekte werden vor der Migration entfernt.
- Anpassen: weiterhin benötigter Code wird an das S/4HANA-Datenmodell und die ATC-Regeln angepasst.
- Neu bauen: tief modifizierte Logik wird als saubere, entkoppelte Erweiterung neu umgesetzt.
- Ersetzen: Funktionen, die der Standard inzwischen abdeckt, werden durch Standard ersetzt.
Die schwierigste Kategorie ist selten die technische Anpassung, sondern die Entscheidung, welcher Code stillgelegt werden darf. Dafür braucht es jemanden, der die Geschäftslogik hinter dem Z-Objekt liest, nicht nur den ATC-Report.
Empfohlenes Vorgehen
Ein tragfähiger Remediation-Ablauf folgt einer klaren Reihenfolge, die verhindert, dass Aufwand in Code fließt, der ohnehin entfallen kann:
- Nutzungsanalyse: Welcher Custom Code wird produktiv überhaupt aufgerufen?
- ATC-Lauf gegen die S/4HANA-Prüfvarianten, Auswertung nach Kritikalität.
- Abgleich mit der Custom Code Migration Worklist und den relevanten Simplification Items.
- Kategorisierung (stilllegen / anpassen / neu bauen / ersetzen).
- Umsetzung mit Absicherung durch Unit- und ATC-Tests, Regressionstest der betroffenen Prozesse.
Entscheidend ist, dass die Remediation früh beginnt. Wer den ungenutzten Code-Anteil erst nach der Konversion bereinigen will, verliert diesen Hebel weitgehend, weil der Aufwand dann schon investiert ist.
Custom Code vor der S/4HANA-Umstellung bewerten lassen
Von der ATC-Auswertung bis zur konkreten Remediation kundeneigener Entwicklungen. Auch als festes Stundenkontingent für die Analyse.