Migration aus Legacy in 90 Tagen ohne Risiko planen

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:

1. Zielausschnitt: Welcher Geschäftspfad wird migriert und was bleibt ausdrücklich im Altsystem?
2. Migrationsmuster: Strangler, Parallelbetrieb oder Fassade.
3. Datenführerschaft: Welches System ist pro fachlichem Zustand autoritativ?
4. Synchronisation: Ereignisbasiert, periodisch oder nur lesende Spiegelung.
5. 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 + Wiederanlauf

Der 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.

{
  "correlationId": "8f2c-41ab",
  "sourceSystem": "legacy-order",
  "entityType": "order",
  "entityId": "4711",
  "errorClass": "business_validation",
  "errorCode": "MISSING_TAX_REGION",
  "retryable": false,
  "targetAction": "manual_review"
}

Gerade bei Legacy-Modernisierung wird Auditierbarkeit oft zu spät eingebaut. Das ist ein Fehler. Wer erst kurz vor dem Cutover merkt, dass sich ein Zielzustand nicht auf den Ursprungsdatensatz zurückführen lässt, hat kein Qualitätsproblem mehr, sondern ein Freigabeproblem.

Validierung mit Produktionsnähe statt Testdatenromantik

Testdaten sind nützlich, aber sie lügen oft freundlich. Historisch gewachsene Sonderfälle, abgeschnittene Zeichensätze, alte Statuscodes oder implizite Geschäftsregeln tauchen dort selten auf. Für eine Legacy-Migration in 90 Tagen braucht es deshalb früh ein freigegebenes Vergleichsfenster mit realen oder realitätsnah anonymisierten Datensätzen.

Ein praktikabler Ablauf ist simpel. Zuerst wird ein Referenzbestand gezogen. Danach laufen Alt und Neu auf denselben Eingängen. Anschließend werden nicht nur Einzelobjekte verglichen, sondern Verteilungen: Statushäufigkeiten, Summen, Fehlerschlüssel, Durchlaufzeiten und manuelle Eingriffe. Diese Sicht ist robuster als das Prüfen einiger zufällig ausgewählter Datensätze.

Wenn für den Parallelbetrieb ein belastbarer Referenzrahmen fehlt, hilft ein Blick in die Dokumentation des Microsoft Azure Cloud Adoption Framework für Migration. Relevant ist dort nicht irgendein Tool-Hinweis, sondern das Prinzip der wiederholbaren Migrationswellen mit klarer Bewertung vor dem nächsten Schritt. Genau diese Logik passt auch hier: kleine Läufe, reproduzierbare Vergleiche, definierte Freigaben statt einmaliger Testabnahme mit Hoffnung auf Stabilität.

Cutover und Parallelbetrieb ohne Schönrechnerei

Der Cutover ist kein verlängerter Test. Er ist ein Betriebsereignis. Parallelbetrieb sollte lang genug sein, um reale Schwankungen zu sehen, aber kurz genug, um keine zwei Wahrheiten zu erzeugen. Verglichen werden nicht nur Einzelfälle, sondern Aggregate: Anzahl Vorgänge, Summen, Durchlaufzeit, offene Fehler, manuelle Nacharbeit und Alter ungeklärter Fälle.

Ein Minimal-Cutover ist fast immer die bessere Wahl. Kleines Freeze-Fenster, letzter differenzieller Nachzug, wenige harte Smoke-Tests, klare Go/No-Go-Entscheidung und ein Rückfallpfad, der technisch wirklich ausführbar ist. Wer beim Umschalten noch Berechtigungen, Datenmodell und Prozesslogik gleichzeitig korrigieren will, baut die Störung selbst ein.

Typisch wird es genau dann kritisch, wenn nach dem letzten Nachzug noch unklare Statusdifferenzen offen sind. Dann steht das Team im Umschaltfenster vor einer schlechten Wahl: trotzdem live gehen und manuelle Korrekturen in Kauf nehmen oder abbrechen, obwohl bereits Freeze, Bereitschaft und Fachfreigaben aktiviert wurden. Dieser Druck entsteht nicht am Umschalttag. Er entsteht Tage vorher, wenn Vergleichsläufe zwar Abweichungen zeigen, aber niemand deren fachliche Relevanz sauber bewertet.

Das Cutover-Protokoll muss nicht lang sein. Es muss präzise sein: Freeze-Regel, finaler Nachzug, Smoke-Tests, Rollback-Schwelle und Incident-Führung. Vor allem die Rollback-Schwelle darf nicht weich formuliert sein. Ungeklärte Summendifferenzen, nicht wiederanlaufbare Kernfehler, fehlende Auditierbarkeit oder widersprüchliche Folgeaktionen zwischen Alt und Neu sind keine Warnhinweise. Das sind Stoppsignale.

Beim Parallelbetrieb fehlt oft nicht die Technik, sondern die Vergleichslogik. Häufig werden zwar Datensätze gespiegelt, aber es fehlen vorab definierte Metriken wie Summendifferenzen pro Tag, Statusverteilungen, Anzahl manueller Korrekturen, Fehlerschlüssel nach Klasse oder die maximale Liegezeit ungeklärter Fälle. Im Projektalltag führt das dazu, dass Fachbereich und IT dieselben Läufe unterschiedlich bewerten: Die einen sehen „fast identisch“, die anderen sehen keine belastbare Freigabe. Dann verlängert sich der Parallelbetrieb, ohne dass die Entscheidungslage besser wird.

Für den eigentlichen Umschalttag hilft eine nüchterne Reihenfolge:

1. Freeze aktivieren: Schreibzugriffe im Altpfad begrenzen oder kontrolliert puffern.
2. Letzten Nachzug ausführen: Nur differenzielle Änderungen seit dem letzten validierten Lauf übernehmen.
3. Smoke-Tests fahren: Ein kleiner Satz produktionsnaher Kernfälle mit klaren Sollwerten.
4. Monitoring scharf schalten: Fehlerquote, Queue-Länge, Latenz und fachliche Differenzen live beobachten.
5. Go oder Rollback entscheiden: Nicht nach Bauchgefühl, sondern gegen die vorher definierten Schwellen.

Wenn ein Rollback vorgesehen ist, muss es geübt werden. Ein Rückfallpfad, der nur auf Folien existiert, ist keiner. Besonders heikel wird es, wenn das Zielsystem bereits Folgeaktionen ausgelöst hat, etwa Benachrichtigungen, Buchungen oder Exporte. Dann reicht es nicht, Daten zurückzuschreiben. Dann müssen auch Seiteneffekte kontrolliert rückabgewickelt oder isoliert werden.

Kosten, Aufwand und die falschen Sparhebel

Bei einem 90-Tage-Vorhaben liegen die Kosten selten im offensichtlichen Build. Sie liegen in Discovery, Validierung, Parallelbetrieb, Ausnahmelogik und Betriebsabsicherung. Genau diese Positionen werden in schwachen Angeboten klein gerechnet, weil sie sich schlechter verkaufen als neue Oberflächen oder moderne Plattformbegriffe.

Ein kompakter Vergleich zeigt die typische Verschiebung:

• Billig kalkuliert: viel Entwicklungszeit, wenig Analyse, kaum Parallelbetrieb, Rollback nur grob beschrieben.
• Belastbar kalkuliert: weniger Feature-Breite, dafür klare Datenanalyse, Vergleichsläufe, Incident-Prozess und Cutover-Proben.

Die zweite Variante wirkt anfangs teurer. In der Realität ist sie oft günstiger, weil sie operative Nacharbeit und verlängerte Doppelpflege reduziert. Wer nur auf den Tagessatz schaut, übersieht den teuersten Posten: Störungen im laufenden Betrieb.

Ein brauchbarer Budgetrahmen sollte deshalb mindestens vier Blöcke getrennt ausweisen: Analyse und Scope-Schnitt, Implementierung der Zielstrecke, Validierung inklusive Parallelbetrieb sowie Cutover und Hypercare. Fehlt einer dieser Blöcke im Angebot, fehlt meist nicht nur eine Zahl, sondern ein ganzer Risikobereich.

Gerade im Einkauf wird hier oft falsch priorisiert. Teams verhandeln hart über Entwicklungstage und akzeptieren gleichzeitig unklare Annahmen bei Datenqualität, manueller Nacharbeit und Betriebsübergabe. Das ist kein Sparen, sondern Risikoverschiebung. Die Rechnung kommt später über verlängerten Parallelbetrieb, zusätzliche Freigabeschleifen und Wochenendarbeit im Cutover.

Wann externe Unterstützung sinnvoll ist und woran man Angebote erkennt

Externe Hilfe ist nicht erst dann sinnvoll, wenn intern niemand entwickeln kann. Sie lohnt sich, wenn Datenführerschaft ungeklärt ist, mehrere Umsysteme betroffen sind, regulatorische Nachweise sauber geplant werden müssen oder das eigene Team zwar das Fachmodell kennt, aber keine belastbare Cutover- und Betriebsroutine hat. Migrationen scheitern oft nicht an fehlender Entwicklungskapazität, sondern an schwacher Übergangsarchitektur.

Belastbare Angebote erkennt man an den Fragen vor Projektstart. Ein seriöser Dienstleister prüft Scope-Grenzen, schreibende Systeme, Vergleichsmetriken, Ausnahmelogik, Rollback-Fenster und Betriebsverantwortung, bevor er einen Termin zusagt. Vorsicht bei Angeboten, die 90 Tage versprechen, aber Discovery, Parallelbetrieb oder Freigabelogik nur am Rand erwähnen. Hier liegt auch ein Marktproblem, über das zu selten offen gesprochen wird: Wer Legacy-Migrationen primär nach Tagessatz einkauft, kauft oft die falsche Optimierung. Billiger wird das selten, weil die Rechnung später über Nacharbeit, verlängerten Parallelbetrieb und operative Störungen kommt.

Intern sollten vor Projektstart drei Vorleistungen vorhanden sein: ein benannter fachlicher Entscheider, Zugriff auf reale Betriebsdaten und die Bereitschaft, Scope aktiv zu kürzen. Fehlt einer dieser Punkte, wird aus dem Vorhaben schnell ein Verhandlungskonflikt zwischen Fachbereich, IT und Dienstleister.

Ein weiterer Prüfpunkt wird oft übersehen: Wer betreibt die Übergangsarchitektur nach dem Go-live? Wenn Adapter, Queue-Consumer, Audit-Logs und Vergleichsjobs zwar gebaut, aber keinem Team sauber übergeben werden, bleiben genau die Artefakte ohne Eigentümer, die später im Incident-Fall zuerst gebraucht werden. Dann weiß niemand, wer Retry-Regeln anpasst, wer Audit-Lücken bewertet oder wer einen festhängenden Vergleichslauf fachlich freigibt. Mittelfristig steigen Wartungsaufwand, Reaktionszeit im Störungsfall und oft auch die Betriebskosten, obwohl die eigentliche Migration formal schon als Erfolg gilt.

Nach 90 Tagen muss nicht das ganze Legacy-System verschwunden sein. Das wäre meist das falsche Ziel. Erreicht sein sollte ein produktiver, abgesicherter Zielausschnitt mit messbarer Entlastung des Altkerns, klarer Beobachtbarkeit und einer Übergangsarchitektur, die den nächsten Schritt vereinfacht. Für den ersten Migrationspfad sprechen in der Praxis meist drei Merkmale: wenige schreibende Umsysteme, klar messbare Vergleichswerte im Parallelbetrieb und ein Rückfallpfad ohne unkontrollierte Seiteneffekte. Wenn diese Merkmale fehlen, ist nicht der Termin das Problem. Dann ist der Einstiegspfad noch nicht reif.