Der gefährlichste Satz im Umgang mit eigener Software ist vielleicht: „Wir sollten das einfach neu schreiben.“ Er fällt über Systeme, die es verdient haben — fünfzehn Jahre alt, undokumentiert, zusammengehalten von den zwei Leuten, die noch wissen, warum das Rechnungsmodul sich so verhält. Er fällt aber auch über Systeme, die tragend sind: Aufträge, Lagerbestand, Abrechnung und Lohnbuchhaltung laufen jeden Tag durch sie hindurch, und das Geschäft steht still, wenn sie es tun. Das Rewrite-Versprechen verführt, weil es sauber ist. Ein neues System, diesmal richtig gebaut, und eines Tages legen Sie den Schalter um. Die Bilanz ist weniger sauber: Big-Bang-Rewrites funktionierender Systeme scheitern oft genug und teuer genug, dass der Satz als beweispflichtige Behauptung behandelt werden sollte, nicht als Plan.
Es gibt eine Alternative mit deutlich besserer Abschlussquote: schrittweiser Ersatz — das Strangler-Fig-Muster, benannt nach der Würgefeige, die um einen Wirtsbaum wächst, bis der Baum nichts mehr trägt. Das neue System wächst um das alte herum, übernimmt ein Modul nach dem anderen, und das alte System wird stillgelegt, wenn nichts mehr zu ihm routet. Das ist weniger dramatisch als ein Rewrite. Genau darum geht es.
Warum große Rewrites scheitern
Die Fehlermuster sind vorhersehbar genug, um Namen zu haben. Das erste ist der Second-System-Effekt: Das Team, das ein System neu baut, trägt jede Ambition in den Neubau, die das alte unterdrückt hat. Ein Projekt mit dem Umfang „was das alte System kann, auf einem modernen Stack“ wird still zu „was das alte System kann, plus das Reporting, das der Vertrieb sich immer gewünscht hat, plus eine Plugin-Architektur, plus Mandantenfähigkeit, falls wir sie je brauchen“. Der Umfang wächst ausgerechnet in dem Projekt, in dem er fest sein sollte, denn das alte System steht daneben als tägliche Erinnerung an alles, was es nie konnte.
Das zweite ist das eingefrorene Funktionsfenster. Ein Rewrite bleibt nur ein Rewrite, wenn das Ziel stillhält, also wird das alte System eingefroren, während das neue gebaut wird. Aber das Geschäft friert nicht ein. Achtzehn Monate sind eine lange Zeit, dem Vertrieb zu sagen, dass es nichts Neues gibt, und kaum ein Unternehmen hält diese Linie durch — also fließen die Änderungen doch in das alte System, der Rewrite jagt einem beweglichen Ziel hinterher, und die Lücke zwischen beiden wächst genau in dem Moment, in dem sie sich schließen sollte.
Das dritte sind die Daten, die niemand versteht. Ein System, das ein Geschäft ein Jahrzehnt lang getragen hat, wird nicht von seiner Dokumentation beschrieben, sondern von seinem Verhalten. Die seltsame Rundung in der Rabattberechnung, der Statuscode, den es für einen einzigen Kunden aus dem Jahr 2016 gibt, der nächtliche Job, der repariert, was die Tagschicht kaputt macht — nichts davon steht in einer Spezifikation, denn das alte System ist die Spezifikation. Ein Big-Bang-Rewrite entdeckt diese Anforderungen im denkbar schlechtesten Moment: nach der Umstellung, in Produktion, als Support-Tickets. Diese Entdeckung ist es meist, die das Projekt beerdigt.
Wie schrittweiser Ersatz tatsächlich aussieht
Das Strangler-Muster hat wenige bewegliche Teile. Zuerst kommt eine Fassade vor das alte System — eine Routing-Schicht, die jede Anfrage entgegennimmt und sie am ersten Tag vollständig durchreicht. Nichts ändert sich, außer dass Ihnen jetzt die Eingangstür gehört. Das ist der gesamte erste Meilenstein, und er ist mehr wert, als er aussieht: Von diesem Punkt an ist die Frage, wo ein Stück Funktionalität lebt, eine Routing-Entscheidung unter Ihrer Kontrolle, unsichtbar für die Menschen, die das System benutzen. Die Fassade kann ein API-Gateway sein, ein Reverse Proxy oder ein schlanker eigener Dienst — die Technologie ist weit weniger wichtig als die Tatsache, dass es sie gibt.
Dann schreitet der Ersatz Modul für Modul voran. Ein abgegrenztes Stück des Systems — etwa die Angebotserstellung — wird als neuer Dienst auf einem bewusst langweiligen Stack neu gebaut, denn eine Modernisierung ist der letzte Ort, an dem man sein Neuheitsbudget ausgeben sollte. Das neue Modul läuft parallel zum alten: Beide erhalten dieselben Eingaben, beide produzieren Ausgaben, und die Ausgaben werden verglichen. Die Antwort des alten Moduls ist die, die Kunden sehen; die Antwort des neuen Moduls ist ein Schatten, protokolliert und abgeglichen.
Die Umstellung erfolgt pro Modul, und erst, wenn die Zahlen übereinstimmen — nicht am Roadmap-Termin, nicht wenn die Demo gut aussieht, sondern wenn der Abgleichbericht lange genug sauber oder erklärbar unsauber war, um ihm zu vertrauen. Dann routet die Fassade die Angebotserstellung zum neuen Modul, das alte bleibt als Rückfallebene in Betrieb, und die Aufmerksamkeit wandert zum nächsten Modul. Jeder Schritt ist klein, gemessen und umkehrbar — genau das, was eine Big-Bang-Umstellung nicht ist.
Das alte System ist nicht der Feind. Es ist die Spezifikation, das Testorakel und die Rückfallebene — bis zu dem Tag, an dem nichts mehr zu ihm routet.
Wie man das erste Modul auswählt
Das erste Modul trägt einen unverhältnismäßig großen Anteil am Schicksal des Projekts, denn seine eigentliche Aufgabe ist, die Maschinerie zu beweisen — die Fassade, den Parallelbetrieb, den Abgleich, die Umstellung — an etwas, das das Unternehmen nicht versenken kann. Drei Filter leisten den Großteil der Arbeit. Geringe Kopplung: Wählen Sie etwas, das die wenigsten Tabellen und Aufrufe mit dem Rest des Systems teilt — Dokumentenerzeugung, Benachrichtigungen, ein Reporting-Fluss —, damit Sie nicht am ersten Tag den ganzen Knoten entwirren. Hoher Schmerz: Wählen Sie etwas, worüber sich Menschen aktiv beschweren, damit die erste Umstellung ein Ergebnis produziert, das jemand außerhalb des Projekts bemerkt. Oft ist der beste Kandidat der Workflow, den das Team bereits mit Exporten und manueller Neueingabe flickt — die Tabellen-Schicht um ein Legacy-System ist eine Landkarte der Schmerzpunkte. Messbar: Wählen Sie etwas, dessen Ergebnis sich mechanisch vergleichen lässt — erzeugte Dokumente, berechnete Summen, Antwortzeiten —, denn die gesamte Umstellungsdisziplin hängt davon ab, Zahlen zum Abgleichen zu haben.
Was das erste Modul nicht sein sollte: beeindruckend. Klein, lästig und zählbar schlägt groß und strategisch. Ein erstes Modul, das sechs Wochen braucht und sauber umgestellt wird, kauft mehr Glaubwürdigkeit als eines, das sechs Monate braucht und vielleicht. Die strategischen Module kommen später, wenn die Maschinerie den Kontakt mit der Produktion überlebt hat.
Das Datenproblem
Code ist die einfache Hälfte einer Modernisierung. Die schwere Hälfte sind die Daten, und das Leitprinzip ist unmissverständlich: Das alte System bleibt die Quelle der Wahrheit, bis das neue Modul für Modul das Gegenteil bewiesen hat. In der Praxis heißt das: Solange ein Modul im Schattenbetrieb läuft, fließen Daten in eine Richtung — von alt nach neu synchronisiert, per Change Data Capture, wenn die alte Datenbank es unterstützt, per nächtlichem Batch, wenn die Plattform nur das erlaubt. Das neue Modul liest seine synchronisierte Kopie, berechnet seine Antworten und schreibt nichts zurück, worauf sich irgendjemand verlässt.
Zwischen Schattenbetrieb und Umstellung liegt die Abgleichphase, und dort kommen die echten Anforderungen ans Licht. Beide Systeme verarbeiten die Arbeit desselben Tages; ein Diff-Job vergleicht die Ergebnisse; jede Abweichung wird untersucht. Die meisten Abweichungen sind Fälle, in denen das neue System auf eine Weise falsch liegt, die keine Spezifikation erfasst hätte — die undokumentierte Rundung, der Kunde mit Sonderbehandlung. Einzeln untersucht, im Schattenbetrieb, sind das günstige Lektionen. Dieselben Entdeckungen nach einer Big-Bang-Umstellung sind Ausfälle.
Manche Abweichungen zeigen in die andere Richtung: Das alte System lag falsch, und das Geschäft hat den Fehler jahrelang still absorbiert. Das sind Entscheidungen, keine Bugs — das alte Verhalten aus Kontinuitätsgründen bewahren, oder es korrigieren und die Betroffenen informieren? Beide Antworten können richtig sein; falsch ist nur, die Wahl aus Versehen zu treffen — was jeder Rewrite getan hat, der die beiden Systeme nie nebeneinander laufen ließ. Erst bei der Umstellung geht die Hoheit über die Daten des Moduls über — das neue System wird zum Schreibenden, und der Abgleichjob läuft danach noch eine Weile weiter, als Stolperdraht.
Wann ein Rewrite die richtige Entscheidung ist
Ehrlichkeit verlangt den Gegenfall, denn schrittweiser Ersatz ist nicht umsonst — Fassade, Synchronisierung und Parallelbetrieb kosten Aufwand, den ein sauberer Rewrite sich sparen würde. Dieser Mehraufwand ist eine Versicherung, und eine Versicherung lohnt sich nicht für jedes Haus. Wenn das System klein genug ist, dass ein fokussierter Ersatz in 2–3 Monaten live geht, kann die Koordinationsmaschinerie mehr kosten als das Risiko, das sie beseitigt. Wenn die Plattform wirklich tot ist — eine Laufzeitumgebung, für die niemand mehr zu finden ist, Hardware, die sich nicht ersetzen lässt, ein Hersteller, den es nicht mehr gibt —, bleibt womöglich nichts Stabiles übrig, das man umwachsen könnte. Und wenn das System wenige Nutzer hat, die einen harten Umstieg verkraften — ein internes Werkzeug für ein Team, zu dem man hinübergehen und reden kann —, ist Parallelbetrieb eine Vorsicht, die die Lage nicht verlangt.
Behalten Sie selbst dann zwei Gewohnheiten aus dem inkrementellen Spielbuch: Migrieren Sie die Daten vor dem Stichtag statt währenddessen, und lassen Sie alt und neu für eine Validierungsphase nebeneinander laufen, wenn es irgendeinen Weg dafür gibt. Die Entscheidung Rewrite oder Strangler bestimmt die Größe des Sicherheitsapparats — sie ändert nichts daran, ob Ergebnisse überprüft werden, bevor sich jemand auf sie verlässt.
Die politische Seite
Eine Modernisierung, die ein Jahr dauert, ist ein politisches Projekt, ganz gleich, mit welcher Architektur. Zwei parallel laufende Systeme bedeuten, für beide zu bezahlen, und irgendwann stellt ein vernünftiger Mensch die Frage, die jedes lange Projekt fürchtet: Wird das je fertig? Die am meisten unterschätzte Eigenschaft des Strangler-Musters ist, dass es seine eigene Antwort erzeugt. Weil der Ersatz pro Modul erfolgt, ist der Fortschritt zählbar — umgestellte Module, Anteil des Traffics auf dem neuen System, Vorfälle pro Umstellung. Das Projekt hat eine Anzeigetafel, keine Fertigstellungs-Prozentzahl, die ein Jahr lang bei achtzig stand.
Der Takt, der Vertrauen erhält, ist die wöchentliche Demo von etwas Echtem: keine Folien, sondern das neue Angebotsmodul, das die tatsächlichen Angebote dieser Woche neben denen des alten produziert, mit dem Abgleich auf dem Bildschirm. Stakeholder sehen die Abweichungen Woche für Woche schrumpfen, was mehr für das Vertrauen tut, als je ein Plan getan hat. Und Zusagen bleiben absichtlich klein: Versprechen Sie nie den Termin, an dem das alte System stirbt — versprechen Sie das nächste Modul, liefern Sie es, wiederholen Sie das. In diesem Takt führen wir Legacy-Modernisierungen durch, und er ist der Unterschied zwischen einer Modernisierung, an die das Unternehmen glaubt, und einer, die es bloß duldet.
Vom alten System wird meist als dem Problem gesprochen. Richtig behandelt, ist es das Gegenteil: eine vollständige, laufende Spezifikation dessen, was das Geschäft braucht, ein Testorakel, das jede Antwort des Ersatzes benotet, und eine Rückfallebene, die jeden Schritt umkehrbar macht. Der große Rewrite wirft diese Vermögenswerte weg und scheitert dann an ihrem Fehlen. Schrittweiser Ersatz gibt sie aus, gezielt, Modul für Modul — bis zu dem Tag, an dem jemand die Routing-Tabelle prüft, nichts mehr auf das alte System zeigen sieht und es abschaltet. Kein Drama. Genau das war der Sinn.