Ablösung einer Integrationsplattform

Stand Oktober 2026. 96 von 99 Prozessen sind abgelöst, gebaut oder bewusst gestrichen. Abgeschaltet wird erst nach Freigabe.

Ausgangslage

Der Konzern betreibt eine Integrationsplattform, die Daten zwischen Systemen bewegt und Verarbeitungen zeitgesteuert ausführt. Sie ist über Jahre gewachsen. Ein vollständiger Überblick über das, was darin läuft und wovon es abhängt, lag nicht vor.

Meine Aufgabe ist die Ablösung. Das Zielbild ist dieselbe Orchestrierung, die in der Datenplattform aus Projekt C läuft, auf einer aktuellen Datenbankplattform. Dieser Bericht steht im Präsens, weil das Vorhaben läuft. Ich beschreibe, was vorliegt, und behaupte nichts, was noch nicht vorliegt.

Entscheidung

Erstens: Bestand automatisiert erfassen, nicht durch Befragung. Ich lese die Plattform maschinell aus. So entsteht ein Bestand, der vollständig ist und sich wiederholen lässt, statt einer Liste aus dem Gedächtnis der Beteiligten.

Zweitens: Risikoklassen vor Reihenfolge. Jeder Prozess bekommt eine Risikoklasse aus seinen Abhängigkeiten und seiner Wirkung. Die Reihenfolge der Migration folgt der Risikoklasse, nicht dem Zuruf.

Drittens: Jeder migrierte Prozess läuft gegen das Original. Ein Prozess gilt erst als abgelöst, wenn sein Ergebnis mit dem Ergebnis der alten Plattform übereinstimmt. Ohne diesen Nachweis wird nichts abgeschaltet.

Viertens: nicht jeden Prozess nachbauen. Was niemand mehr braucht, wird gestrichen. Was nur Zwischenstände für andere Prozesse hält, entfällt, wenn der Nachbau ohne ihn auskommt.

Umsetzung

Der Bestand ist erfasst: 99 geplante Prozesse, 1.278 Jobs, rund 8.200 Verarbeitungsschritte. Dazu der Abhängigkeitsgraph, der zeigt, welcher Prozess welchen voraussetzt, und die Risikoklassen je Prozess.

Der erste Prozess war der Test für die Methode. Ich habe sein Ergebnis gegen das Original geprüft: 501.546 Zeilen, identisch, null Abweichungen.

Seitdem habe ich alle 99 Prozesse bearbeitet. Die neue Fachschicht bündelt, was vorher verstreut war. 23 von 25 Zieltabellen sind fertig. 13 Steuer- und Zwischentabellen der alten Plattform entfallen ersatzlos. Tabellen, in die bisher bis zu 8 Prozesse geschrieben haben, haben jetzt einen einzigen Baustein. Auch die Prozesse, die in andere Systeme zurückschreiben, sind nachgebaut. Sie sind bewusst abgeschaltet, bis das Umschalten freigegeben ist. Ein Fehler beim Zurückschreiben landet in Buchungen, nicht in einer Auswertung.

Beim Nachbau sind Lücken aufgefallen, die die alte Plattform nie hatte schließen können. Lieferaufträge ohne Datum fehlten bisher ganz. Und ein alter Prozess bucht seit Mitte August bei jedem Lauf alle Wareneingänge einer Tierart erneut, weil in seiner Auswahlbedingung eine Klammer fehlt. Gefunden habe ich das nicht durch eine Meldung, sondern beim Nachbau. Ich habe den Fall mit Belegen an die IT-Leitung übergeben. Mein Nachbau sendet nur, was im Zielsystem noch fehlt.

Damit Fortschritt und Fehler sichtbar sind, gibt es einen Leitstand in der Plattform aus Projekt A. Er zeigt Jobs, Läufe, Prozessketten und den Datenfluss von der Quelle über den Job bis zum Ziel. Wer berechtigt ist, kann einen Lauf von dort starten oder wiederholen, und jeder Eingriff wird protokolliert. Die Geschäftsführung sieht den Stand der Ablösung im selben System wie die Fachzahlen. Leitstand und ein Servicedesk für die IT kamen in 12 Produktions-Releases an zwei Tagen.

Ergebnis mit Messung

96 von 99 Prozessen sind abgelöst, gebaut oder bewusst gestrichen. Das heißt noch nicht, dass die alte Plattform aus ist. Abgeschaltet ist sie erst, wenn die gebauten Prozesse freigegeben sind und parallel ohne Abweichung gelaufen sind. Das ist der Teil, der jetzt kommt, und er hängt nicht nur an mir.

Was ich anders machen würde

Den Vergleich gegen das Original als festen Baustein bauen, den jeder Prozess automatisch durchläuft, bevor der erste Prozess migriert wird. Beim ersten Prozess habe ich ihn eigens aufgesetzt. Für die übrigen ist er Teil des Weges geworden, aber später als nötig.

Zugänge und Freigaben früher anfragen. 51 Prozesse sind gebaut und warten. Die Technik war schneller fertig als die Organisation dahinter. Das hätte ich am Anfang wissen und parallel anstoßen können.

Die Risikoklassen früher gegen die Fachseite prüfen. Meine Klassen kommen aus Abhängigkeiten und Wirkung im System. Die Fachseite weiß, welcher Prozess morgens um sechs jemandem fehlt. Beides zusammen ergibt die richtige Reihenfolge.

Technik

• Python
• Dagster
• SQL Server 2022