Was überlebt eine Migration von ECC zu S/4HANA?

Der Stichtag 2027 ist nicht der Termin, an dem eine Migration von ECC zu S/4HANA beginnen sollte. Bis dahin müssen die schwierigen Entscheidungen, Neuentwicklungen, Probeläufe und fachlichen Abnahmen abgeschlossen sein. Selten bringt die Standardkonvertierung von SAP ein Programm aus dem Tritt. Meist ist es das private System, das über zwanzig Jahre um SAP herum entstanden ist: Z-Programme, geänderte Includes, User Exits, BAdIs, Hintergrundjobs, Dateiaustausch, Formulare, Berichte und Annahmen, die niemand dokumentiert hat.

Wer diesen Bestand als einen Stapel ABAP behandelt, der nur kompilieren muss, erhält ein technisch grünes System mit fehlerhaftem Geschäftsverhalten. Die Prüfung muss für jedes Objekt vier verschiedene Tatsachen klären: Läuft es noch, erlaubt SAP den Erweiterungspunkt weiterhin, verwendet es noch jemand und bleibt sein Ergebnis korrekt? Dafür braucht es unterschiedliche Belege. Ein einzelner Scan kann nicht alle vier Fragen beantworten.

Das Jahr 2027 verändert die Reihenfolge der Arbeit

SAP hat die Mainstream-Wartung der Kernanwendungen von SAP Business Suite 7 bis Ende 2027 zugesagt. Kunden können optional eine kostenpflichtige Extended Maintenance bis Ende 2030 beziehen. Diese Verlängerung schafft Luft, aber kein Migrationskonzept. Der Einkauf kann Supportabdeckung kaufen. Er kann nicht nachträglich die Jahre beschaffen, die nötig sind, um undokumentierte Abrechnungslogik zu verstehen oder eine Lageranbindung sicher neu zu bauen.

Der erste sinnvolle Meilenstein ist deshalb eine Prüfung, die Belege erzeugt, keine Folie mit einer Zielarchitektur. Am Ende müssen ein Objektinventar, echte Nutzungsdaten, Abhängigkeitsgruppen, bekannte Auswirkungen der Simplification Items, prüfbares Geschäftsverhalten und namentlich benannte Verantwortliche stehen. Wenn die Prüfung nur kundeneigene Objekte je Paket zählt, hat sie das Problem gezählt, aber nicht beschrieben.

Beginnen Sie, solange ECC noch die Wahrheit abbildet. Produktive Last, Jobverlauf, Schnittstellenverkehr und abgestimmte Finanzergebnisse sind viel nützlicher als Erinnerungen, die erst nach einem Freeze gesammelt werden. Sobald Teams Jobs für das Programm abschalten oder Integrationen ändern, ist die Ausgangsbasis verunreinigt. Ich habe erlebt, wie Teams das alte Verhalten zum Monatsabschluss aus Sitzungsnotizen rekonstruieren mussten, weil niemand einen sauberen Lauf aufgezeichnet hatte. Das lässt sich vermeiden.

Der Termin verändert auch die Reihenfolge. Die Analyse des Individualcodes gehört vor die endgültige Festlegung des Konvertierungsumfangs, weil ihre Ergebnisse das Ziel verändern können. Eine stark modifizierte ECC-Transaktion kann als S/4HANA-Erweiterung, als eigener Service, durch Standardfunktionen oder durch Stilllegung enden. Diese Wege lassen sich erst seriös schätzen, wenn klar ist, welchen Code und welche Daten jede Transaktion berührt.

Der kundeneigene Bestand ist größer als der Z-Namensraum

Eine Liste der Z-Objekte ist ein nützlicher Anfang und eine gefährliche Definition des Umfangs. Kundenspezifisches Verhalten kann in Namensräumen, Änderungen an SAP-Objekten, Enhancement-Implementierungen, generiertem Code, Varianten, Workflow-Regeln, BRFplus-Inhalten, Formularen, Jobketten, berechtigungsabhängigen Verzweigungen und externen Programmen stecken, die RFCs aufrufen oder Dateien lesen. Mancher besonders folgenreiche Code enthält keine Z-Transaktion, die ein Fachverantwortlicher erkennen würde.

Bauen Sie das Inventar aus mehreren Quellen auf und bewahren Sie die Verbindungsschlüssel. Repository-Metadaten zeigen, was existiert. ATC und die S/4HANA-Prüfungen zeigen, welche statischen Muster mit dem Zielrelease kollidieren. SCMON und SUSG zeigen ausgeführte Prozeduren über einen repräsentativen Beobachtungszeitraum. ST03N-Lastdaten helfen, Transaktionen und Benutzer zuzuordnen. Der Jobverlauf in SM37 legt Batch-Pfade offen. Wo Änderungen vorliegen, zeigen SPAU und SPDD die Stellen, an denen der Kunde von SAP abgewichen ist. Schnittstellenkataloge, RFC-Destinationen, IDoc-Konfiguration und Zeitpläne für Dateiübertragungen decken Pfade außerhalb der Dialognutzung ab.

Verdichten Sie das nicht zu früh zu einem Risikowert. Halten Sie je Objekt mindestens Repository-Identität, Paket, Komponente, letzte Änderung, Aufrufer- und Aufrufbeziehungen, beobachtete Ausführung, Geschäftsprozess, berührte Daten, Simplification-Befund, Erweiterungsmechanismus, Testbeleg und verantwortlichen Eigentümer fest. Ein Objekt ohne beobachtete Nutzung kann ein Jahresabschlussbericht sein. Ein oft aufgerufenes Hilfsprogramm kann risikoarm sein, weil es nur Datumswerte formatiert. Häufigkeit und Auswirkung sind getrennte Achsen.

Schwierig ist indirekt erreichter Code. Ein User Exit, den die Standardverarbeitung aufruft, taucht in Laststatistiken womöglich nie als benannte Transaktion auf. Ein Funktionsbaustein läuft vielleicht nur über einen externen RFC. Eine Formroutine kann per Customizing ausgewählt werden. Die Abhängigkeitsanalyse muss an fachlichen Einstiegspunkten beginnen und Aufrufe, Tabellen, Nachrichten, Jobs und Schnittstellen verfolgen. Das Zählen einzelner Objekte verdeckt Gruppen, die gemeinsam umziehen müssen.

Ich nehme auch betriebliche Artefakte in den Umfang auf. Jobvarianten, Druckerziele, logische Dateipfade, Ereignisauslöser, Zertifikate und technische Benutzer sind kein ABAP, doch das nachgebildete Verhalten hängt oft von ihnen ab. Ein Migrationsteam, das den Code für fertig erklärt, während Basis diese Abhängigkeiten beim Cutover rekonstruiert, hat die Codeprüfung nicht abgeschlossen.

Kompilierung beweist weniger als viele hoffen

Eine fehlerfreie Syntaxprüfung belegt, dass der Compiler das Programm in der neuen Umgebung akzeptiert. Sie beweist nicht, dass es dieselben Datensätze liest, dieselbe Reihenfolge verwendet, dieselben Belege bucht, dieselben Sperren respektiert oder innerhalb seines Batch-Fensters fertig wird. Kompatibilität ist eine notwendige Schranke und ein schwacher fachlicher Test.

S/4HANA ändert Datenmodelle und stellt an manchen Stellen Kompatibilitätsviews bereit, um den Übergang zu erleichtern. Dadurch können alte Lesezugriffe weiterlaufen, während ein Architekturproblem verborgen bleibt. Code kann aus einem Kompatibilitätsview plausible Daten lesen und trotzdem die freigegebene API oder das semantische Modell umgehen, das der neue Entwurf vorsieht. Richtig kann sein, den Zugriff zu ersetzen, den Sonderweg stillzulegen oder ihn vorübergehend mit einem klaren Ablaufdatum zu behalten. Ein grüner ATC-Befund kann diese Entwurfsentscheidung nicht treffen.

Auch implizites Datenbankverhalten erzeugt falsche Sicherheit. Betrachten Sie eine alte Routine wie diese:

SELECT * FROM vbap
  INTO TABLE @DATA(items)
  WHERE vbeln = @order_number.

READ TABLE items INDEX 1 INTO DATA(first_item).

Ohne ORDER BY garantiert die Datenbank nicht, welche Zeile zuerst erscheint. Wenn der nachfolgende Code Index eins als früheste Position behandelt, kann eine Änderung der Datenbank oder des Ausführungsplans das Ergebnis ohne Syntaxfehler verändern. Die Reparatur besteht nicht darin, willkürlich zu sortieren, bis ein Test grün wird. Das Team muss die beabsichtigte Geschäftsregel wiederfinden, ausdrücklich abbilden und Grenzfälle wie abgelehnte, neu nummerierte oder gelöschte Positionen prüfen.

Native SQL, Datenbankhinweise, Annahmen über Pool- oder Clustertabellen, direkte Änderungen an SAP-eigenen Tabellen und breite SELECT *-Muster verdienen Aufmerksamkeit, bilden aber nicht die ganze Prüfung. Dynamische Aufrufe, Routinen mit vielen Feldsymbolen und generierte Anweisungen können einfache statische Verfolgung aushebeln. Verbinden Sie automatisierte Befunde mit gezielter Codelektüre an Einstiegspunkten mit hoher Auswirkung. Die statische Analyse liefert eine Karte. Sie erklärt nicht, warum der Weg gebaut wurde.

User Exits und BAdIs sind Verträge, keine Behälter

Eine Enhancement-Implementierung lässt sich nicht allein nach ihrem Inhalt beurteilen. Ihr tatsächlicher Vertrag umfasst den Aufrufzeitpunkt durch SAP, den dann vollständigen Datenstand, Aktualisierungen im Dialog oder Update Task, die vom Aufrufer behandelten Ausnahmen und spätere Standardlogik, die Änderungen wieder überschreiben kann. Ein Ersatz-BAdI mit ähnlichem Namen kann einen anderen Vertrag haben.

Klassische User Exits und Customer Exits tragen oft knappen Code mit großer fachlicher Wirkung. Wenige Zeilen können eine Profitcenter-Ableitung vornehmen, einen Auftrag ablehnen, die Preisfindung ändern oder eine Genehmigung lenken. Erfassen Sie bei der Prüfung für jede Implementierung Auslöser, Eingabestatus, Nebenwirkungen, Fehlerverhalten und nachgelagerte Abnehmer. Ordnen Sie sie dann dem empfohlenen Erweiterungspunkt für das konkrete S/4HANA-Release und Betriebsmodell zu. Gehen Sie nicht davon aus, dass eine On-Premise-Erweiterungsoption in jedem Ziel gleich existiert.

Der beliebte Rat, jeden Exit sofort durch ein BAdI zu ersetzen, ist zu grob. Er klingt modern und gibt dem Programm eine einfache Kennzahl, doch die Hülle bestimmt nicht die Qualität des Entwurfs. Manche Logik gehört in eine freigegebene In-App-Erweiterung, manche in einen Side-by-Side-Service, manche in die Standardkonfiguration und manche sollte verschwinden. Wer undurchsichtige Logik in einen neueren Hook verschiebt, erhält ihre Undurchsichtigkeit.

Änderungen an SAP-Objekten verlangen eine noch härtere Entscheidung. Fragen Sie, warum die Änderung existierte, ob SAP die Funktion später bereitgestellt hat und ob der Fachbereich noch von der Abweichung abhängt. SPAU-Arbeit darf kein Ritual werden, bei dem jede historische Änderung erneut eingespielt wird. Jede übernommene Änderung erhöht die Last künftiger Upgrades. Deshalb sollte ihr Eigentümer sie mit aktuellen Belegen und einem Test verteidigen, der ohne sie fehlschlägt.

Halten Sie die Entscheidung als Vertrag fest: Bei diesem Geschäftsereignis und Zustand muss die Erweiterung diese Änderungen oder diesen Fehler erzeugen und darf diese geschützten Felder nicht verändern. Diese Aussage bleibt nützlich, ob das Ziel ABAP, Konfiguration, Go oder ein Workflow außerhalb des Kerns ist.

Nutzungsdaten brauchen einen Geschäftskalender

Laufzeitbelege sind unverzichtbar, doch ein Beobachtungsfenster ist nicht allein wegen seiner Länge repräsentativ. In SAP-Beständen gibt es Quartalsabschluss, Jahresendsteuer, jährliche Inventur, saisonale Preisfindung, Prüfungsauszüge und Jobs nur für Ausnahmefälle. Eine Entscheidung über ungenutzten Code braucht einen Geschäftskalender und einen Eigentümer, nicht nur einen Zeitstempel der letzten Ausführung.

Sammeln Sie mit SCMON Nutzung auf Prozedurebene und verdichten Sie die Ergebnisse mit SUSG für die Individualcodeanalyse. Verbinden Sie diese Belege mit Lastverlauf, Batch-Zeitplänen und Schnittstellenüberwachung. Der Beobachtungszeitraum muss die wichtigen Ereignisse des Unternehmens bewusst einschließen. Kann er ein jährliches Ereignis nicht enthalten, prüfen Sie die Belege des letzten Laufs und sprechen Sie mit der Person, die sein Ergebnis abstimmt.

Ordnen Sie Kandidaten als behalten, ändern, stilllegen oder ungeklärt ein. Löschen Sie ungeklärten Code nicht, um ein Dashboard zu verbessern. Für die Stilllegung braucht es drei Belege: keine relevante Ausführung, keinen konfigurierten oder indirekten Einstiegspfad und einen Fachverantwortlichen, der der Entfernung zustimmt. Archivieren Sie Entscheidung und Abhängigkeitsbelege, damit ein später Einwand ohne neue Discovery geklärt werden kann.

Nutzung hilft auch bei der Testauswahl. Häufig laufender Code liefert viel Produktionsverkehr, doch seltene Pfade mit hohen Auswirkungen brauchen sorgfältig erstellte Testdaten. Eine selten genutzte Kreditfreigabe oder Steuerkorrektur kann tiefere Tests verdienen als ein Bericht, der jeden Morgen geöffnet wird. Gewichten Sie nach Schaden eines falschen Ergebnisses, Schwierigkeit der Erkennung und Wiederherstellbarkeit.

Eine weitere Falle ist doppelte Logik. Zwei Z-Programme können denselben Begriff für Dialog und Batch unterschiedlich berechnen. Die Laufzeitanalyse sieht zwei aktive Objekte. Die fachliche Analyse sollte eine strittige Regel erkennen. Legen Sie solche Widersprüche vor der Migration offen. Beide Varianten originalgetreu neu zu bauen würde einen Fehler im Unternehmenswissen erhalten.

Simplification-Befunde brauchen Entscheidungen

SAP Readiness Check, der Simplification Item Catalog und ATC-Prüfungen liefern unverzichtbare Belege, doch jeder Befund muss im lokalen Entwurf ausgelegt werden. Ein Simplification Item zeigt eine relevante technische oder funktionale Änderung. Es weiß nicht, ob Ihr individuelles Programm überflüssig ist, ob ein Kompatibilitätsweg vorübergehend genügt oder welches Geschäftsergebnis bestehen bleiben muss.

Erfassen Sie je Befund das betroffene Objekt, den Prozess, die vorgesehene Behandlung, den Zielmechanismus, den beweisenden Test und die abnehmende Person. Vermeiden Sie Abschlussnotizen wie "angepasst" oder "nicht relevant" ohne Beleg. Ein halbes Jahr später weiß niemand, ob "nicht relevant" unerreichbaren Code, einen Fehlalarm, einen stillgelegten Prozess oder eine ungeprüfte Annahme meinte.

Eine brauchbare Prüfsequenz sieht so aus:

1. Führen Sie ATC-Prüfungen für das Zielrelease über den gesamten kundeneigenen Umfang aus, einschließlich Änderungen und Namensräumen.
2. Verbinden Sie Befunde mit beobachteter Nutzung und Abhängigkeitsgruppen, statt Objekte alphabetisch zu prüfen.
3. Verfolgen Sie jede Gruppe mit hoher Auswirkung bis zu einem fachlichen Einstiegspunkt und einem verantwortlichen Eigentümer.
4. Wählen Sie Stilllegung, vorübergehende Beibehaltung, Anpassung oder Neuentwurf und dokumentieren Sie den Grund.
5. Hängen Sie ausführbare Belege an: Regressionstest, abgestimmtes Ergebnis, aufgezeichneter Schnittstellenaustausch oder genehmigte Ausnahme.

Diese Reihenfolge verhindert einen häufigen Fehler: Entwickler schließen Tausende lokale Befunde, während das Programm einen systemübergreifenden Prozess übersieht. Befundzahlen messen die Größe einer Arbeitsliste, nicht die Bereitschaft. Eine Gruppe mit zwölf Befunden und bekanntem Paritätstest kann sicherer sein als eine dynamisch aufgebaute Buchungsroutine, die kein Werkzeug auflöst.

Halten Sie Ausnahmen eng und befristet. Bleibt ein Befund, weil während des Übergangs ein Kompatibilitätsview erlaubt ist, benennen Sie Release-Annahme und Bedingung für die Entfernung. Dauerhafte Ausnahmen ohne Entwurfsnachweis werden zur Archäologie des nächsten Migrationsteams.

Schnittstellen scheitern an den Grenzen der Verantwortung

Eine Schnittstellenprüfung muss Protokoll, Bedeutung der Nutzdaten und Betriebsvereinbarung erfassen. Teams inventarisieren oft RFCs, IDocs, APIs und Dateien und halten eine Schnittstelle für verstanden, sobald ihr Endpunkt bekannt ist. Fehler stecken in Feldbedeutungen, Reihenfolge, Duplikatbehandlung, Bestätigungen und dem manuellen Reparaturweg bei Ausfall einer Seite.

Beginnen Sie mit beobachtetem Austausch und Konfiguration, nicht mit dem Namen im Katalog. Erfassen Sie Initiator, Zeitplan oder Auslöser, Authentifizierung, Nutzdatenversion, typischen Mengenverlauf, Timeout, Wiederholungsregel, Idempotenz, Reihenfolgeannahme und Abstimmungsverantwortlichen. Bei Dateien gehören Namensregeln, Zeichencodierung, Trennzeichen, Kontrollsummen, Ablageverzeichnisse und Archivierung dazu. Bei IDocs bewahren Sie Nachrichtentyp, Basistyp, Erweiterungen, Partnervereinbarungen, Statusbehandlung und Jobs zur Fehlernachbearbeitung. Bei RFCs suchen Sie externe Aufrufer ebenso wie in SAP konfigurierte Destinationen.

Individuelles ABAP legt einen Datenvertrag oft unbeabsichtigt offen. Ein Abnehmer kann von einem undokumentierten Feld, einem bestimmten Nachrichtentext, leer statt null oder der Zeilenreihenfolge in einem Auszug abhängen. S/4HANA kann eine sauberere freigegebene API anbieten, doch ein neuer Endpunkt beseitigt diese Annahmen beim Abnehmer nicht. Vergleichen Sie alten und neuen Vertrag Feld für Feld. Entscheiden Sie dann, ob der Abnehmer angepasst, eine Kompatibilitätsschicht an die Grenze gesetzt oder der Austausch versioniert wird.

Die Abstimmung braucht einen eigenen Test. Eine erfolgreiche HTTP-Antwort oder ein grüner IDoc-Status beweist die technische Zustellung bis zu einer Stufe. Beides beweist nicht, dass beide Systeme dasselbe Geschäftsereignis genau einmal angenommen haben. Definieren Sie den Geschäftsschlüssel zum Abgleich, die von Bedienern verglichenen Summen oder Zustände, die zulässige Verzögerung und das Verfahren zur Wiederholung ohne doppelte Buchung. Erfassen Sie aktuelle Ausnahmen, denn im Reparaturablauf können Geschäftsregeln stecken, die im Programm fehlen.

Ich lasse Teams einen Fehler vollständig durchspielen. Angenommen, ECC schreibt nachts eine Preisdatei, überträgt sie an ein Lagersystem und archiviert die Quelle. Die Übertragung läuft in einen Timeout, nachdem der Empfänger die Datei gespeichert, aber bevor ECC den Erfolg vermerkt hat. Der zweite Versuch sendet eine weitere Kopie. Erkennt der Empfänger Dateien nur am Eingangsnamen, importiert er beide und verändert die Bestandsbewertung zweimal. Die Migration muss Duplikaterkennung erhalten oder verbessern, nicht nur den erfolgreichen Lauf kopieren. Ein Paritätstest sollte Timeout, Wiederholung und Abstimmung auslösen.

Schnittstellen bestimmen auch die Reihenfolge beim Cutover. Kann ein externes System den neuen Vertrag nicht am selben Tag annehmen, definieren Sie einen begrenzten Parallelweg und einen Verantwortlichen für dessen Entfernung. Vermeiden Sie bidirektionale Kompatibilitätsschichten mit unklarem Dateneigentum. Im Plan wirken sie flexibel und werden dauerhaft, wenn niemand mehr beweisen kann, welche Seite den maßgeblichen Datensatz hält.

Behandeln Sie jeden undokumentierten Abnehmer als offenes Risiko. Durchsuchen Sie verfügbare Netzwerk- und Gateway-Protokolle, technische Benutzeraktivität und Dateiabrufe. Fragen Sie Bediener, welche Auszüge sie von Hand verschieben. Machen Sie den Vertrag ausdrücklich, bevor Sie den Erzeuger ändern. Der schlechteste Zeitpunkt, um eine kleine Desktop-Datenbank als Abnehmer eines Z-Berichts zu entdecken, ist nach dem ersten Abschluss im neuen System.

Parität muss vor dem Neubau aufgezeichnet werden

Erwartetes Verhalten lässt sich am besten erfassen, solange ECC reale Arbeit verarbeitet und Finanz-, Lieferketten- und Betriebsteams die Ergebnisse noch abstimmen. Ein Neubau, der nur gegen handgefertigte Beispiele getestet wird, verfehlt die ungewöhnlichen Kombinationen aus Jahren echter Nutzung.

Bauen Sie eine Paritätsprüfung um fachliche Grenzen. Vergleichen Sie bei Berichten sortierte Ergebnismengen und Summen, mit dokumentierten Toleranzen für Felder, deren Darstellung sich berechtigt ändert. Zeichnen Sie bei Schnittstellen Anfragen, Antworten, IDocs, Dateien und Nebenwirkungen auf und spielen Sie bereinigte Fälle gegen das Ziel. Vergleichen Sie bei Buchungen Belegarten, Kontierungen, Beträge, Währungen, Steuerbehandlung, Statuswechsel und Fehlermeldungen, auf die externe Bediener angewiesen sind. Maskieren Sie vertrauliche Daten, ohne die Kombinationen zu zerstören, die Logik auslösen.

Ein brauchbarer Testdatensatz kann einfach sein:

{
  "case_id": "sales-order-credit-hold",
  "entry_point": "order_create",
  "input_ref": "fixture/credit-hold-017.json",
  "expected": {
    "status": "HELD",
    "posted_documents": 0,
    "message_id": "ZCREDIT-014"
  }
}

Die Bezeichner sind Beispiele, doch die Form zwingt das Team zu sagen, was als gleich gilt. Ergänzen Sie bei Bedarf Vorbedingungen und geschützte Nebenwirkungen. Speichern Sie sowohl das rohe Ergebnis als auch den normalisierten Vergleich, damit Prüfer erkennen, was die Prüfung ignoriert. Entfernt die Normalisierung Zeitstempel, Reihenfolge oder erzeugte Kennungen, dokumentieren Sie, warum diese Unterschiede fachlich bedeutungslos sind.

Aufgezeichneter Produktionsverkehr braucht Auswahl. Jeder Aufruf muss selten wiederholt werden, und rohe Menge kann leichte Erfolgsfälle überbetonen. Wählen Sie Äquivalenzklassen, Grenzbeträge, seltene Statuskombinationen, Fehlerpfade und jede bekannte regulatorische oder vertragliche Verzweigung. Ergänzen Sie dann Fälle für Regeln aus der Codelektüre, auch wenn sie im Aufzeichnungsfenster nicht vorkamen.

Parität verlangt keine schlechte Architektur. Sie fixiert das nach außen bedeutsame Verhalten und erlaubt im Ziel klarere Grenzen und Dateneigentum. CodeHero verwendet diesen Ansatz beim Neubau von ABAP: Die Plattform liest den gesamten Baum, und eine Paritätsprüfung vergleicht das neue System mit aufgezeichnetem Produktionsverkehr, während sich die Architektur ändert. Die Prüfung trägt die Abnahmeentscheidung, nicht die Ähnlichkeit zwischen altem und neuem Quellcode.

Manches ABAP gehört nicht nach S/4HANA

Eine Migration bietet die Chance, den kundeneigenen Kern zu verkleinern. "Clean Core" ist aber kein Befehl, jedes fragwürdige Programm auf eine andere Plattform zu verschieben. Der Ort folgt Verhalten, Transaktionsgrenze, Dateneigentum, Latenz und Betriebsmodell. Eine eng gekoppelte Prüfung in einen entfernten Service zu verschieben kann neue Fehlerarten schaffen, ohne eine nützliche Grenze zu erzeugen.

Halten Sie Logik nahe am Kern, wenn sie synchron an einer SAP-Transaktion teilnehmen muss und das Ziel einen freigegebenen Erweiterungsmechanismus mit dem nötigen Vertrag anbietet. Verlagern Sie Logik, wenn sie eine eigenständige Fähigkeit besitzt, über freigegebene APIs oder Ereignisse arbeiten kann und von einem eigenen Lebenszyklus profitiert. Ersetzen Sie Individualcode durch S/4HANA-Standardverhalten, wenn der Fachbereich die Standardregel annimmt. Legen Sie Code still, wenn die Belege zeigen, dass der Prozess nicht mehr existiert.

Die Zielsprache ist eine nachrangige Entscheidung. Go kann zu Services mit klaren Schnittstellen und betrieblicher Verantwortung passen. Rust kann zu numerischen Kernen passen, bei denen Korrektheit und Kontrolle zählen. TypeScript kann für Benutzeroberflächen und Workflow-Flächen passen. Keine Sprache repariert einen fehlenden Geschäftsvertrag. Wenn ein Team nicht sagen kann, was eine ABAP-Routine tun muss, macht ihre Übersetzung in eine modische Sprache die Unklarheit nur teurer.

Hüten Sie sich vor ausgelagertem Code, der SAP-Tabellen weiter als private Datenbank behandelt. Ein Z-Programm auszulagern und den direkten Tabellenzugriff zu behalten erzeugt einen verteilten Monolithen plus Netzwerkfehler. Definieren Sie API- oder Ereignisvertrag, Dateneigentum, Wiederholung und Idempotenz und testen Sie Teilausfälle. Ein sauberes Diagramm ohne Abstimmung ist kein fertiger Entwurf.

Es gibt auch eine personelle Grenze. ABAP-Fachleute kennen oft die Ausnahmen, die Architekturteams als technische Altlast abtun. Bringen Sie sie mit Prozessverantwortlichen und Zielentwicklern zusammen. Nicht jede alte Implementierung muss bleiben, aber ihr Wissen darf nicht verschwinden, bevor die Geschäftsregel ein neues Zuhause hat.

Das Ergebnis muss eine Go- oder No-Go-Entscheidung tragen

Eine glaubwürdige Prüfung zeigt Führungskräften, was stillgelegt, angepasst oder neu entworfen werden kann, was ungeklärt bleibt und welche Belege jede Aussage stützen. Ein Entwickler muss zugleich ein Hauptrisiko bis zu Objekten, Abhängigkeiten, Verkehr und Tests verfolgen können. Braucht eine Seite eine zusätzliche mündliche Überlieferung, ist das Ergebnis unvollständig.

Ordnen Sie die Arbeit nach Geschäftsfähigkeit und Abhängigkeitsgruppe, nicht nach Tausenden Repository-Objekten. Zeigen Sie je Gruppe Umfang, aktuelle Einstiegspunkte, Nutzungsbelege, Simplification-Auswirkungen, Daten- und Schnittstellenabhängigkeiten, Zielbehandlung, Paritätsabdeckung, Eigentümer und offene Entscheidungen. Schätzen und planen Sie auf Gruppenebene, weil Objekte eines Buchungs- oder Fulfilment-Pfads selten unabhängig migrieren.

Legen Sie klare Abschlusskriterien fest. Jedes kundeneigene Objekt im Umfang muss zu einer Gruppe oder einer begründeten Stilllegungsmenge gehören. Jede Gruppe mit hoher Auswirkung braucht Zielbehandlung und Eigentümer. Jedes beibehaltene Verhalten braucht eine identifizierte Testquelle. Jeder offene Punkt braucht Entscheidungsdatum und erforderlichen Beleg. Diese Kriterien zeigen Unsicherheit, statt sie in einem Prozentwert zu verstecken.

Erklären Sie die Discovery nicht für abgeschlossen, solange Produktionsbelege fehlen. Zeichnen Sie repräsentativen Verkehr, abgestimmte Ergebnisse und Ausnahmeläufe jetzt auf, solange ECC verfügbar und vertrauenswürdig ist. Statische Prüfungen lassen sich später wiederholen. Eine übersehene Jahresendverzweigung oder ein undokumentierter externer Aufrufer lässt sich nicht auf Wunsch zurückholen.

Der Stichtag 2027 ist real, weil Wartungsoptionen enger und teurer werden. Panik taugt trotzdem nicht zur Planung. Die unmittelbare Aufgabe ist genau: Laufzeiterfassung freigeben, Inventarformat festlegen, die erste Geschäftsgruppe mit hoher Auswirkung wählen und ihr Verhalten aufzeichnen. Mit diesen Belegen werden Diskussionen über Zielarchitektur, Kosten und Termine zu technischen Entscheidungen statt Vermutungen.

Planen Sie die Prüfung für Unsicherheit, nicht nur für bekannte Anpassungen. Reservieren Sie Entscheidungskapazität für Objekte ohne Eigentümer, dynamische Aufrufe, nicht reproduzierbare Berichte und Schnittstellen mit unbekannten Abnehmern. Das sind keine administrativen Reste. Dort ändert sich der Umfang spät, sobald endlich jemand die Funktion des Codes entdeckt.

Halten Sie die Belege unter Versionskontrolle und aktualisieren Sie sie bei Änderungen an ECC. Ein neuer Notfalltransport, eine geänderte Jobvariante oder eine Schnittstellenänderung nach der ersten Erfassung kann Abhängigkeitskarte und Tests entwerten. Führen Sie eine kleine Eingangsregel ein: Jede Produktivänderung im Migrationsfenster muss nennen, welche Gruppe, Entscheidung und Paritätstests sie betrifft. So driftet die Ausgangsbasis nicht unbemerkt vom tatsächlich zu konvertierenden System weg.

Proben Sie schließlich den Entscheidungsweg ebenso wie die Software. Geben Sie Verantwortlichen eine wirklich mehrdeutige Gruppe und verlangen Sie Zielwahl, Freigabe stillgelegten Verhaltens und Annahme der Paritätsbelege. Fehlt diese Entscheidungsbefugnis während der Prüfung, wartet dasselbe Problem im Cutover-Termin mit weniger Zeit und schlechteren Möglichkeiten.