Warum die Migration jetzt auf die Roadmap gehört
SAP Process Integration und Process Orchestration laufen auf ein definiertes Wartungsende zu. Wer Schnittstellen heute noch auf der klassischen Middleware betreibt, verliert mittelfristig Support, Sicherheitsupdates und den Zugang zu neuen SAP-Adaptern. Gleichzeitig verschiebt sich die Integrationslogik in der SAP-Welt konsequent in die Cloud Integration der SAP Integration Suite.
Aus unseren Projekten wissen wir: Der kritische Pfad ist selten die Technik, sondern die Zeit. Eine mittlere Systemlandschaft mit 150 bis 400 aktiven Schnittstellen benötigt realistisch zwölf bis 24 Monate, wenn Fachbereiche, externe Partner und EDI-Strecken eingebunden werden müssen. Wer erst zwei Quartale vor dem Wartungsende startet, migriert unter Druck — und zahlt das mit Betriebsrisiko.
Schritt 1: Bestandsaufnahme statt Bauchgefühl
Der Fahrplan beginnt mit einer belastbaren Inventur. Wir ziehen dafür alle Integrated Configurations, ICOs, Mappings und Adapter aus dem bestehenden PI/PO-System und ergänzen sie um Laufzeitdaten aus dem Message Monitoring: Wie viele Nachrichten laufen pro Tag über die Schnittstelle, wer ist fachlicher Owner, welche Partner hängen daran?
Erfahrungsgemäß sind 20 bis 40 Prozent der dokumentierten Schnittstellen faktisch tot — Testobjekte, abgelöste Partner, doppelte Strecken. Diese Objekte werden nicht migriert, sondern stillgelegt. Das ist der günstigste Teil jedes Migrationsprojekts und reduziert den Aufwand messbar, bevor die erste Zeile Konfiguration entsteht.
Schritt 2: Zielarchitektur und Migrationsmuster festlegen
Nicht jede Schnittstelle wird eins zu eins übersetzt. Wir arbeiten mit vier Mustern: unveränderte Neuimplementierung in der Cloud Integration, Ablösung durch Standard-APIs von SAP S/4HANA, Konsolidierung mehrerer Altstrecken auf einen Flow sowie Stilllegung. Für jede Schnittstelle wird das Muster in der Inventur dokumentiert und mit dem fachlichen Owner bestätigt.
Parallel entsteht die Zielarchitektur: Wo liegt die Cloud Connector-Verbindung, wie werden Zertifikate und Credentials im Security Material verwaltet, welche Namenskonventionen gelten für Packages und iFlows, wie sieht das Fehler-Handling mit Retry und Alerting aus? Diese Leitplanken vor dem ersten iFlow zu setzen, verhindert die typische Wildwuchs-Landschaft, die zwei Jahre später niemand mehr betreiben will.
Schritt 3: Migrieren in Wellen, testen mit echten Nachrichten
Wir schneiden die Migration in Wellen von je 15 bis 30 Schnittstellen, gruppiert nach Fachbereich oder Partner — nicht nach technischer Ähnlichkeit. So bleibt der Test in einer Hand und die Abnahme organisatorisch sauber. Jede Welle durchläuft denselben Zyklus: Aufbau, Unit-Test, Integrationstest mit produktionsnahen Nachrichten, Parallelbetrieb, Umschaltung.
Der wirksamste Qualitätsbaustein ist der Test mit echten Payloads aus dem Altsystem. Wir extrahieren archivierte Nachrichten, spielen sie gegen den neuen iFlow und vergleichen die Ergebnisse feldgenau. Mapping-Abweichungen, die im Fachtest wochenlang unentdeckt bleiben, fallen so am ersten Tag auf.
Für EDI- und Partnerstrecken planen wir bewusst einen Parallelbetrieb ein: Beide Systeme verarbeiten dieselben Nachrichten, aber nur eines liefert produktiv aus. Das kostet Laufzeit, verhindert aber den Worst Case einer gestörten Lieferkette.
Schritt 4: Betrieb ab Tag eins mitdenken
Eine migrierte Schnittstelle ist erst dann fertig, wenn klar ist, wer nachts alarmiert wird. Wir verankern deshalb schon während der Migration das Monitoring: Alerting auf fehlgeschlagene Nachrichten, definierte Eskalationswege, dokumentierte Wiederanlaufverfahren und Kennzahlen zur Nachrichtenlaufzeit.
Für Kunden ohne eigenes Integrationsteam übernehmen wir diesen Betrieb im Rahmen unserer Application-Management-Services — mit denselben Spezialisten, die die Migration umgesetzt haben. Das verkürzt die Fehleranalyse erheblich, weil Architektur-Wissen und Betriebsverantwortung nicht auseinanderfallen.
Der pragmatische Einstieg
Wenn Sie noch keinen Fahrplan haben, ist die Schnittstellen-Inventur der richtige erste Schritt: Sie ist in wenigen Wochen erstellt, kostet vergleichsweise wenig und liefert die Zahlen für Budget, Zeitplan und Business Case. Erst danach lässt sich seriös entscheiden, ob intern, gemischt oder über ein Nearshore-Team migriert wird.
Unsere Spezialisten begleiten SAP-Integrationsprojekte von der Inventur über die Zielarchitektur bis zum laufenden Betrieb. Sprechen Sie uns an, wenn Sie Ihren Migrationsfahrplan gegen die Praxis prüfen wollen.