Das Legacy-Dilemma
Jedes Unternehmen mit mehr als 10 Jahren IT-Geschichte kennt das Problem: Ein System, das geschäftskritisch ist, aber niemand mehr gerne anfasst. Die Dokumentation ist lückenhaft, die ursprünglichen Entwickler sind weg, die Technologie ist veraltet — aber das System läuft und verdient Geld.
Die Versuchung: alles neu bauen. Die Realität: 70 % aller Big-Bang-Migrationen scheitern oder überschreiten Budget und Zeitrahmen massiv.
Warum Big-Bang scheitert
1. Unterschätzter Umfang
Legacy-Systeme enthalten jahrelang gewachsene Geschäftslogik, die nirgends dokumentiert ist. Erst im Nachbau entdeckt man Edge Cases, die das alte System stillschweigend behandelt.
2. Kein Business Value während der Migration
Ein Rewrite liefert über Monate keinen neuen Geschäftswert — während die Konkurrenz Features ausrollt.
3. Alles-oder-nichts-Risiko
Wenn der Go-Live scheitert, gibt es kein Zurück — oder der Rückfall auf das alte System widerspricht der neuen Datenbankstruktur.
Das Strangler-Fig-Pattern
Prinzip
Statt das alte System zu ersetzen, bauen Sie neue Funktionalität daneben und leiten schrittweise Traffic um:
- Identifizieren — Welche Funktion soll zuerst modernisiert werden?
- Implementieren — Neue Version der Funktion in moderner Architektur bauen
- Umleiten — Traffic für diese Funktion vom alten zum neuen System routen
- Verifizieren — Verhalten und Daten vergleichen
- Abschalten — Alte Funktion im Legacy-System deaktivieren
Der Proxy als Schlüssel
Ein Reverse Proxy oder API Gateway steht zwischen den Clients und beiden Systemen. Er entscheidet, welche Anfragen an das alte und welche an das neue System gehen. Das ermöglicht:
- Schrittweise Migration — Route für Route
- Canary Releases — 5 % des Traffics auf das neue System, dann 10 %, 50 %, 100 %
- Sofortiges Rollback — bei Problemen Traffic zurückleiten
Welche Funktionen zuerst?
Die Reihenfolge entscheidet über Erfolg oder Misserfolg:
Zuerst migrieren:
- Funktionen mit hoher Änderungsfrequenz (wo das Legacy-System am meisten bremst)
- Funktionen mit klaren Schnittstellen (wenig Abhängigkeiten zum Rest)
- Funktionen mit messbarem Business Impact
Zuletzt migrieren:
- Kernfunktionen mit komplexer, undokumentierter Geschäftslogik
- Funktionen mit tiefer Datenbankintegration
- Funktionen, die selten geändert werden (der ROI der Migration ist gering)
Datenmigration
Die größte Herausforderung ist selten der Code, sondern die Daten:
Shared Database (kurzfristig)
Altes und neues System nutzen dieselbe Datenbank. Einfach, aber koppelt die Systeme.
Database per Service (Zielzustand)
Jeder neue Service hat seine eigene Datenbank. Erfordert Datensynchronisation.
Change Data Capture (CDC)
Änderungen in der alten Datenbank werden als Events erfasst und an die neuen Services propagiert. Tools: Debezium, AWS DMS, Striim.
Anti-Patterns
| Anti-Pattern | Konsequenz |
|---|---|
| „Erst alles planen, dann alles bauen” | Zurück beim Big-Bang |
| Feature Parity als Ziel | Man baut das alte System nach statt es zu verbessern |
| Kein Proxy/Gateway | Keine Möglichkeit, Traffic schrittweise umzuleiten |
| Altes System nicht warten | Das Legacy-System muss während der Migration stabil bleiben |
| Zu viele Services auf einmal | Mehr als 2-3 parallele Migrationen überlastet das Team |
Zeithorizont
Ehrliche Erwartungen:
| Unternehmensgröße | Legacy-Alter | Typische Dauer |
|---|---|---|
| 50-200 Mitarbeiter | 5-10 Jahre | 12-18 Monate |
| 200-1000 Mitarbeiter | 10-20 Jahre | 18-36 Monate |
| 1000+ Mitarbeiter | 15+ Jahre | 24-48 Monate |
Fazit
Legacy-Modernisierung ist ein Marathon, kein Sprint. Das Strangler-Fig-Pattern gibt Ihnen die Kontrolle: Sie entscheiden, was wann migriert wird, können jederzeit stoppen oder die Richtung ändern und liefern dabei kontinuierlich Geschäftswert. Die Alternative — das alte System noch ein weiteres Jahr zu „pflegen” — wird nicht billiger.