Der gefährlichste Satz im Umgang mit der eigenen Software lautet vermutlich: „Das schreiben wir einfach neu.“ Er fällt über Systeme, die es verdient haben: 15 Jahre alt, undokumentiert, zusammengehalten von den zwei Leuten, die noch wissen, warum das Rechnungsmodul sich so verhält. Er fällt genauso über Systeme, die tragend sind - Aufträge, Bestände, Abrechnung und Lohnbuchhaltung laufen jeden Tag durch sie hindurch, und wenn sie stehen, steht der Betrieb. Das Versprechen der Neuentwicklung verführt, weil es so sauber klingt: ein neues System, diesmal richtig gemacht, und eines Tages legen Sie den Schalter um. Die Bilanz ist weniger sauber. Big-Bang-Rewrites laufender Systeme scheitern oft genug und teuer genug, dass man den Satz als beweispflichtige Behauptung behandeln sollte und nicht als Plan.
Es gibt eine Alternative mit deutlich besserer Abschlussquote: den schrittweisen Ersatz nach dem 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 wird stillgelegt, sobald nichts mehr zu ihm routet. Weniger dramatisch als ein Rewrite. Genau darum geht es.
Warum große Rewrites scheitern
Die Fehlermuster sind so vorhersehbar, dass sie Namen haben. Das erste ist der Second-System-Effekt: Das Team, das ein System neu aufsetzt, nimmt jede Ambition mit hinein, die das alte unterdrückt hat. Aus dem Auftrag „was das alte System kann, auf einem modernen Stack“ wird still und leise „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, weil das alte System daneben steht und täglich an alles erinnert, was es nie konnte.
Das zweite ist das eingefrorene Funktionsfenster. Ein Rewrite bleibt nur dann ein Rewrite, wenn das Ziel stillhält; also wird das alte System eingefroren, solange das neue entsteht. Das Geschäft friert allerdings nicht mit ein. 18 Monate sind eine lange Zeit, um dem Vertrieb zu sagen, dass es nichts Neues gibt, und kaum ein Unternehmen hält diese Linie durch. Die Änderungen wandern also doch in das alte System, der Rewrite jagt einem beweglichen Ziel hinterher, und der Abstand zwischen beiden wächst genau in dem Moment, in dem er schrumpfen sollte.
Das dritte sind die Daten, die niemand mehr versteht. Ein System, das ein Unternehmen ein Jahrzehnt lang getragen hat, wird nicht durch seine Dokumentation beschrieben, sondern durch sein Verhalten. Die eigenwillige Rundung in der Rabattberechnung, der Statuscode, den es nur für einen einzigen Kunden aus dem Jahr 2016 gibt, der nächtliche Job, der repariert, was die Tagschicht zerschießt: Nichts davon steht in einer Spezifikation, denn das alte System ist die Spezifikation. Ein Big-Bang-Rewrite findet diese Anforderungen im denkbar schlechtesten Moment, nämlich nach der Umstellung, in Produktion, als Support-Tickets. An dieser Entdeckung scheitert das Projekt dann meistens.
Wie der schrittweise Ersatz in der Praxis abläuft
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 ausnahmslos durchreicht. Es ändert sich nichts, außer dass Ihnen nun die Eingangstür gehört. Das ist der gesamte erste Meilenstein, und er ist mehr wert, als er aussieht: Von hier an ist die Frage, wo eine Funktion läuft, eine Routing-Entscheidung unter Ihrer Kontrolle, für die Anwender unsichtbar. Die Fassade kann ein API-Gateway sein, ein Reverse Proxy oder ein schlanker eigener Dienst; die Technologie zählt weit weniger als die Tatsache, dass es sie gibt.
Danach schreitet der Ersatz Modul für Modul voran. Ein abgegrenztes Stück des Systems, etwa die Angebotserstellung, entsteht neu als eigener Dienst auf einem bewusst langweiligen Stack, denn eine Modernisierung ist der letzte Ort, an dem man sein Neuheitsbudget ausgeben sollte. Das neue Modul läuft parallel zum alten: Beide bekommen dieselben Eingaben, beide erzeugen Ergebnisse, und die Ergebnisse werden verglichen. Was das alte Modul ausgibt, sehen die Kunden; was das neue ausgibt, läuft im Schatten mit, wird protokolliert und abgeglichen.
Die Umstellung erfolgt pro Modul und erst dann, wenn die Zahlen übereinstimmen. Nicht zum Roadmap-Termin, nicht wenn die Demo gut aussieht, sondern wenn der Abgleichbericht lange genug sauber oder erklärbar unsauber war, um ihm zu trauen. Dann routet die Fassade die Angebotserstellung auf das neue Modul, das alte bleibt als Rückfallebene in Betrieb, und die Aufmerksamkeit wandert zum nächsten Modul. Jeder Schritt bleibt klein, messbar und umkehrbar - alles drei, was eine Big-Bang-Umstellung nicht ist.
Das alte System ist nicht der Gegner. Es ist Spezifikation, Testorakel und Rückfallebene, bis zu dem Tag, an dem nichts mehr zu ihm routet.
Welches Modul kommt zuerst?
Das erste Modul trägt einen unverhältnismäßig großen Teil des Projektschicksals, weil seine eigentliche Aufgabe darin besteht, die Maschinerie zu beweisen - Fassade, Parallelbetrieb, Abgleich und Umstellung -, und zwar an etwas, das das Unternehmen nicht versenken kann. Drei Filter leisten den Großteil der Arbeit. Geringe Kopplung: Wählen Sie etwas, das möglichst wenige Tabellen und Aufrufe mit dem Rest des Systems teilt, also Dokumentenerzeugung, Benachrichtigungen oder einen Reporting-Ablauf, damit Sie nicht am ersten Tag den ganzen Knoten entwirren müssen. Hoher Leidensdruck: Wählen Sie etwas, worüber sich Menschen aktiv beschweren, damit die erste Umstellung ein Ergebnis bringt, das jemand außerhalb des Projekts bemerkt. Oft ist der beste Kandidat der Ablauf, den das Team ohnehin mit Exporten und doppelter Erfassung flickt; die Tabellen-Schicht rund um ein Legacy-System ist eine Landkarte seiner wunden Punkte. Messbar: Wählen Sie etwas, dessen Ergebnis sich maschinell vergleichen lässt, also erzeugte Dokumente, berechnete Summen oder Antwortzeiten, denn die gesamte Umstellungsdisziplin hängt daran, dass es Zahlen zum Abgleichen gibt.
Was das erste Modul nicht sein muss: beeindruckend. Klein, lästig und zählbar schlägt groß und strategisch. Ein Modul, das nach 6 Wochen sauber umgestellt ist, schafft mehr Vertrauen als eines, das 6 Monate braucht und vielleicht funktioniert. Die strategischen Module kommen später, wenn die Maschinerie den Kontakt mit der Produktion überstanden hat.
Das Datenproblem
Code ist die einfache Hälfte einer Modernisierung. Die schwere Hälfte sind die Daten, und das Leitprinzip dafür 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, dass die Daten nur in eine Richtung fließen, solange ein Modul im Schattenbetrieb läuft - von alt nach neu, per Change Data Capture, wenn die alte Datenbank das hergibt, per nächtlichem Batch, wenn die Plattform nur das zulässt. Das neue Modul liest seine synchronisierte Kopie, berechnet seine Antworten und schreibt nichts zurück, worauf sich jemand 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, und jede Abweichung wird untersucht. Meistens liegt das neue System falsch, und zwar auf eine Weise, 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 Unternehmen hat den Fehler jahrelang still mitgetragen. Das sind Entscheidungen und keine Bugs. Bewahren Sie das alte Verhalten, weil die Kontinuität schwerer wiegt, oder korrigieren Sie es und informieren die Betroffenen? Beide Antworten können richtig sein; falsch ist nur, die Wahl versehentlich zu treffen, und genau das tut jeder Rewrite, 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 als Stolperdraht weiter.
Wann ein Rewrite die richtige Entscheidung ist
Ehrlich bleibt die Sache nur mit dem Gegenfall, denn der schrittweise Ersatz ist nicht umsonst zu haben: Fassade, Synchronisierung und Parallelbetrieb kosten Aufwand, den ein sauberer Rewrite spart. Dieser Mehraufwand ist eine Versicherung, und nicht jedes Haus muss man versichern. Ist das System klein genug, dass ein fokussierter Ersatz in 2-3 Monaten live geht, kann die Koordinationsmaschinerie mehr kosten als das Risiko, das sie beseitigt. Ist die Plattform wirklich tot, weil sich für die Laufzeitumgebung niemand mehr einstellen lässt, die Hardware sich nicht ersetzen lässt oder es den Hersteller nicht mehr gibt, bleibt womöglich nichts Stabiles übrig, an dem das Neue wachsen könnte. Und hat das System wenige Nutzer, die einen harten Umstieg verkraften, etwa ein internes Werkzeug für ein Team, zu dem man hinübergehen und reden kann, dann verlangt die Lage keinen Parallelbetrieb.
Zwei Gewohnheiten aus dem schrittweisen Vorgehen sollten Sie trotzdem behalten: Migrieren Sie die Daten vor dem Stichtag statt an ihm, und lassen Sie Alt und Neu für eine Validierungsphase nebeneinander laufen, wo immer sich das einrichten lässt. Die Entscheidung zwischen Rewrite und Strangler bestimmt die Größe des Sicherheitsapparats. Ob Ergebnisse überprüft werden, bevor sich jemand auf sie verlässt, steht dagegen gar nicht zur Wahl.
Die politische Seite
Eine Modernisierung, die ein Jahr dauert, ist ein politisches Projekt, ganz gleich, mit welcher Architektur sie arbeitet. Zwei parallel laufende Systeme bedeuten, 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 die Antwort selbst erzeugt. Weil der Ersatz pro Modul erfolgt, lässt sich der Fortschritt zählen: umgestellte Module, Anteil der Anfragen, die das neue System bedient, Vorfälle je Umstellung. Das Projekt bekommt eine zählbare Bilanz statt einer Fertigstellungsquote, die ein Jahr lang bei 80 % steht.
Den Takt hält die wöchentliche Demo an etwas Echtem: keine Folien, sondern das neue Angebotsmodul, das die tatsächlichen Angebote dieser Woche neben denen des alten erzeugt, mit dem Abgleich auf dem Bildschirm. Die Beteiligten sehen die Abweichungen Woche für Woche schrumpfen, und das schafft mehr Vertrauen, als ein Plan es je geschafft hat. Die Zusagen bleiben dabei absichtlich klein: Versprechen Sie nie den Termin, an dem das alte System abgeschaltet wird, sondern das nächste Modul, liefern Sie es und wiederholen Sie das. In diesem Takt führen wir Legacy-Modernisierungen durch, und er entscheidet darüber, ob ein Unternehmen an seine Modernisierung glaubt oder sie nur duldet.
Vom alten System wird meist als dem Problem gesprochen. Richtig behandelt, ist es das Gegenteil: eine vollständige, laufende Spezifikation dessen, was der Betrieb braucht, ein Testorakel, das jede Antwort des Nachfolgers benotet, und eine Rückfallebene, die jeden Schritt umkehrbar macht. Der große Rewrite wirft diese drei Werte weg und scheitert anschließend daran, dass sie fehlen. Der schrittweise Ersatz setzt sie gezielt ein, Modul für Modul, bis jemand die Routing-Tabelle prüft, nichts mehr auf das alte System zeigt und es abschaltet. Kein Drama. Genau das war der Sinn.