Einen Legacy-Monolithen modernisieren
Ein gewachsenes Altsystem ablösen, ohne den Betrieb zu riskieren — Schritt für Schritt statt Big-Bang.
Was ist das? · Playbook
Ein wiederholbares Vorgehen für eine wiederkehrende Herausforderung — Situation, Schritte, Entscheidungspunkte und Validierung. Wie wir es tun, nicht warum. Zur Übersicht
Wann dieses Playbook greift.
Ein über Jahre gewachsenes System trägt das Geschäft, ist aber schwer änderbar geworden: unklare Grenzen, dünne Testabdeckung, Wissen in wenigen Köpfen. Ein vollständiger Neubau ist verlockend — und riskant.
Ziele
- Das Altsystem bleibt jederzeit betriebsbereit.
- Änderbarkeit und Wartbarkeit kehren schrittweise zurück.
- Wissen wird gesichert, nicht durch einen Neubau verloren.
Typische Risiken
- Big-Bang-Rewrite: monatelang kein Mehrwert, hohes Umschaltrisiko.
- Datenmigration ohne bewiesenen Rückweg.
- Neue und alte Logik driften auseinander — doppelte Wahrheit.
- Unklare Altgrenzen werden 1:1 ins neue System übernommen.
Bevor wir bauen.
- Bestandsaufnahme: Was tut das System wirklich, wo liegen die Risiken?
- Charakterisierungstests um die kritischen Pfade legen, bevor etwas verändert wird.
- Fachliche Grenzen (Bounded Contexts) identifizieren, unabhängig vom Altcode.
- Reversible Migrationsstrategie festlegen und Backup/Restore beweisen.
Wie wir vorgehen.
Strangler Fig statt Rewrite
Neue Funktionalität entsteht neben dem Altsystem; Anfragen werden Funktion für Funktion umgeleitet. Das Alte läuft, bis das Neue es sicher ersetzt hat.
Grenzen zuerst schneiden
Wir lösen entlang stabiler Domänengrenzen ab, nicht entlang technischer Schichten. Die erste Grenze ist die risikoärmste mit klarem Nutzen.
Eine Quelle der Wahrheit
Während des Übergangs hält ein System die Wahrheit für einen Datenbereich — nie beide. Synchronisation ist explizit und einseitig.
Kleine, umkehrbare Schritte
Jede Umleitung ist einzeln ausrollbar und zurücknehmbar. Fortschritt ist wöchentlich sichtbar und im Betrieb messbar.
Fragen, die eine Antwort brauchen.
Ist die nächste abzulösende Grenze fachlich stabil — oder ändert sie sich noch?
Existiert für den betroffenen Pfad ein Charakterisierungstest?
Ist die Umleitung reversibel, wenn sie fehlschlägt?
Bleibt die Quelle der Wahrheit eindeutig?
Validierung
- Der abgelöste Pfad verhält sich nachweislich wie zuvor (Charakterisierungstests grün).
- Umschaltung und Rücknahme sind im Staging geprobt.
- Metriken zeigen keinen Regressionseffekt im Betrieb.
Häufige Fehler
- Den Rewrite als Projekt starten, bevor die Grenzen verstanden sind.
- Unklare Altgrenzen unverändert übernehmen.
- Datenmigration ohne bewiesenen Rückweg.
- Schritte, die zu groß sind, um sie einzeln zurückzunehmen.
Wann wir bewusst anders vorgehen.
- Wenn das Altsystem klein, gut verstanden und risikoarm ist, kann ein gezielter Neubau günstiger sein als schrittweise Ablösung.
- Wenn das System ohnehin abgeschaltet wird, lohnt keine Modernisierung — nur ein sauberer Ausstieg.
Beteiligte Phasen der Engineering Method
Setzen Sie Ihren Engineering-Weg fort.
Verwandte Konzepte, Entscheidungen, Playbooks und Standpunkte — als zusammenhängender Pfad, nicht als Linkliste.
Verwandte Konzepte
Engineering-Entscheidungen
Eine ähnliche Herausforderung?
Playbooks zeigen, wie wir denken. Für Ihr konkretes Vorhaben sprechen Sie mit der Geschäftsführung — technisch, ohne Vertrieb.
