Strangler Fig: ablösen statt ersetzen
Kein Thema kommt in Erstgesprächen so oft vor wie dieses: Da läuft ein System seit zwölf Jahren, es verdient jeden Tag Geld, und niemand will hinein. Jede Änderung dauert länger als die davor. Der Plan, den fast alle schon einmal gefasst haben, lautet: neu bauen, dann umschalten.
Dieser Plan hat eine Erfolgsquote, die man nicht in eine Präsentation schreiben möchte. Nicht weil Teams zu schlecht wären, sondern weil er zwei Dinge gleichzeitig verlangt: das Alte weiterbetreiben und das Neue zu Ende bauen — mit denselben Leuten. Das Alte gewinnt immer, weil es das Geschäft ist.
Die Idee ist älter als die meisten Altsysteme
Strangler Fig beschreibt die Alternative: Du stellst dich nicht neben das Altsystem, sondern davor. Ein Einstiegspunkt — Reverse Proxy, Router, Fassade — nimmt allen Verkehr entgegen und entscheidet pro Pfad, wer antwortet: alt oder neu. Am Anfang antwortet zu hundert Prozent das Alte. Dann verschiebt sich der Anteil, Stück für Stück, über Monate.
Der entscheidende Unterschied zum Neubau ist nicht die Technik. Es ist, dass jeder einzelne Schritt für sich schon Wert liefert und für sich zurückgerollt werden kann. Du brauchst nie einen Stichtag, an dem alles gut gehen muss.
Der erste Schnitt geht an den Rand, nicht ins Herz
Der naheliegende Fehler ist, mit dem wichtigsten Teil anzufangen — der Bestellabwicklung, der Preisberechnung, dem Kern eben. Da sitzt schließlich der Schmerz.
Der erste Schnitt sollte drei Eigenschaften haben: klar abgrenzbar, fachlich langweilig, aber im echten Verkehr. Ein Bereich, den das Team versteht, an dem niemand hängt und der trotzdem Produktionslast sieht. Denn was du im ersten Schritt eigentlich baust, ist nicht das Feature. Es ist die Fassade, das Deployment, die Beobachtbarkeit, der Rollback-Weg. Diese Infrastruktur einmal an etwas Ungefährlichem durchzuspielen ist billiger, als sie beim Checkout zum ersten Mal zu benutzen.
Wenn der erste herausgelöste Bereich nach zwei Wochen produktiv läuft und niemand es gemerkt hat, hast du den Beweis, den das Vorhaben braucht — intern wie beim Auftraggeber.
Die Fassade ist die eigentliche Investition
An der Fassade entscheidet sich, ob die Ablösung trägt. Drei Dinge gehören hinein, bevor der erste echte Umzug stattfindet:
Routing pro Pfad, nicht pro System. Die Umschaltung muss so fein sein, dass ein einzelner Endpunkt zurückgedreht werden kann, ohne dass alles andere mitgeht.
Umschalten zur Laufzeit. Ein Deployment als Rollback-Mechanismus ist zu langsam. Die Entscheidung alt/neu gehört in Konfiguration, die ohne Release greift.
Beide Seiten messen. Latenz, Fehlerquote und — wo es geht — die Antworten selbst. Neu und alt eine Weile parallel laufen zu lassen und die Ergebnisse zu vergleichen, deckt genau die Sonderfälle auf, die in keiner Spezifikation stehen, aber seit acht Jahren produktiv bedient werden.
Daten sind die harte Grenze
Code lässt sich umleiten. Daten nicht. Solange alt und neu auf denselben Tabellen schreiben, ist die Trennung eine Behauptung.
Der pragmatische Weg: pro Tabelle einen Eigentümer festlegen. Wer sie besitzt, schreibt. Alle anderen lesen — über eine Schnittstelle, nicht über das Schema. Jede weiterhin geteilte Tabelle wird zur dokumentierten Schuld, mit Datum und Abbaukriterium. Das ist unbequem, aber es macht sichtbar, wie weit die Ablösung wirklich ist. Ein Fortschrittsbalken, der nur Endpunkte zählt und den Datenbesitz ignoriert, lügt zuverlässig.
Wer tiefer im fachlichen Schnitt steckt: Wie man die Grenzen dafür findet und festhält, steht in DDD einführen ohne Big Bang.
Woran es scheitert: der Rückbau
Das Muster ist technisch selten das Problem. Es scheitert an der Politik des letzten Drittels.
Die ersten Umzüge sind sichtbar und werden gefeiert. Irgendwann sind achtzig Prozent des Verkehrs auf dem neuen Weg, und der Rest ist unattraktiv: die Sonderfälle, der Batch, den einmal im Jahr jemand braucht, die Schnittstelle zu einem Partner, der nicht antwortet. Ab hier finanziert niemand mehr gern. Und dann läuft beides weiter. Dauerhaft. Zwei Systeme statt einem — teurer als der Zustand davor.
Zwei Dinge helfen dagegen, und beide sind organisatorisch, nicht technisch:
Erstens, der alte Pfad wird gelöscht, sobald der neue stabil ist. Nicht auskommentiert, nicht per Feature-Flag stillgelegt — gelöscht. Was noch da ist, wird benutzt.
Zweitens, das Abschaltdatum des Altsystems steht von Anfang an im Plan, und zwar mit derselben Verbindlichkeit wie ein Liefertermin. Es wird sich verschieben. Aber ein Datum, das sich verschiebt, erzeugt jedes Mal ein Gespräch. Kein Datum erzeugt nie eines.
Was du realistisch erwarten kannst
Eine Ablösung dieser Art ist kein Projekt mit Enddatum, sondern eine Betriebsart über ein bis zwei Jahre. Sie ist in Summe nicht billiger als ein Neubau — sie ist nur die Variante, bei der du an jedem einzelnen Tag ein funktionierendes Geschäft hast und jederzeit aufhören kannst, ohne alles zu verlieren.
Das ist der ganze Handel: Du tauschst die Aussicht auf einen großen sauberen Wurf gegen die Sicherheit, dass nichts umfällt. In einem System, das jeden Tag Umsatz macht, ist das kein schlechter Tausch.
Klingt nach deinem Thema? Schreib mir. Im Erstgespräch klären wir unverbindlich, ob und wie ich helfen kann.