ABAP Custom-Code-Cleanup
ATC-basiertes Custom-Code-Inventar als Verhandlungs-Grundlage für jede S/4-Brownfield-Migration. Wir prüfen Ihren Z-Code in Pflicht-Checks, Stil-Checks und domänenspezifischen Checks, klassifizieren die Findings nach Tier (1=migration-blocker, 2=lifecycle-debt, 3=cosmetic) und formen daraus ein priorisiertes Refactoring-Backlog. Kein Aufräum-Wille aus dem Bauchgefühl, sondern eine Liste mit Aufwand- und Risiko-Tiefe je Z-Programm.
Warum überhaupt Custom-Code-Cleanup
Eine S/4HANA-Brownfield-Migration kostet selten dort am meisten, wo man es erwartet. SUM DMO läuft technisch durch – das eigentliche Risiko sitzt im Z-Code. Jedes nicht-dokumentierte Z-Programm ist eine Wette: läuft es nach der Konvertierung weiter, oder bricht es bei einem geänderten Standard-FBA, einer obsoleten API, einem neuen Datentyp? Wer das nicht weiss, plant Cutover ohne Boden.
Ein systematisches Custom-Code-Inventar ist deshalb der Schritt vor dem Migration-Schritt. Es schafft das, was die nächsten 12–24 Monate stabilisiert: eine Liste, die jedes Z-Programm kennt, das Risiko quantifiziert und in eine Reihenfolge bringt, die mit Ihrem Timing zusammenpasst.
So gehen wir vor
1. ATC-Inventur (Discover)
Wir richten den ATC (ABAP Test Cockpit) mit drei Check-Stufen ein:
- Pflicht-Checks – alle SAP-Standard-Checks für S/4-Readiness (obsolete APIs, geänderte Datentypen, Sicherheits-Findings, Performance-Probleme bei HANA, Open SQL-Konformität)
- Stil-Checks – Clean-ABAP-Konventionen (Variablen-Namensgebung, Modul-Größen, Inline-Deklarationen), nach Ihrer Code-Norm angepasst
- Domänen-Checks – kundenspezifische Regeln, z.B. Verbot direkter SELECT auf Buchhaltungstabellen, Modul-Konventionen für IDoc- Mappings, abhängigkeits-Verbote zwischen Z-Klassen
Der Scan läuft über die Gesamtsumme aller Eigenentwicklungen, nicht nur über die "wahrscheinlich kritischen" Programme. Vollständigkeit ist die Voraussetzung für Priorisierung.
2. Tier-Klassifikation
Findings werden in drei Tiers eingeordnet:
- Tier 1 – Migration-Blocker: das Programm wird nach SUM DMO abstürzen oder fehlerhafte Ergebnisse liefern. Muss VOR der Konvertierung repariert werden. (Typisch: obsolete BAPIs, geänderte Standard-Strukturen, falsches HANA-SQL.)
- Tier 2 – Lifecycle-Debt: das Programm läuft technisch, aber die Logik trägt Schmerz für die nächsten 3–5 Jahre (z.B. duplizierte Standard-Logik, undurchsichtige Datenflüsse, fehlende Unit-Tests). Refactoring nach Cutover, in geplanten Releases.
- Tier 3 – Kosmetik: Stil-Verstöße, schlechte Namen, fehlende Kommentare. Sind nicht teuer aber summieren sich. In Code-Reviews nachgezogen.
Jedes Finding bekommt eine Aufwand-Schätzung (in Story Points oder Std), eine Risiko-Bewertung und einen Owner aus Ihrem Team.
3. Refactoring-Backlog
Aus der klassifizierten Liste entsteht ein priorisierter Backlog mit klarer Reihenfolge:
- Tier-1-Reparaturen in der Sandbox durchführen, dann Regressionstests
- Tier-1-Reparaturen in Dev/Q ausrollen, in Prod vor SUM DMO konsolidieren
- SUM DMO durchführen mit minimalen SPDD/SPAU
- Nach Go-Live: Tier-2-Refactoring in geplanten Releases
- Tier-3 als laufender Hygienestrom in Code-Reviews
Diese Reihenfolge ist verhandelbar – eine RISE-Migration mit knappem Vertragsfenster wird anders priorisiert als eine Brownfield-Migration mit eigenem Tempo.
4. ATC-Pipeline für den Run
Wir hinterlassen den ATC nicht als Einmal-Werkzeug. Mit abapGit + Pipeline-Integration läuft der Check bei jedem Commit. Neue Z-Programme werden ab Cleanup-Stichtag automatisch geprüft. So bleibt die mühsam gewonnene Code-Hygiene erhalten, ohne dass das Team einen eigenen Code-Review-Tisch braucht.
Wer mit uns arbeitet
Dieses Angebot richtet sich an Entwicklungs-Verantwortliche und ABAP-Leads, die einen verlässlichen Partner für die Custom-Code- Inventur und das Refactoring-Backlog suchen. Eine kompakte ABAP-Code-Review (60 Min) ist meist der schnellste Einstieg – wir schauen gemeinsam in den vorhandenen ATC-Befund (oder richten einen ein) und besprechen die ersten Tier-Treiber.
