Modernisierung ohne Big-Bang-Rewrite — ein Ansatz

Jedes Altsystem produziert irgendwann dieselbe Besprechung. Jemand legt dar, wie viel schneller alles auf einer sauberen Architektur wäre, alle stimmen zu, und ein Rewrite wird für zwei Quartale eingeplant. Achtzehn Monate später gibt es zwei Systeme: eines verdient Geld, das andere ist fast fertig.

Die Alternative heißt nicht „damit leben“. Sie heißt: das System ersetzen, während es weiterläuft — eine Route nach der anderen, jeder Schritt in Produktion ausgeliefert, jeder Schritt zurücknehmbar. Die Muster dafür sind alt, gut dokumentiert und langweilig, und genau das will man. Dieser Artikel handelt davon, wie sie zusammenspielen — und von dem Abschnitt, den die meisten Texte weglassen: wann ein Rewrite tatsächlich die richtige Antwort ist.

Warum Big-Bang-Rewrites immer wieder passieren

Sie passieren immer wieder, weil sie tatsächlich verlockend sind, und es lohnt sich, fair zu benennen warum. Ein Rewrite verspricht eine saubere Spezifikation, ein Enddatum und keine Kompromisse mit Entscheidungen von Leuten, die längst weg sind. Die schrittweise Ablösung verspricht nichts davon. Sie verspricht ein Jahr mit zwei Systemen gleichzeitig.

Fowler benennt den Denkfehler präzise: „Replacing a serious IT system takes a long time, and the users can't wait for new features. Replacements seem easy to specify, but often it's hard to figure out the details of existing behavior.“ Strangler Fig Application.

Der zweite Satz ist das ganze Problem. Die Spezifikation für den Ersatz ist das Verhalten des alten Systems, und niemand weiß, worin es besteht. Nicht weil das Team nachlässig wäre — sondern weil fünfzehn Jahre Sonderfälle, Workarounds und regulatorische Flicken in Code stecken, den niemand vollständig gelesen hat, und gut die Hälfte davon sind keine Bugs. Sie sind der Grund, warum ein bestimmter Kunde geblieben ist.

Es gibt auch einen organisatorischen Grund, und ihn zu ignorieren ist der Grund, warum gute technische Argumente verlieren. Ein Rewrite lässt sich leicht finanzieren, weil er eine Form hat, die ein Budget versteht: einen Umfang, ein Enddatum, eine Zahl. Die schrittweise Ablösung verlangt eine dauerhafte Zuteilung ohne Fertigstellungstermin — und das ist deutlich schwerer zu genehmigen, selbst wenn es günstiger ist. Damit der schrittweise Plan die Besprechung übersteht, geben Sie ihm dieselben Artefakte: eine Folge datierter Meilensteine, von denen jeder etwas Sichtbares liefert.

Die Risikokurve, die niemand zeichnet

Beide Ansätze leisten in etwa dieselbe Gesamtarbeit. Der Unterschied liegt vollständig in der Form des Risikos — genauer: darin, wie lange zwischen einer Entscheidung und der Erkenntnis vergeht, ob sie richtig war.

Die Delivery-Forschung zeigt immer in dieselbe Richtung. Der DORA-Report 2025 fand die größte Gruppe von Teams bei einer Change Failure Rate von 8–16 %, mit 39,5 % oberhalb von 16 % — und nur 16,2 % können bei Bedarf deployen. Liest man das nebeneinander, ergibt sich das Argument für kleine Änderungen von selbst: Wenn etwa jede achte Änderung fehlschlägt, sollten Änderungen klein, häufig und einzeln zurücknehmbar sein. Berichterstattung zu den Benchmarks 2025 (Sekundärquelle, nicht der Report selbst).

Ein Big-Bang-Cutover ist eine einzelne Änderung mit einer Fehlerrate, die Sie nie gemessen haben.

Die Nahtstellen finden

Schrittweise Ablösung braucht eine Schnittstelle zum Ansetzen, und Altsysteme bieten sie selten dort, wo man sie hätte. Eine Nahtstelle ist jeder Punkt, an dem sich ein Aufruf umleiten lässt, ohne den Aufrufer zu ändern. Die Arbeit des ersten Monats besteht darin, sie zu finden — und wenn es keine gibt, eine zu schaffen.

• Am Rand. Eine HTTP-Route, ein Queue-Topic, ein geplanter Job. Die einfachsten Nahtstellen, weil eine Proxy davor sitzen kann, ohne dass der Legacy-Code davon erfährt.
• An den Daten. Event Interception — die Schreibvorgänge abgreifen und nach außen spiegeln. Fowler merkt an, dass man beim Strangler Fig ohnehin eine Form davon einsetzt, ob man sie benannt hat oder nicht.
• Im Code. Branch by Abstraction: eine Schnittstelle über das einführen, was ersetzt werden soll, die Schnittstelle unverändert lassen und die Implementierung dahinter austauschen. Bei vielen Aufrufern der Versionierung der Schnittstelle vorzuziehen, weil es die Änderungsfläche verkleinert.

Wählen Sie die erste Nahtstelle nach Risiko, nicht nach Ehrgeiz. Der richtige Eröffnungszug ist eine Route mit hohem Volumen — damit Sie schnell lernen — und geringer Konsequenz, damit dieses Lernen billig ist. Reporting-Endpunkte und lesende Ansichten sind meist der richtige Anfang. Die Abrechnung nicht.

Der Strangler Fig, konkret

Die Metapher ist eine echte Pflanze: eine Würgefeige, die „germinate[s] in a nook of a tree… draws nutrients from the host tree until it reaches the ground to grow roots and the canopy to get sunlight.“ In Software heißt das: eine Fassade vor das alte System setzen und dann verschieben, was dahinter liegt — eine Route nach der anderen.

Der Einwand betrifft immer die Proxy: Code, der nur existiert, um gelöscht zu werden. Fowler antwortet direkt — „people often balk at the necessity of building transitional architecture… While this may appear to be a waste, the reduced risk and earlier value from the gradual approach outweigh its costs.“ Planen Sie die Übergangsarchitektur ausdrücklich ein. Ein Plan, der so tut, als sei sie umsonst, streicht sie stillschweigend — und sie zu streichen heißt, zum Big Bang zurückzukehren.

Ein durchgerechnetes Beispiel auf dieser Seite: der Tag, an dem wir die Karte abschalteten beschreibt eine landesweite Kartenplattform, die auf diese Weise über fünf Monate und drei Architekturgenerationen neu gebaut wurde — einschließlich des Teils, in dem das Kernfeature bewusst abgeschaltet statt weitergeschleppt wurde.

Expand und Contract: Daten migrieren ohne Wartungsfenster

Das Routing ist die einfache Hälfte. Am darunterliegenden Schema scheitern schrittweise Migrationen tatsächlich, denn eine Datenbankänderung gilt als das eine Deployment, das sich nicht zurücknehmen lässt. Parallel Change ist das Muster, das sie zurücknehmbar macht, und es hat drei benannte Phasen: Expand, Migrate, Contract.

Fowler benennt das Fehlerbild deutlich: „if the contract phase is not executed you might end up in a worse state than you started.“ Schritt fünf ist der, der in der Woche des Feature-Launchs zurückgestellt wird — und ihn zu überspringen hinterlässt zwei Spalten, beide beschrieben, keine maßgeblich, und ein Jahr später weiß niemand mehr, aus welcher die Berichte lesen. Parallel Change.

Schreiben Sie den Contract-Schritt in dasselbe Ticket wie den Expand-Schritt, mit eigenem Abnahmekriterium. Das ist die einzige verlässliche Absicherung gegen eine Migration, die für immer zu 80 % fertig ist.

Shadow Traffic: den neuen Pfad beweisen, bevor Sie ihm vertrauen

Sie haben nun eine Nahtstelle und ein Schema, das sich bewegen lässt. Was Sie nicht haben, ist die Gewissheit, dass die neue Implementierung der alten entspricht — denn die Spezifikation wurde nie aufgeschrieben. Shadow Traffic ist der Weg, sie zurückzugewinnen: jede reale Anfrage an beide Pfade schicken, die Nutzerin aus dem alten bedienen, die Antwort des neuen verwerfen und die Unterschiede protokollieren.

Das Mismatch-Log ist die Spezifikation, die Sie nie hatten. Die meisten Einträge sind trivial — Schlüsselreihenfolge, Rundung, Leerzeichen — und die filtern Sie heraus. Übrig bleibt der interessante Teil: die Fälle, in denen das alte System etwas Überraschendes tut, und der Moment, in dem Sie entscheiden müssen, ob es ein Fehler ist, den Sie beheben, oder ein Verhalten, auf das sich eine Kundin verlässt. Diese Entscheidung ist die eigentliche Arbeit einer Migration, und das Shadowing bringt sie ans Licht, bevor es eine Kundin tut.

• Der neue Pfad darf nicht schreiben. Eine Mutation zu shadowen führt sie zweimal aus. Beginnen Sie mit Lesevorgängen, und shadowen Sie Schreibvorgänge in ein Wegwerf-Schema.
• Kalkulieren Sie die doppelte Last ein. Sie betreiben das System doppelt. Ist das nicht tragbar, shadowen Sie einen Stichprobenanteil — wenige Prozent echten Verkehrs schlagen hundert Prozent synthetischen Verkehr.
• Schalten Sie nach Daten um, nicht nach Kalender. Das Signal zum Umschalten ist eine Abweichungsrate, die seit vierzehn Tagen langweilig ist — nicht das Quartalsende.

Verfolgen Sie die Übereinstimmung als Kennzahl auf einem Dashboard, neben Latenz und Fehlerrate: Anteil der geshadowten Anfragen, bei denen beide Pfade übereinstimmten, aufgeschlüsselt nach Endpunkt. Das macht aus einer Migration statt eines Gefühls eine Messgröße — und gibt Ihnen etwas, das Sie denjenigen zeigen können, die die Übergangsarchitektur finanzieren. Im siebten Monat werden Sie das brauchen.

Cutover per Feature-Flag, nicht per Wochenende

Wenn der Diff ruhig ist, sollte die Umschaltung selbst das undramatischste Ereignis des Projekts sein: ein Flag, das einen Prozentsatz des Verkehrs von einer Implementierung auf die andere verschiebt, dienstags um 10 Uhr umgelegt von jemandem, der es in zehn Sekunden zurückstellen kann.

1. Verschieben Sie zuerst interne Nutzer. Sie melden Probleme per Chatnachricht statt per Support-Ticket.
2. Dann einen Prozentsatz — 1, 5, 25, 50 — mit definierter Wartezeit je Stufe und einer benannten Person, die die Fehlerrate beobachtet.
3. Halten Sie den alten Pfad warm und erreichbar, solange das Rollback zählt — und das ist länger, als es sich anfühlt.
4. Löschen Sie ihn zu einem geplanten Termin, in einem Ticket, das bereits existiert. Das ist wieder die Contract-Phase, und sie wird aus denselben Gründen übersprungen.

Eine Regel lässt das alles funktionieren: Das Flag muss eine Laufzeiteinstellung sein, kein Deployment. Erfordert das Zurückrollen ein Release, dauert Ihr Rollback so lange wie Ihre Pipeline — und im Störfall ist das der Unterschied zwischen einem Ausschlag und einem Ausfall.

Wann ein Rewrite tatsächlich richtig ist

Die schrittweise Ablösung ist der Standardfall, keine Religion. Sie hat reale Kosten — Übergangsarchitektur, eine lange Phase mit zwei Systemen und einen Disziplinanspruch, den nicht jede Organisation durchhält. Manchmal ist ein Rewrite schlicht richtig.

Die Zeile, die am häufigsten entscheidet, ist die zweite auf der rechten Seite: ob die vollständige Spezifikation auf eine Seite passt. Kann jemand aufschreiben, was das System leisten muss, ohne den Quelltext zu lesen, ist ein Rewrite ein begrenztes Problem. Kann er es nicht — und bei allem, was seit einem Jahrzehnt in Produktion läuft, kann er es nicht —, dann ist der Rewrite kein Bauprojekt. Er ist ein Reverse-Engineering-Projekt mit angehängtem Bau, und der Zeitplan wurde nur für den Bau geschätzt.

Die ehrliche Lesart dieser Tabelle ist: Die meisten realen Systeme treffen auf beiden Seiten mehrere Zeilen. Wenn das so ist, lautet die entscheidende Frage nicht, welche Spalte länger ist. Sie lautet: Wenn sich der Ersatz als falsch erweist — wie lange dauert es, das herauszufinden, und was kostet es, das rückgängig zu machen? Schrittweise Ablösung ist keine bessere Architektur. Sie ist eine kürzere Rückkopplungsschleife, erkauft mit Übergangscode.

Wo Sie im nächsten Sprint anfangen

• Setzen Sie eine Fassade vor irgendetwas. Selbst wenn sie 100 % des Verkehrs direkt an das Altsystem durchreicht, haben Sie nun einen Standpunkt. Das ist eine Sprint-Aufgabe, und sie entsperrt alles Weitere.
• Wählen Sie eine Route mit hohem Volumen und geringer Konsequenz. Sie wollen schnell lernen und günstig falschliegen. Berichte vor Zahlungen, Lesen vor Schreiben.
• Shadowen Sie, bevor Sie vertrauen. Das Mismatch-Log bringt Ihnen in zwei Wochen mehr über Ihr eigenes System bei als jede Code-Archäologie.
• Schreiben Sie das Löschticket jetzt. Contract-Phasen finden nur statt, wenn sie geplant wurden, bevor alle müde waren. Geben Sie ihr Datum und Verantwortliche im selben Atemzug wie dem Bau.
• Machen Sie das Flag zur Laufzeiteinstellung. Ein Rollback, das ein Deployment braucht, ist kein Rollback. Das ist die günstigste Versicherung im gesamten Plan.

Keiner dieser Schritte ist für sich genommen beeindruckend. Genau darum geht es: Es gibt zu keinem Zeitpunkt einen Abend, an dem alles funktionieren muss.