Legacy-Modernisierung ohne Big Bang

Fast jedes Unternehmen, das lange genug Software betreibt, kommt an denselben Punkt: Ein System trägt das Geschäft, aber niemand ändert es mehr gern. Es ist unübersichtlich geworden, die Menschen, die es gebaut haben, sind weg, und jede Anpassung fühlt sich an wie ein Eingriff am offenen Herzen. Der naheliegende Wunsch ist, es einmal richtig neu zu bauen.

Dieser Wunsch ist der teuerste Fehler in der Softwaretechnik. Ein Altsystem ist kein Entwurf, den man sauber ersetzt — es ist der eingefrorene Zustand von Jahren an Entscheidungen, Sonderfällen und stillen Anforderungen, von denen die meisten nirgends aufgeschrieben stehen. Dieser Text handelt davon, wie man ein solches System ablöst, ohne den Big Bang: inkrementell, in kleinen umkehrbaren Schritten, mit dem alten System als Netz, bis das neue trägt.

Warum der große Rewrite scheitert

Der Big-Bang-Rewrite verspricht, alles auf einmal richtig zu machen: neues System bauen, alles migrieren, an einem Stichtag umschalten. Er scheitert aus drei strukturellen Gründen, nicht aus Unfähigkeit.

Erstens: Das Alte enthält Wissen, das niemand mehr hat. Die tausend kleinen Sonderfälle, die sich über Jahre angesammelt haben, sind Anforderungen — nur unsichtbar. Ein Neubau auf der grünen Wiese reproduziert sie nicht, er entdeckt sie in der Produktion, einen Ausfall nach dem anderen.

Zweitens: Während man neu baut, steht das Alte nicht still. Das Geschäft braucht weiter Änderungen. Entweder friert man die Entwicklung am Altsystem ein — dann verliert das Unternehmen für die Dauer des Umbaus die Fähigkeit, sich zu bewegen — oder man pflegt beide Systeme parallel und baut ein bewegliches Ziel nach.

Drittens: Der Stichtag bündelt das gesamte Risiko in einem einzigen Moment. Alles muss gleichzeitig funktionieren — Code, Daten, Integrationen, Betrieb. Fällt etwas aus, gibt es keinen Teil-Rückweg, nur ein Zurück auf null. Das ist das Gegenteil dessen, wie wir bauen: in kleinen, umkehrbaren Schritten.

Die Empfehlung folgt daraus: Lösen Sie das Risiko in kleine, einzeln beherrschbare Stücke auf, statt es auf einen Termin zu konzentrieren. Der Preis ist, dass die Ablösung länger dauert und über die ganze Zeit zwei Systeme koexistieren müssen — mehr Betriebsaufwand, eine temporäre Nahtstelle, die man selbst pflegt. Anders entscheiden wir nur, wenn das System klein genug ist, um es in wenigen Wochen vollständig und mit einem echten Testnetz nachzubauen — dann kann ein sauberer Neubau günstiger sein als die Nahtstelle.

Was „Legacy" wirklich bedeutet

Legacy heißt nicht „alt". Ein zwanzig Jahre altes System, das verstanden, getestet und gepflegt ist, ist kein Legacy-Problem — es ist ausgereifte Technik. Legacy ist ein System, das das Geschäft trägt, in Produktion läuft und schlecht verstanden ist. Der Wert steckt in „trägt das Geschäft"; das Risiko steckt in „schlecht verstanden".

Diese Unterscheidung bestimmt die ganze Strategie. Das Ziel der Modernisierung ist nicht, alten Code durch neuen zu ersetzen. Das Ziel ist, Verständnis und Änderbarkeit zurückzugewinnen, ohne den Wert zu zerstören, der im Bestehenden steckt. Wer das vergisst, optimiert auf neue Technik und riskiert genau das eine, was das System wertvoll macht: dass es funktioniert.

Das Prinzip: verstehen, einhegen, ersetzen

Die inkrementelle Ablösung folgt immer derselben Ordnung. Erst verstehen, was ein Teil tut — beobachtbar, nicht vermutet. Dann einhegen: eine Naht zwischen alt und neu legen, hinter der man arbeiten kann, ohne den Rest zu berühren. Dann ersetzen, Stück für Stück, und jedes ersetzte Stück sofort in Betrieb nehmen.

Der Kern ist Umkehrbarkeit. Jeder Schritt ist so geschnitten, dass er einzeln ausgeliefert und einzeln zurückgenommen werden kann. Man wettet nie das ganze System auf eine Änderung; man verschiebt eine dünne Scheibe, prüft, ob sie hält, und geht zur nächsten. Geht eine Scheibe schief, ist der Schaden auf diese Scheibe begrenzt — nicht auf den Stichtag.

Der Strangler-Fig-Ansatz

Das tragende Muster heißt Strangler Fig, nach der Würgefeige, die einen Baum umwächst und ihn schließlich ersetzt, während er die ganze Zeit steht. Man setzt eine Fassade vor das Altsystem — den Punkt, an dem alle Anfragen ankommen. Anfangs reicht die Fassade alles unverändert ans Alte durch. Dann verlegt man eine fachliche Scheibe nach der anderen ins neue System und lässt die Fassade genau diese Scheiben umleiten. Das Alte schrumpft, das Neue wächst, und zu keinem Zeitpunkt steht das System still.

Schema: Die Fassade ist der einzige feste Punkt; hinter ihr wandert das System.

Die Empfehlung: Führen Sie zuerst die Fassade ein und liefern Sie sie im Durchreich-Modus aus, bevor Sie irgendetwas ersetzen. So trennen Sie das Risiko der Naht vom Risiko der Migration. Der Preis ist eine zusätzliche Schicht, durch die jede Anfrage läuft — etwas Latenz, ein Stück Infrastruktur, das man betreiben und absichern muss, und die Disziplin, dass keine neue Funktion am Altsystem vorbei direkt angebunden wird. Anders entscheiden wir, wenn das System keine klare Eintrittsstelle hat, an der sich eine Fassade legen lässt — etwa eine dicke Desktop-Anwendung ohne Dienstgrenze; dort muss die Naht erst durch eine Schnittstelle geschaffen werden, bevor die Ablösung beginnen kann.

Die Nahtstelle: Fassade und Anti-Corruption Layer

Die Naht hat zwei Aufgaben. Als Fassade entscheidet sie, welche Anfrage ans Alte und welche ans Neue geht. Als Anti-Corruption Layer übersetzt sie zwischen der alten und der neuen Welt, damit die Begriffe und Fehler des Altsystems nicht in die neue Domäne durchsickern. Ohne diese Übersetzung erbt das neue System die Modellfehler des alten — und man hat viel Arbeit investiert, um dieselben Probleme neu zu verpacken.

Die Empfehlung: Halten Sie die neue Domäne unabhängig vom alten Modell; alles, was aus dem Altsystem kommt, wird an der Naht in die Sprache der neuen Domäne übersetzt. Der Preis ist Übersetzungscode, der doppelt aussieht und den man pflegen muss, solange beide Welten koexistieren. Anders entscheiden wir, wenn das alte Modell nachweislich sauber ist und weiterleben soll — dann ist die Übersetzung überflüssige Reibung, und man übernimmt das Modell bewusst, statt es zu kapseln.

Daten sind das eigentliche Problem

Code lässt sich Scheibe für Scheibe verschieben. Daten nicht so leicht: Sie sind gemeinsam, sie sind groß, und die Datenbank überlebt jede Anwendungsschicht über ihr. Der schwierigste Teil jeder Modernisierung ist fast nie der Code — es ist, die Daten zu bewegen, ohne sie zu verlieren und ohne das System anzuhalten.

Das Werkzeug dafür ist die schrittweise, umkehrbare Schemaänderung — Expand, Migrate, Contract. Zuerst erweitern: das neue Schema additiv neben das alte legen, ohne etwas zu entfernen. Dann übergehen: neu und alt eine Zeit lang parallel schreiben (Dual-Write), Bestandsdaten im Hintergrund nachfüllen, lesend nach und nach auf das Neue umstellen. Erst wenn nichts mehr das Alte liest, zusammenziehen: das alte Feld entfernen. Jede einzelne Änderung ist für sich rückwärtskompatibel und damit umkehrbar.

Schema: Kein Feld wird geändert; es wird hinzugefügt, gefüllt, dann das alte entfernt.

Die Empfehlung: Migrieren Sie Daten früh und parallel, nicht als letzten Schritt vor dem Stichtag. Der Preis ist eine Phase des Doppelschreibens, in der zwei Quellen konsistent gehalten werden müssen, plus der Aufwand, Bestandsdaten nachzufüllen und die Gleichheit beider Seiten zu prüfen. Anders entscheiden wir bei kleinen, unkritischen Datenmengen mit akzeptablem Wartungsfenster — dort ist eine einmalige Migration im Fenster einfacher als die dauerhafte Doppelschreib-Maschinerie.

Branch by Abstraction und Parallelbetrieb

Nicht jeder Teil sitzt bequem hinter der Fassade. Ein tief im System verdrahteter Baustein — eine Berechnung, ein Zugriff auf einen externen Dienst — lässt sich mit Branch by Abstraction ablösen: Man legt eine Abstraktion über die alte Implementierung, schreibt hinter derselben Abstraktion die neue, schaltet über einen Schalter um und entfernt am Ende die alte. Der Umbau geschieht im laufenden Code, ohne langlebigen Seitenzweig.

Vor dem Umschalten kommt der Parallelbetrieb: neue und alte Implementierung eine Zeit lang gemeinsam laufen lassen, beide Ergebnisse vergleichen, aber weiterhin nur das alte als verbindlich behandeln. Erst wenn die neue über echten Verkehr hinweg dasselbe liefert, wird umgeschaltet. So wird die Korrektheit an der Produktion bewiesen, bevor sie Verantwortung übernimmt — und nicht danach.

Die Empfehlung: Beweisen Sie die neue Implementierung im Parallelbetrieb gegen echten Verkehr, bevor sie verbindlich wird. Der Preis ist doppelte Ausführung für die Dauer des Vergleichs — mehr Last, mehr Instrumentierung, und der Umgang mit Abweichungen, die oft vergessene Sonderfälle aufdecken. Anders entscheiden wir, wo die doppelte Ausführung Nebenwirkungen hätte, die sich nicht gefahrlos doppeln lassen — etwa Zahlungen oder Versand; dort prüft man gegen aufgezeichneten Verkehr in einer Schattenumgebung statt live.

Reihenfolge: das Riskanteste zuerst, in dünnen Scheiben

Womit anfangen? Nicht mit dem Einfachsten, um schnell etwas vorzuzeigen, und nicht mit dem Größten, um es hinter sich zu bringen. Zuerst kommt der riskanteste, am wenigsten verstandene Pfad — aber als dünnstmögliche Scheibe, die End-to-End durch die Naht läuft. So räumt man das größte Unbekannte am Anfang aus, wenn Ändern noch günstig ist, statt es am Ende zu entdecken.

Eine gute erste Scheibe ist fachlich abgeschlossen, klein und echt in Betrieb. Sie beweist die ganze Kette — Fassade, neue Domäne, Daten, Betrieb — an einem realen, aber begrenzten Fall. Was sie über die Naht und die Datenwege lehrt, trägt jede folgende Scheibe.

Die Empfehlung: Schneiden Sie die Arbeit nach fachlichen Fähigkeiten, nicht nach technischen Schichten, und beginnen Sie mit der riskantesten dünnen Scheibe. Der Preis ist, dass die erste Scheibe unverhältnismäßig teuer wirkt, weil sie die gesamte Nahtstelle mit aufbaut, bevor sichtbarer Fortschritt entsteht. Anders entscheiden wir, wenn ein Teil unter akutem Druck steht — ein Sicherheitsrisiko, ein Datenschutzproblem, ein Baustein, der ständig ausfällt; dann zieht dieser Teil unabhängig vom Risikoprofil nach vorn.

Charakterisierungstests: das Netz vor dem Umbau

Man kann nicht sicher ändern, was man nicht beobachten kann. Bevor eine Scheibe umzieht, hält man das aktuelle Verhalten des Altsystems in Charakterisierungstests fest — Tests, die nicht beschreiben, was das System tun sollte, sondern was es tut, samt seiner Eigenheiten. Sie sind das Netz: Weicht das neue Verhalten ab, schlagen sie an, bevor es die Produktion tut.

Der entscheidende Punkt ist Reihenfolge und Trennung. Erst wird das Verhalten unter das Netz gestellt, dann umgezogen, und während des Umzugs wird das Verhalten nicht zugleich verbessert. Eine Modernisierung, die gleichzeitig neue Funktionen einbaut, kann Abweichungen nicht mehr deuten — jeder Unterschied könnte Absicht oder Fehler sein.

Die Empfehlung: Schreiben Sie Charakterisierungstests vor dem Umbau und halten Sie Migration und Funktionsänderung strikt getrennt. Der Preis ist, dass man Tests für Verhalten schreibt, das man ohnehin ersetzen will, und dass gewünschte Verbesserungen warten müssen, bis der Umzug steht. Anders entscheiden wir dort, wo das alte Verhalten nachweislich falsch ist und niemand sich darauf verlässt — dann friert man den Fehler nicht im Test ein, sondern korrigiert ihn bewusst und dokumentiert die Abweichung.

Beobachtbarkeit und Rückfahrkarte

Inkrementelle Ablösung lebt von zwei Dingen im Betrieb: Man muss sehen, was passiert, und man muss zurückkönnen. Jede Scheibe geht hinter einem Schalter live, mit Beobachtbarkeit von der ersten Minute — alte und neue Wege liefern vergleichbare Signale, sodass eine Abweichung sofort sichtbar ist. Der alte Pfad bleibt betriebsbereit, bis die neue Scheibe über genug echten Verkehr Vertrauen aufgebaut hat.

Die Empfehlung: Legen Sie jede Scheibe hinter einen Schalter, mit dem sich in Sekunden auf den alten Pfad zurückschalten lässt, und lassen Sie den alten Pfad, bis das Vertrauen steht. Der Preis ist, dass beide Wege eine Weile lauffähig bleiben müssen — doppelter Code, doppelter Betrieb, und die Pflicht, den alten Pfad am Ende wirklich zu entfernen, statt ihn schleichend zum Dauerzustand werden zu lassen. Anders entscheiden wir bei einer Scheibe ohne nennenswertes Risiko, deren Rückweg teurer ist als ihr möglicher Schaden — dort schaltet man direkt um und spart sich den doppelten Pfad.

Wann ein Rewrite doch richtig ist

Die ehrliche Antwort gehört zur Beratung, auch wenn sie gegen die eigene Methode spricht. Es gibt Fälle, in denen der inkrementelle Weg der falsche ist. Wenn die Plattform selbst tot ist — eine Laufzeit ohne Sicherheitsupdates, für die es keine Leute und keine Zukunft mehr gibt — hilft kein Umbau im Bestand. Wenn die fachliche Aufgabe sich so grundlegend geändert hat, dass das alte Modell nicht mehr die richtige Frage beantwortet, migriert man kein falsches Modell, sondern baut das richtige. Und wenn das System klein genug ist, um es mit einem echten Testnetz in kurzer Zeit vollständig nachzubauen, kann der Neubau günstiger sein als die Nahtstelle, die die Ablösung braucht.

Der gemeinsame Nenner: Ein Rewrite ist dann richtig, wenn das Risiko klein und beherrschbar ist — nicht, wenn der Frust über das Alte groß ist. Die Frage ist nie „Wollen wir es neu?", sondern „Können wir für den Neubau dieselbe Verantwortung übernehmen wie für den Bestand?". Wo die Antwort nein ist, gilt der inkrementelle Weg.

Häufige Fehler

Die immer gleichen Muster machen Modernisierungen teuer oder gefährlich:

• Der Big-Bang-Stichtag, der das gesamte Risiko in einen Moment ohne Teil-Rückweg bündelt.
• Der Rewrite auf der grünen Wiese, der die unsichtbaren Anforderungen des Alten in der Produktion wiederentdeckt.
• Der Feature-Freeze über die ganze Umbauzeit, der dem Geschäft die Beweglichkeit nimmt und Druck aufbaut, der die Sorgfalt frisst.
• Migration und neue Funktionen gleichzeitig, sodass sich Abweichungen nicht mehr deuten lassen.
• Die Daten zuletzt, statt früh und parallel — der Teil, der am wahrscheinlichsten kippt.
• Keine Naht: neue Funktionen werden direkt ans Altsystem gehängt und verlängern genau das, was man ablösen wollte.
• Der alte Pfad, der nach dem Umschalten „vorläufig" bleibt und zum dauerhaften zweiten System wird.

Checkliste

Fragen, die eine CTO an ein Modernisierungsvorhaben stellen kann. Es sind Diagnosefragen, keine Urteile.

• Gibt es eine Naht — eine Stelle, an der wir alt und neu trennen können? Ohne Naht gibt es keine inkrementelle Ablösung.
• Ist das aktuelle Verhalten unter einem Testnetz, bevor wir es anfassen? Was man nicht beobachten kann, kann man nicht sicher ändern.
• Ist jede Scheibe einzeln auslieferbar und einzeln zurücknehmbar? Sonst ist es ein Big Bang in Raten.
• Migrieren wir Daten früh und rückwärtskompatibel, oder heben wir sie uns für den Schluss auf? Daten kippen zuletzt und am teuersten.
• Trennen wir Migration und Funktionsänderung sauber? Beides zugleich macht Abweichungen unlesbar.
• Bleibt der alte Pfad betriebsbereit, bis das Vertrauen steht — und gibt es einen Plan, ihn danach zu entfernen? Ein Rückweg, den man nie schließt, wird zum zweiten System.
• Beginnen wir mit dem Riskantesten in dünner Scheibe, statt mit dem Sichtbarsten? Risiko gehört an den Anfang.
• Könnten wir für einen Neubau dieselbe Verantwortung übernehmen wie für den Bestand? Wenn nein, ist der inkrementelle Weg richtig.

FAQ

Dauert der inkrementelle Weg nicht länger als ein Rewrite? Bis zur ersten sichtbaren Scheibe oft ja, weil die Naht mit aufgebaut wird. Über das ganze Vorhaben meist nein — und vor allem trägt das Geschäft die ganze Zeit weiter. Der Rewrite wirkt nur schneller, weil sein Risiko unsichtbar bleibt, bis der Stichtag es einlöst.

Ist eine zusätzliche Fassade nicht selbst neue Komplexität? Ja, und sie ist vorübergehend. Die Fassade ist der Preis der Umkehrbarkeit: Sie erlaubt, Scheibe für Scheibe zu verschieben, ohne den Rest zu berühren. Sie wird entfernt, wenn das Alte stillgelegt ist. Bleibt sie dauerhaft ohne Zweck, war sie an der falschen Stelle.

Was, wenn niemand mehr weiß, was das Altsystem eigentlich tut? Dann ist das Verstehen der erste Schritt, nicht das Bauen. Charakterisierungstests und Beobachtbarkeit machen das tatsächliche Verhalten sichtbar, bevor es umzieht. Man deckt das Wissen auf, statt es zu erraten — genau der Schritt, den der Big-Bang-Rewrite überspringt.

Können wir während der Modernisierung neue Funktionen liefern? Ja — das ist einer der Hauptgründe für den inkrementellen Weg. Aber nicht in derselben Scheibe wie ein Umzug. Neue Funktionen entstehen im neuen System hinter der Naht; Umzug und Funktionsänderung bleiben getrennt, damit Abweichungen deutbar bleiben.

Woran erkennen wir, dass wir fertig sind? Wenn nichts mehr durch die Fassade ans Altsystem geht, keine Quelle mehr das alte Datenschema liest und der alte Pfad entfernt ist. Fertig ist nicht der letzte neue Code, sondern der Moment, in dem das Alte abgeschaltet werden kann, ohne dass es jemand merkt.

Womit fängt man an — welche Scheibe zuerst? Mit der riskantesten in einer möglichst dünnen Form. Das Riskante zuerst zu verschieben, deckt die harten Probleme auf, solange das Vorhaben noch jung ist und man umkehren kann — nicht am Ende, wenn alles davon abhängt. Dünn bleibt die Scheibe, damit ein Fehlschlag billig ist. Das Riskante spät und dick zu verschieben, ist der häufigste Weg, den inkrementellen Vorteil zu verspielen.

Weiterführend

• Software, die in zehn Jahren noch läuft — die Grundlage: was Systeme langlebig und änderbar hält.
• Legacy-Monolith modernisieren — das Playbook zum konkreten Vorgehen.
• Modularer Monolith und Modularer Monolith vs. Microservices — wohin man ablöst, und warum meist nicht in verteilte Dienste.
• Laravel oder Symfony als Beispiel einer tragenden Technikwahl beim Neubau der Scheiben.

Grundlage ist die Batunet Engineering Method: verstehen, entscheiden, beweisen, bauen, härten, betreiben — in kleinen, umkehrbaren Schritten.

Eine gelungene Modernisierung sieht man nicht. Es gibt keinen Stichtag, kein Bangen, keine Nacht, in der alles auf dem Spiel steht. Irgendwann läuft das Neue, das Alte ist aus, und niemand kann den Moment benennen, in dem es passiert ist.