Das Playbook für Legacy-Migrationen: Wellen, Parallelbetrieb und identische Zeilenzahlen und Prüfsummen

Jedes Unternehmen hat ein System, das niemand anfassen will: eine alte Datenbank, einen Monolithen, zwei Werkzeuge, die synchron bleiben müssen. Big-Bang-Migrationen solcher Systeme sind der Ort, an dem Wochenenden und Ruf verloren gehen. Was funktioniert, ist absichtlich langweilig: zuerst kartieren, in Wellen umziehen, Alt und Neu nebeneinander laufen lassen und erst umschalten, wenn die Zahlen identisch sind. Das ist mein Playbook, mit den Projekten, in denen es gehalten hat.

Dominik Heinrich

8. November 202611 Min. Lesezeit

1. Warum Big-Bang-Migrationen scheitern

Eine Big-Bang-Migration setzt alles auf eine Nacht: alle Daten, alle Funktionen, alle Nutzer wechseln gleichzeitig. Stimmt etwas nicht, merken Sie es in Produktion, ohne Rückweg, der nicht die seither geleistete Arbeit kostet. Ausserdem bekommt das alte System monatelang keine Änderungen mehr, während das neue gebaut wird, und das Geschäft wartet.

Die Projekte auf dieser Website, die gut liefen, haben diese Wette alle vermieden. Ein ERP und ein CRM blieben mit denselben Daten im täglichen Einsatz, während sie in beide Richtungen verbunden wurden. Hochsensible Gesundheitsdaten wanderten zwischen zwei öffentlichen Systemen, ohne dass ein Datensatz verloren ging. Mandanten-Datenbanken zogen mit identischen Zeilenzahlen und Prüfsummen in einen Kubernetes-Cluster. Unterschiedliche Systeme, dasselbe Muster.

2. Zuerst das alte System kartieren, mit KI, die den Code liest

Vor jedem Plan steht eine Karte: welche Komponenten es gibt, welche Daten sie besitzen, welche Schnittstellen sie nach aussen verbinden, welche Jobs nachts laufen und welche Personen und Teams wovon abhängen. Alte Systeme verstecken ihr tatsächliches Verhalten an Orten, an die sich niemand erinnert: eine Stored Procedure, ein Cron-Job, ein CSV-Export, den jemand jeden Montag öffnet.

Hier hat KI die Arbeit am stärksten verändert. Ein Coding-Agent kann eine grosse alte Codebasis lesen, Einstiegspunkte und Datenflüsse auflisten und die Karte entwerfen, und es braucht Tage Prüfung statt Wochen Lesen. Ich überprüfe jeden wichtigen Befund weiterhin am laufenden System, aber der erste Entwurf ist nicht mehr der längste Teil. Fragen Sie auch die Nutzer: Der Export, den niemand dokumentiert hat, ist der, der die Lohnabrechnung stoppt.

3. Pro Komponente eine Strategie wählen, nicht eine für alles

Nicht jeder Teil verdient eine Neuentwicklung. Die Migrationsleitlinien von AWS nennen die üblichen Strategien: stilllegen, behalten, rehosten, verlagern, replatformen, ersetzen und refaktorieren. Wenden Sie sie pro Komponente an: Das Reporting-Modul, das niemand nutzt, wird stillgelegt, der stabile Batch-Job läuft unverändert auf neuer Infrastruktur, die Datenbank wechselt auf einen verwalteten Dienst, und nur der Teil, der das Geschäft bremst, wird neu gebaut.

So bleibt die teure Arbeit dort, wo sie sich auszahlt. In einem Automotive-Projekt zog eine regulierte Anwendung vollständig in Terraform nach Azure Kubernetes Service, ohne eine einzige Kontrolle zu lockern, und die Cloud-Kosten lagen am Ende rund 25 % tiefer. Die Einsparung kam aus der sorgfältigen Wahl, was sich ändert, nicht daraus, alles zu ändern.

4. Wellen nach Geschäftsfähigkeit, hinter einer Fassade

Teilen Sie den Umzug in Wellen, die für das Geschäft Sinn ergeben: erst die Rechnungsstellung, dann die Kundenkonten, dann das Reporting. Jede Welle ist klein genug, um sie gründlich zu testen und für sich allein zurückzunehmen. Vermeiden Sie den Schnitt nach Technikschichten («erst die Datenbank, dann das Backend»): Eine halb umgezogene Funktion ist der schwierigste Zustand im Betrieb.

Stellen Sie eine Fassade davor, das Strangler-Fig-Muster aus dem Azure Architecture Center: Nutzer und andere Systeme sprechen mit der Fassade, und sie leitet jede Funktion zum alten oder zum neuen System. Eine Funktion umzuziehen wird zu einer Routing-Änderung, die Sie in Minuten zurücknehmen können. Über die Wellen schrumpft das alte System, bis nichts mehr dorthin geleitet wird.

5. Daten bewegen, ohne einen Datensatz zu verlieren

Daten wandern in zwei Phasen: eine Massenkopie von allem, danach Change Data Capture, die die neue Seite bis zum Umschalten aktuell hält. Verwaltete Dienste wie Azure Database Migration Service und AWS DMS erledigen beides für gängige Datenbanken. Wo zwei Systeme länger im Gleichschritt bleiben müssen, gehört eine Queue dazwischen.

So funktionierte die Middleware für die Gesundheitsdaten: Serverless Functions auf Azure, mit Azure Queue Storage zwischen den beiden öffentlichen Systemen. War eine Seite nicht erreichbar, warteten die Datensätze in der Queue, statt verloren zu gehen, und wurden zugestellt, sobald sie zurück war. Wiederholungen, idempotente Verarbeitung und eine Dead-Letter-Queue, auf die wirklich jemand schaut, machen aus «wir hoffen, nichts ging verloren» ein «wir können zeigen, dass nichts verloren ging».

Legacy-Migration in Wellen: KI-gestützte Analyse liest die alte Anwendung; Nutzer und andere Systeme gehen über eine Fassade, die noch nicht umgezogene Funktionen zur alten Anwendung und umgezogene zu den neuen Diensten leitet; die Daten wandern von der alten Datenbank per Massenkopie plus Change Data Capture, werden pro Tabelle und Welle mit Zeilenzahlen und Prüfsummen geprüft und erreichen die neue Datenbank nur, wenn sie identisch sind. — Eine Welle einer Migration: kartieren, über eine Fassade leiten, Daten bewegen, vergleichen, umschalten. Klicken für volle Grösse.

6. Parallelbetrieb, Zeilenzahlen und Prüfsummen

Bevor eine Welle endgültig umschaltet, verarbeiten beide Systeme dieselben Eingaben, und Sie vergleichen die Ergebnisse: Summen, Rechnungen, Berichte, die Zahlen, mit denen die Leute tatsächlich arbeiten. Für die Daten selbst vergleichen Sie pro Tabelle und Welle: die Zeilenzahl und eine Prüfsumme über den Inhalt in fester Reihenfolge. AWS DMS bringt eine Validierung mit, die Quelle und Ziel Zeile für Zeile vergleicht; für alles andere reicht eine Abfrage wie die unten auf beiden Seiten.

Vereinbaren Sie die Regel vorher: Weichen Zählung oder Prüfsumme ab, schaltet die Welle nicht um, egal wie nah das Datum ist. Als im FinOps-Projekt Mandanten-Datenbanken mit CloudNativePG in einen Kubernetes-Cluster zogen, waren Zeilenzahlen und Prüfsummen identisch, bevor ein einziger Mandant umgeschaltet wurde.

sql

-- Run on the old and the new database, per table and per wave (PostgreSQL)
SELECT 'invoices'                                            AS table_name,
       count(*)                                              AS row_count,
       md5(string_agg(md5(t::text), '' ORDER BY t.id))       AS checksum
FROM invoices t;
-- Same result on both sides, or the wave does not switch.

7. Umschalten, mit einem getesteten Rückweg

Das Umschalten einer Welle ist eine kurze, geprobte Routine: Schreibzugriffe auf die Daten der Welle einfrieren, die letzten Änderungen ankommen lassen, Zählungen und Prüfsummen ein letztes Mal vergleichen, die Fassade umstellen, die Geschäftskennzahlen beobachten. Lassen Sie die alte Seite eine Weile nur lesend weiterlaufen, damit Sie nachschlagen können und ein Rückweg möglich bleibt.

Ein Rückweg, der nie ausgeführt wurde, ist kein Plan. Proben Sie ihn an einer Kopie: Fassade zurückstellen, die auf der neuen Seite gemachten Änderungen nachspielen, die Zahlen erneut prüfen. Wenn alle einmal gesehen haben, dass es funktioniert, ist der Umschalttag ruhig statt heroisch.

8. Die Arbeit abschliessen: abschalten und als Code behalten

Eine Migration ist fertig, wenn das alte System weg ist, nicht wenn das neue live ist. Archivieren Sie, was Sie aus rechtlichen Gründen behalten müssen, schalten Sie die alte Seite ab, kündigen Sie Lizenzen und Verträge und löschen Sie, was niemand braucht. Sonst zahlen Sie für zwei Systeme, und das alte hält ein Sicherheitsrisiko am Leben.

Und bauen Sie die neue Seite ab dem ersten Tag als Code, damit die nächste Änderung ein Pull Request ist und keine weitere Migration. Im Automotive-Projekt ging alles als Terraform hinein, mit Policies, die für jedes Team gelten: Die Plattform, auf die Sie migrieren, sollte leichter zu ändern sein als die, die Sie verlassen haben.

Fazit
Migrieren Sie wie ein Buchhalter, nicht wie ein Held: zuerst kartieren, in Wellen hinter einer Fassade umziehen, beide Seiten parallel betreiben und erst bei identischen Zeilenzahlen und Prüfsummen umschalten.

Echte Projekte dazu

Das für Ihr Unternehmen? Sprechen wir mail@dominikheinrich.ch

Quellen und offizielle Leitfäden