Ob eine Legacy-Migration in 90 Tagen tragfähig ist, sieht man oft schon in Woche 1. Wenn nach wenigen Workshops noch immer unklar ist, welches System einen fachlichen Zustand schreiben darf, welche Ausnahmen täglich manuell korrigiert werden und woran Alt gegen Neu verglichen wird, ist der Scope falsch geschnitten. In solchen Lagen scheitert nicht das Tempo. Es scheitert die Auswahl des ersten produktiven Pfads. Genau deshalb sind viele 90-Tage-Zusagen am Markt zu billig verkauft.
Der Engpass ist fast immer Begrenzung. Ein produktiver Pfad mit klaren Ein- und Ausgängen lässt sich in 90 Tagen migrieren. Ein historisch gewachsener Kern fast nie. Genau hier werden viele Angebote wertlos: Sie verkaufen einen Termin, bevor klar ist, welches System welchen fachlichen Zustand schreiben darf und wie Alt gegen Neu verglichen wird.
Für die Vorentscheidung reichen meist drei Migrationsmuster. Das Strangler-Pattern passt, wenn sich Funktionalität schrittweise vor das Altsystem ziehen lässt. Parallelbetrieb ist nötig, wenn fachliche Korrektheit über reale Daten nachgewiesen werden muss. Eine Fassade hilft, wenn das Legacy-System intern chaotisch ist, nach außen aber stabile Schnittstellen hat. Wenn diese Wahl nach zehn Arbeitstagen noch offen ist, wird der 90-Tage-Rahmen bereits fragwürdig.
Falls intern noch die Grundsatzfrage offen ist, ob eher Umbau oder Ersatz sinnvoll ist, sollte zuerst Refaktorisierung oder Neuschreiben entschieden werden. Sonst diskutiert das Team über Tools und Liefertermine, obwohl die Architekturfrage noch nicht beantwortet ist.
Wann ein 90-Tage-Vorhaben realistisch ist
Ein belastbarer Scope hat einen klaren fachlichen Start- und Endpunkt, wenige direkt betroffene Umsysteme und benannte Verantwortliche. Ein Pfad wie Auftragseingang bis Bestätigung kann passen. Die komplette Auftragsabwicklung inklusive Abrechnung, Reporting und Archivierung passt meist nicht. Der Unterschied ist operativ, nicht theoretisch: Je mehr Folgeprozesse an einem Zustand hängen, desto teurer wird jede ungeklärte Ausnahme.
Go oder No-Go entscheidet sich früh. Können Sie innerhalb von zehn Arbeitstagen Quellsysteme, schreibende Systeme, lesende Systeme, fachliche Eigentümer, Vergleichsmetriken und den Rückfallpfad benennen? Wenn nicht, sollte niemand einen 90-Tage-Plan als belastbar verkaufen. Dann fehlt nicht nur Detailwissen. Dann fehlt die Grundlage für eine sichere Umstellung.
Es gibt auch harte Ausschlusskriterien. Der Zeitraum ist nicht seriös, wenn mehrere Systeme denselben fachlichen Zustand schreiben, kritische Regeln nur in Batch-Jobs oder Excel-Makros stecken, regulatorische Nachweise im Ziel noch nicht abbildbar sind oder Alt und Neu nach dem Umschalten nicht konsistent gehalten werden können. In solchen Lagen hilft kein enger Sprintplan. Zuerst braucht es Entflechtung.
Ein Muster aus realen Vorhaben taucht ständig auf: Nicht die sichtbare Oberfläche macht Probleme, sondern stille Abhängigkeiten. Der nächtliche CSV-Export, eine manuelle Korrektur im Backoffice oder ein historischer Statuswert ohne saubere Semantik verursachen oft mehr Risiko als ein fehlender Screen. Deshalb sollte die Systemkarte aus echten Betriebsdaten entstehen und nicht aus Architekturfolien.
Vor dem eigentlichen Build sollten fünf Entscheidungen feststehen:
- Zielausschnitt: Welcher Geschäftspfad wird migriert und was bleibt ausdrücklich im Altsystem?
- Migrationsmuster: Strangler, Parallelbetrieb oder Fassade.
- Datenführerschaft: Welches System ist pro fachlichem Zustand autoritativ?
- Synchronisation: Ereignisbasiert, periodisch oder nur lesende Spiegelung.
- Abbruchkriterien: Bei welchen offenen Punkten wird gestoppt statt weitergebaut?
Der letzte Punkt fehlt in vielen Projekten. Das ist kein Randdetail. Wenn bis Ende des ersten Monats keine belastbare Liste fachlicher Ausnahmen vorliegt, keine Freigabeverantwortlichen benannt sind oder die Zielstrecke nur mit manuellen Sondergriffen stabil bleibt, ist ein Stopp günstiger als ein späterer Cutover unter Druck.
Zusätzlich sollte der Scope auf eine fachliche Wahrheit reduziert werden. Wenn etwa Kundenstatus, Preislogik und Auftragsfreigabe in verschiedenen Altkomponenten leben, ist ein 90-Tage-Vorhaben nur dann realistisch, wenn genau eine dieser Wahrheiten in die Zielstrecke gezogen wird und die anderen vorerst stabil angebunden bleiben. Viele Teams schneiden stattdessen nach Oberfläche. Das ist bequem, aber falsch. Migriert werden sollten Zustände und Entscheidungen, nicht nur Masken.
Hilfreich ist eine kurze Bewertungsmatrix mit drei Spalten: fachlicher Nutzen, Integrationslast und Rückfallfähigkeit. Ein Pfad mit hohem Nutzen, niedriger Integrationslast und sauberem Rollback ist ein Kandidat. Ein Pfad mit hohem Nutzen, aber fünf schreibenden Umsystemen und unklarer Rückabwicklung ist keiner. Diese Nüchternheit spart Wochen.
Architektur und Validierung vor dem Cutover
Die Zielstrecke muss nicht elegant sein. Sie muss idempotent, beobachtbar und fachlich prüfbar sein. Ein Vorgang, der nach Timeout doppelt geschrieben wird, ist kein Randproblem, sondern ein Architekturfehler. Dasselbe gilt für Fehlerpfade ohne Wiederanlauf oder für Mapping-Logik, die Datenbereinigung und Fachregeln untrennbar vermischt.
In der Praxis funktioniert ein robuster Migrationspfad meist mit wenigen klaren Bausteinen: Eingang der Quelldaten, Normalisierung, fachliche Validierung, persistente Ausgabe und Fehlerkanal. Jeder Vorgang braucht dabei eine Korrelation, damit Incident-Analyse nicht in Tabellenexporten endet.
Legacy DB / Datei / API
-> Ingestion-Job oder Event-Consumer
-> Mapping und Normalisierung
-> Fachliche Validierung und Dublettenprüfung
-> Zielsystem
-> Audit-Log + Fehler-Queue + WiederanlaufDer heikle Teil ist fast nie der Transport. Er ist semantisch. Ein Feld wie status=closed kann im Altbestand „fakturiert“ bedeuten, im Ziel aber nur „bearbeitet“. Solche Unterschiede müssen an echten Datensätzen geprüft werden. Wenn diese Klärung in ein späteres Backlog geschoben wird, entsteht eine technisch saubere und fachlich falsche Strecke.
Für die Abnahme reichen wenige harte Schwellen. Sinnvoll sind etwa keine ungeklärten Differenzen bei Summen, Stückzahlen oder Statusverteilungen im freigegebenen Vergleichsfenster, keine fehlenden Pflichtfelder in produktionsrelevanten Datensätzen, ein Wiederanlauf ohne Dubletten und ein Audit-Log mit klaren Fehlerstatus. Mehr Kennzahlen machen die Entscheidung selten besser. Sie machen sie nur schwerer lesbar.
Die Logik dahinter ist näher an Betriebsdisziplin als an klassischem Projektcontrolling. Begriffe aus SRE oder Service Level Objectives helfen nur dann, wenn sie eine konkrete Konsequenz haben: Was gilt als akzeptabler Betrieb, welche Abweichung ist tolerierbar und ab wann wird zurückgeschaltet? Ohne diese Schwellen wird Parallelbetrieb schnell zu einer Beobachtungsphase, die Zeit kostet, aber keine Freigabe erzeugt.
Ein konkretes Beispiel aus dem Handel zeigt, wo die Reibung sitzt. Migriert wurde nicht das gesamte Auftragswesen, sondern nur der Pfad Auftrag anlegen bis Export an Finance in einem Umfeld mit mehreren angebundenen Umsystemen und engem nächtlichen Exportfenster. Kritisch war nicht der Build, sondern die Kosten manueller Nacharbeit bei Summendifferenzen und die Rollout-Reibung rund um das enge Zeitfenster. Deshalb liefen zwei Wochen Parallelbetrieb mit Vergleich von Datensatzanzahl, Summen und Fehlerschlüsseln. Der Scope blieb klein, die Validierung hart, der Rest blieb draußen.
Wenn Alt und Neu übergangsweise gekoppelt bleiben müssen, ist ein Legacy-System an ein neues Produkt anbinden oft die vernünftigere Zwischenstufe als ein sofortiger Komplettumbau. Das ist weniger elegant, aber operativ meist sicherer.
Datenfluss, Mapping und Fehlerkanäle sauber trennen
Viele Migrationen scheitern nicht an fehlender Technik, sondern an vermischter Verantwortung im Datenfluss. Wenn ein Mapping-Service gleichzeitig Daten bereinigt, Fachregeln interpretiert und technische Retries ausführt, lässt sich später kaum noch erklären, warum ein Datensatz im Ziel anders aussieht als im Ursprung. Besser ist eine harte Trennung: Transformation ändert Formate, Validierung prüft Regeln, Orchestrierung steuert Reihenfolge und Wiederanlauf.
Diese Trennung ist nicht akademisch. Sie entscheidet darüber, ob ein Incident in 20 Minuten oder in zwei Tagen verstanden wird. In Vorhaben mit engem Zeitfenster ist das ein echter Kostenfaktor. Ich habe mehrfach gesehen, dass Teams ihre ersten zwei Wochen verlieren, weil sie Fehler nur als Logzeilen sehen, aber nicht als fachlich klassifizierte Fälle.
Ein brauchbares Fehlermodell unterscheidet mindestens vier Klassen: technische Transienten, permanente Mapping-Fehler, fachliche Regelverletzungen und Abhängigkeitsfehler durch Umsysteme. Erst damit wird klar, was automatisch wiederholt werden darf, was in eine manuelle Klärung muss und was den Cutover blockiert.
