Jedes gewachsene Unternehmen hat es: das eine System, das keiner mehr anfassen will. Die Warenwirtschaft von 2011, das ERP mit den 400 undokumentierten Sonderfällen, die Access-Datenbank, an der drei Abteilungen hängen. Irgendwann fällt der Satz „Wir bauen das neu" — und genau dort beginnen die meisten Modernisierungsprojekte zu scheitern.
Warum Big-Bang-Rewrites scheitern
Der komplette Neubau klingt sauber, hat aber eine eingebaute Falle: Bis das neue System alles kann, was das alte konnte, liefert es nichts. Das Altsystem entwickelt sich währenddessen weiter, weil das Geschäft nicht wartet — das Rewrite-Team jagt also ein bewegliches Ziel. Dazu kommt, dass die 400 Sonderfälle nicht in der Dokumentation stehen, sondern im Code und in den Köpfen. Sie tauchen erst auf, wenn die Buchhaltung im neuen System einen Monatsabschluss versucht. Typisches Ergebnis: 18 Monate Entwicklung, kein Go-live, und am Ende laufen beide Systeme halb.
Das Prinzip: Fassade davor, dann Stück für Stück ersetzen
Das Strangler-Pattern — benannt nach der Würgefeige, die einen Baum umwächst, bis sie ihn ersetzt hat — dreht die Logik um. Vor das Altsystem kommt eine Fassade: ein Proxy oder Gateway, durch das ab sofort jeder Zugriff läuft. Anfangs leitet die Fassade schlicht alles ans Altsystem weiter, nichts ändert sich. Dann wird ein einzelner Bereich neu gebaut — etwa die Angebotserstellung — und die Fassade routet nur diese Anfragen auf den neuen Dienst. Der Rest läuft unverändert alt. Bereich für Bereich wandert so die Funktionalität hinüber, bis das Altsystem leer ist und abgeschaltet werden kann.
Der entscheidende Unterschied: Beim Big Bang gibt es einen einzigen, riskanten Umschalttag. Beim Strangler-Pattern gibt es dutzende kleine Umschaltungen — jede einzeln testbar, jede einzeln zurücknehmbar.
Wo anfangen: die Auswahl des ersten Moduls
Das erste Modul entscheidet über die Glaubwürdigkeit des ganzen Vorhabens. Bewährte Kriterien:
- Hoher Schmerz, klare Grenzen: ein Bereich, über den sich alle beschweren und der wenige Abhängigkeiten hat
- Eigene Daten: Module, die vorwiegend auf eigenen Tabellen arbeiten, lassen sich sauberer herauslösen
- Messbarer Nutzen: ein Ergebnis, das Fachbereich und Geschäftsführung nach acht Wochen sehen können
- Kein Herzstück: nicht mit der Kernbuchung oder Abrechnung starten — die kommt, wenn Fassade und Team eingespielt sind
Der schwierige Teil: die Daten
Code zu ersetzen ist die halbe Arbeit, die Daten sind die andere. Solange alter und neuer Teil auf denselben Bestand zugreifen müssen, braucht es eine klare Besitzregel: Genau ein System schreibt einen Datensatztyp, das andere liest — über Schnittstelle oder Synchronisation, nie beide schreibend auf dieselbe Tabelle. Wer diese Regel aufweicht, handelt sich Inkonsistenzen ein, die Wochen kosten. Für die Übergangszeit hat sich ein ereignisbasierter Abgleich bewährt: Der neue Dienst veröffentlicht Änderungen, das Altsystem konsumiert sie — so bleibt die Richtung eindeutig.
Fortschritt messbar machen
Ein Strangler-Projekt braucht eine Kennzahl, sonst wird es zum ewigen Nebenprojekt. Praktikabel ist der Anteil des Traffics, der über die Fassade bereits im neuen System landet: 0 Prozent am Anfang, 100 Prozent am Ende. Diese Zahl gehört ins Monatsreporting — und zu jedem migrierten Modul gehört ein festes Abschaltdatum für den alten Pfad. Ohne Abschaltdisziplin bleibt der teuerste Zustand dauerhaft bestehen: zwei Systeme, doppelte Wartung, doppelte Fehlerquellen.
Warum sich der Aufwand überhaupt lohnt, zeigt der Beitrag zu technischen Schulden und warum alte Systeme Wachstum bremsen — und wie der Datenumzug im Detail sauber läuft, der Artikel zur Datenmigration ohne Chaos.