Legacy-System modernisieren ohne Ausfallzeit: Der Praxis-Leitfaden
"Never touch a running system" ist einer der teuersten Sätze der IT. Er klingt vernünftig – bis das System so alt ist, dass jede Änderung zum Risiko wird und das Unternehmen trotzdem längst nicht mehr stehen bleiben kann. Die gute Nachricht: Du musst dich nicht zwischen "Stillstand" und "riskanter Kompletttausch am Wochenende" entscheiden. Mit dem richtigen Vorgehen läuft dein System während der gesamten Modernisierung normal weiter – deine Kund:innen merken nichts davon.
Warum der "Big Bang" beim laufenden Betrieb scheitert
Der klassische Fehler: Ein Team verschwindet für sechs bis zwölf Monate, baut das System komplett neu, und plant einen großen Cutover-Termin. Das Problem ist nicht der Ehrgeiz, sondern die Physik des Risikos: Je länger zwei Systeme parallel existieren, ohne dass eines produktiv validiert wird, desto größer die Lücke zwischen Annahme und Realität. Am Cutover-Wochenende zeigt sich dann jeder übersehene Edge-Case gleichzeitig – im Produktivbetrieb, unter Zeitdruck. Ich habe dazu einen ausführlichen Artikel über den Big-Bang-Mythos geschrieben, falls du tiefer einsteigen willst.
Das Strangler-Fig-Pattern: der sichere Ausweg
Die Alternative stammt von Martin Fowler und ist nach der Würgefeige benannt, die einen Wirtsbaum langsam umschließt, bis dieser nicht mehr gebraucht wird. Übertragen auf Software heißt das: Du legst eine Routing-Schicht (Proxy, API-Gateway oder Feature-Flag-Layer) vor dein Altsystem und ersetzt Funktion für Funktion durch die neue Implementierung – während der Rest unverändert weiterläuft.
Der entscheidende Vorteil: Nach jedem einzelnen Schritt hast du wieder ein vollständig lauffähiges, produktives System. Kein monatelanger Schwebezustand, kein "Alles oder nichts".
So läuft eine Zero-Downtime-Modernisierung in der Praxis ab
- Ist-Zustand erfassen. Welche Module gibt es, wie hängen sie zusammen, wo liegen die größten Risiken und die teuersten Wartungskosten? Genau das ist der Kern eines Architecture & Code Health Audits.
- Nahtstellen definieren. Du ziehst klare Grenzen zwischen fachlichen Domänen (Bounded Contexts), damit du einzelne Teile isoliert austauschen kannst, ohne den Rest anzufassen.
- Routing-Layer einziehen. Ein Proxy oder Gateway entscheidet pro Request, ob die alte oder die neue Implementierung antwortet – zunächst für 0 %, dann für 5 %, dann für 100 % des Traffics.
- Modul für Modul ersetzen. Jede Migration ist ein kleiner, in sich abgeschlossener Schritt mit eigenem Test- und Rollback-Plan.
- Datenmigration absichern. Für Datenbanken bewähren sich Dual-Write (beide Systeme schreiben parallel) und Shadow-Read (die neue Implementierung liest bereits mit, ohne dass ihre Antwort ausgeliefert wird) – so vergleichst du beide Ergebnisse, bevor du umschaltest.
- Altcode konsequent entfernen. Der letzte Schritt wird gerne vergessen: Sobald ein Modul vollständig migriert ist, muss der alte Pfad aus dem System verschwinden – sonst wächst die Komplexität statt zu sinken.
Feature-Flags als Rückversicherung
Feature-Flags entkoppeln Deployment von Aktivierung. Du kannst neuen Code produktiv ausrollen, ohne dass er sofort für alle Nutzer:innen aktiv ist. Zeigt sich ein Problem, drehst du den Flag zurück – ganz ohne Rollback-Deployment und ohne Downtime. Für geschäftskritische Systeme ist das der Unterschied zwischen einem stillen Incident und einem öffentlichen Ausfall.
Typische Stolperfallen
- Kein automatisiertes Test-Netz. Ohne Regressionstests wird jede Migration zum Blindflug. Charakterisierungstests für den Ist-Zustand sind Pflicht, bevor du etwas veränderst.
- Zu große Schnitte. Ein Modul, das "nur mal eben" mitmigriert wird, ist meist größer als gedacht. Kleinere Schritte reduzieren das Risiko pro Deployment drastisch.
- Datenintegrität wird zu spät geprüft. Dual-Write-Fehler fallen oft erst Wochen später auf – regelmäßige Konsistenzchecks zwischen altem und neuem System sind kein Nice-to-have.
- Der Cutover-Zeitpunkt wird politisch statt technisch entschieden. Umgeschaltet wird, wenn die Metriken stimmen – nicht, wenn der Quartalsbericht ansteht.
Fazit
Zero-Downtime-Modernisierung ist kein Sonderfall für Großkonzerne, sondern für jedes Unternehmen erreichbar, das seine Migration in kleine, reversible Schritte zerlegt und konsequent misst statt hofft. Der größte Hebel liegt dabei nicht im Tooling, sondern in der Reihenfolge: erst Nahtstellen, dann Routing, dann Migration – nie umgekehrt.
Willst du wissen, wo die sichersten Nahtstellen in deinem System liegen? Im Architecture & Code Health Audit analysiere ich dein System in zwei Tagen und liefere dir einen priorisierten, risikoarmen Modernisierungs-Fahrplan.