Legacy-Modernisierung
Schrittweise modernisieren. Ohne Big-Bang-Rewrite.
70 % der Big-Bang-Rewrite-Projekte scheitern. Wir modernisieren mit dem Strangler-Fig-Pattern — jeder Schritt bringt Wert und ist rueckgaengig machbar.
Warum kein Big-Bang-Rewrite¶
Die Statistik ist eindeutig: 70 % der grossen Rewrite-Projekte ueberschreiten das Budget um 2x+ oder scheitern komplett. Gruende:
- Scope Creep — „Da wir es sowieso neu machen, fuegen wir noch X, Y, Z hinzu”
- Wissensverlust — Niemand weiss, warum Legacy tut, was es tut. Grenzfaelle zeigen sich erst in der Produktion.
- Doppelte Wartung — 12-24 Monate zwei Systeme parallel pflegen
- Big-Bang-Risiko — Tag X: Sie schalten um und hoffen
Das Strangler-Fig-Pattern eliminiert alle diese Risiken.
7-Schritte-Modernisierungs-Playbook¶
Schritt 1: Stabilisierung und Messung (2-4 Wochen)
Bevor Sie anfangen zu aendern, muessen Sie wissen, wo Sie stehen. Wir deployen Monitoring, sammeln Baseline-Metriken, identifizieren Engpaesse. Ergebnis: Health Report des Legacy-Systems mit konkreten Zahlen.
Schritt 2: Domaenen-Mapping (1-2 Wochen)
Event-Storming-Workshops mit Domaenenexperten. Wir kartieren Bounded Contexts, Abhaengigkeiten, Datenfluesse. Wir identifizieren Kandidaten fuer die erste Migration — Module mit den wenigsten Abhaengigkeiten und dem hoechsten Wert.
Schritt 3: API Gateway (2-3 Wochen)
Fassade vor dem Legacy. Alle Anfragen gehen durch das Gateway, Routing-Regeln entscheiden, wer bedient. Neues System hinter Gateway, Legacy hinter Gateway. Umschaltung auf Endpunkt-Ebene.
Schritt 4: Erste Modul-Isolation (4-8 Wochen)
Wir extrahieren den ersten Bounded Context in einen eigenstaendigen Service. Eigene Datenbank, eigenes Deployment, eigenes Monitoring. Anti-Corruption Layer schuetzt den neuen Service vor dem Legacy-Datenmodell.
Schritt 5: Datenmigration (2-4 Wochen pro Modul)
CDC (Debezium) fuer Echtzeit-Replikation. Dual-Write mit Reconciliation-Jobs. Konsistenzmetriken — Migration ist abgeschlossen, wenn die Reconciliation 7 Tage in Folge 100 % Uebereinstimmung zeigt.
Schritt 6: Traffic-Shifting (1-2 Wochen pro Modul)
Canary Release: 5 % → 25 % → 50 % → 100 %. Automatische Metriken entscheiden ueber Fortfahren. Rollback in Sekunden. Menschliches Eingreifen nur bei Anomalien.
Schritt 7: Stilllegung (1-2 Wochen pro Modul)
Altes Modul abschalten. Neues Modul 30 Tage nach vollstaendigem Rollout monitoren. Datenarchivierung. Dokumentation.
Datenmigration — der schwierigste Teil¶
Legacy-Systeme haben Jahre technischer Schulden in den Daten: - Inkonsistente Formate (Datum als String in 5 verschiedenen Formaten) - Fehlende Validierung (NULL wo es nicht sein sollte, Duplikate) - Implizite Geschaeftslogik in Daten (Statuscodes, die niemand dokumentiert hat)
Unser Ansatz: 1. Analyse — Quelldata-Profiling, Anomalie-Identifikation 2. Transformationsregeln — Mapping + Bereinigung + Validierung 3. CDC-Pipeline — Debezium fuer Echtzeit-Synchronisation 4. Reconciliation — Automatischer Vergleich Quelle vs. Ziel 5. Rollback-Plan — Fuer jeden Schritt
Erfolg messen¶
Modernisierung ohne Metriken ist nur Neuschreiben. Wir messen:
- Deployment-Frequenz — Von monatlich zu taeglich
- Lead Time — Von Wochen zu Stunden
- MTTR — Von Stunden zu Minuten
- Change Failure Rate — Unter 5 %
- TCO — Gesamtkosten fuer Betrieb und Entwicklung
- Entwicklerzufriedenheit — Ja, wir messen auch die Teamzufriedenheit
Häufig gestellte Fragen
6-18 Monate je nach Systemgroesse. Aber wir liefern Wert ab dem ersten Quartal — besseres Monitoring, schnellere Deployments, reduzierte Betriebskosten.
Jeder Schritt ist rueckgaengig machbar. Das alte System laeuft parallel, bis das neue seine Qualitaet bewiesen hat. Wir trennen Legacy nie ab, bis das neue System alle Quality Gates bestanden hat.
Nein. Strangler Fig ermoeglicht parallele Entwicklung — neue Features gehen ins neue System, das alte wird nur noch gewartet. Das Team blockiert das Business nicht.