Strangler-Pattern: Wie du Legacy-Systeme schrittweise ablöst

Dein Legacy-System verarbeitet Bestellungen, Rechnungen oder Produktionsdaten zuverlässig – solange niemand eine Änderung verlangt. Sobald eine neue Schnittstelle, ein anderes Datenmodell oder ein moderner Self-Service dazukommt, wird aus einer kleinen Anpassung schnell ein Risiko. Wer sein Legacy-System modernisieren will, steht deshalb vor einer unangenehmen Frage: Komplett ersetzen oder schrittweise ablösen?

Das Strangler-Pattern bietet einen kontrollierten Weg durch diese Entscheidung. Neue Funktionen entstehen außerhalb des alten Systems und übernehmen schrittweise dessen Aufgaben. So bleibt der laufende Betrieb stabil, während technische Abhängigkeiten, veraltete Komponenten und schwer wartbarer Code Stück für Stück verschwinden.

Stell Dir ein Logistik-Team vor, dessen Auftragsverwaltung seit Jahren auf einer zentralen Anwendung läuft. Das System kennt jede Sonderregel, jede historische Ausnahme und vermutlich auch einige Abkürzungen, die niemand mehr dokumentiert hat. Das Team entwickelt nun einen neuen Service für Lieferstatus und Kundenbenachrichtigungen. Dieser Service greift zunächst auf die vorhandenen Auftragsdaten zu. Später übernimmt er eigene Prozesse. Die alte Anwendung bleibt währenddessen für die übrigen Abläufe aktiv.

Genau so entsteht eine schrittweise Migration von Legacy-Systemen: Ein abgegrenzter Teil wird modernisiert, über eine Routing- oder Integrationsschicht angebunden und unter realen Bedingungen betrieben. Jede erfolgreiche Ablösung reduziert die Verantwortung des alten Systems. Der große Schnitt verliert an Bedeutung.

Wie lässt sich ein Legacy-System modernisieren?

Ein Legacy-System zu modernisieren bedeutet, seine technische Basis, seine Architektur oder einzelne Geschäftsprozesse gezielt weiterzuentwickeln, ohne den laufenden Betrieb unnötig zu gefährden. Die passende Strategie hängt von Abhängigkeiten, Datenqualität, Änderungsdruck und dem geschäftlichen Wert der bestehenden Funktionen ab.

Moderne Zielarchitekturen entstehen häufig in mehreren Etappen. Einzelne Komponenten werden ersetzt, Schnittstellen stabilisiert, Datenflüsse bereinigt und Verantwortlichkeiten neu zugeschnitten. Dabei kann die Modernisierung verschiedene Formen annehmen:

• Refactoring: Bestehender Code wird strukturell verbessert, während seine Funktion erhalten bleibt.
• Replatforming: Die Anwendung wechselt auf eine andere technische Plattform, etwa eine neue Laufzeitumgebung oder Infrastruktur.
• Modulare Ablösung: Einzelne fachliche Bereiche werden als eigenständige Services oder Module neu gebaut.
• Neuentwicklung: Ein System wird fachlich und technisch von Grund auf neu konzipiert.

Die erste Aufgabe besteht in einer belastbaren Bestandsaufnahme. Dazu gehören Geschäftsprozesse, Schnittstellen, Datenflüsse, Batch-Jobs, Benutzerrollen und technische Abhängigkeiten. Besonders kritisch sind Funktionen, die nur implizit im Code stecken. Eine Anwendung kann technisch veraltet wirken und trotzdem zentrale Geschäftslogik enthalten, die in keinem Fachkonzept auftaucht.

Wie groß ist dein Legacy-Monster?

Lass uns sprechen, bevor die nächste kleine Änderung zum großen Risiko wird.

Mats EversGeschäftsführer

Kostenfreies Erstgespräch

Was kostet eine komplette Neuentwicklung?

Die Kosten einer kompletten Neuentwicklung hängen vor allem von fachlicher Komplexität, Integrationsgrad, Datenmigration und dem erforderlichen Parallelbetrieb ab. Eine pauschale Antwort gibt es nicht. Die reine Entwicklung der neuen Anwendung bildet dabei nur einen Teil der Gesamtkosten einer Systemneuentwicklung.

Eine neue Lösung braucht zunächst ein belastbares fachliches Modell. Teams müssen Prozesse analysieren, Sonderfälle klären, Rollen definieren und Schnittstellen festlegen. Danach folgen Architektur, Implementierung, Tests, Datenübernahme, Betrieb und Schulung. Je größer die Lücke zwischen dokumentierter und tatsächlich gelebter Funktionalität ist, desto höher wird der Analyseaufwand.

Bei einer kompletten Neuentwicklung statt Migration kommen weitere Kostenblöcke hinzu:

• Fachliches Reverse Engineering: Geschäftsregeln und Ausnahmefälle müssen aus Code, Gesprächen und Betriebswissen rekonstruiert werden.
• Integrationen: ERP, CRM, Zahlungsdienste, Maschinen, Portale und Partner benötigen abgestimmte Schnittstellen.
• Datenmigration: Historische Daten müssen bewertet, bereinigt, transformiert und fachlich validiert werden.
• Parallelbetrieb: Alte und neue Lösung laufen häufig über eine Übergangsphase hinweg.
• Organisatorischer Aufwand: Fachbereiche, Betrieb und Support müssen Prozesse und Verantwortlichkeiten anpassen.

Eine Neuentwicklung lohnt sich vor allem bei einem klaren strategischen Ziel, stark veränderten Geschäftsprozessen oder einer Architektur, deren technische Grenzen jede weitere Änderung verteuern. Der Aufwand muss gegen die laufenden Kosten des Altbestands gerechnet werden. Dazu zählen Wartung, Spezialwissen, Lizenzabhängigkeiten, Ausfallrisiken und die Zeit, die Entwickler für das Verstehen statt für das Verbessern des Systems einsetzen.

Eine grobe Budgetschätzung auf Basis von Funktionslisten reicht für diese Entscheidung selten aus. Aussagekräftiger sind technische Spikes, Domänen-Workshops und ein vertikaler Prototyp mit echten Integrationen. Sie zeigen früh, wo die schwierigen Stellen liegen.

Wie funktioniert die modulare Ablösung mit dem Strangler-Pattern?

Das Strangler-Pattern ersetzt ein Legacy-System schrittweise, indem neue Komponenten einzelne fachliche Verantwortlichkeiten übernehmen und der Datenverkehr kontrolliert auf sie gelenkt wird. Der alte Kern bleibt für verbleibende Funktionen aktiv, bis seine Aufgaben vollständig abgelöst sind.

Der Name bezieht sich auf eine Würgefeige, die um einen bestehenden Baum wächst und ihn im Laufe der Zeit überwuchert. In der Softwarearchitektur wächst die neue Lösung um das alte System herum. Das Bild ist etwas botanischer als nötig, bleibt aber erstaunlich treffend.

Eine Umsetzung beginnt mit klaren fachlichen Schnitten. Geeignet sind Bereiche mit eigener Verantwortung, überschaubaren Datenflüssen und einem erkennbaren Änderungsbedarf. Beispiele sind Preisberechnung, Benachrichtigungen, Dokumentenerzeugung oder die Verwaltung eines bestimmten Geschäftsvorgangs.

Ein typischer Ablauf umfasst fünf Schritte:

1. Systemgrenzen und Abhängigkeiten erfassen: Teams dokumentieren Aufrufe, Datenbesitz, Nebenwirkungen und fachliche Verantwortlichkeiten.
2. Routing etablieren: Ein API-Gateway, ein Reverse Proxy oder eine vergleichbare Schicht entscheidet, welche Anfragen das alte oder das neue System verarbeitet.
3. Vertikalen Funktionsschnitt bauen: Ein fachlicher Ablauf wird von der Oberfläche bis zur Datenhaltung durchgängig umgesetzt.
4. Verhalten vergleichen: Fachliche Ergebnisse, Fehlerfälle, Laufzeiten und Datenkonsistenz werden unter realen Bedingungen geprüft.
5. Alte Funktion zurückbauen: Sobald der neue Bereich stabil läuft, wird die entsprechende Logik im Legacy-System deaktiviert und entfernt.

Entscheidend ist die Besitzfrage für Daten. Zwei Systeme dürfen dieselben Datenbestände nicht dauerhaft unkontrolliert verändern. Für jeden migrierten Bereich braucht es eine klare Regel: Welches System ist führend? Wie werden Änderungen übertragen? Wie lassen sich Fehler erkennen und korrigieren?

Eine robuste Übergangsarchitektur braucht außerdem Observability. Metriken, strukturierte Logs, Traces und fachliche Prüfungen zeigen, ob die neue Komponente korrekt arbeitet. Feature-Toggles und kontrollierte Rollouts ermöglichen eine begrenzte Aktivierung. Damit wird die Migration selbst zu einem steuerbaren Betriebsprozess.

Welche Risiken hat eine Big-Bang-Migration?

Eine Big-Bang-Migration bündelt die Umstellung auf einen einzigen Stichtag und konzentriert dadurch technische, fachliche und organisatorische Risiken in einem kurzen Zeitfenster. Die Risiken einer Big-Bang-Migration steigen besonders bei vielen Integrationen, großen Datenbeständen und schwer testbaren Geschäftsregeln.

Der Ansatz hat einen nachvollziehbaren Reiz: Nach der Umstellung existiert eine Zielplattform, und der Übergang endet an einem klaren Datum. Für kleine, überschaubare Systeme mit wenigen Abhängigkeiten kann das funktionieren. Bei gewachsenen Unternehmensanwendungen entstehen jedoch mehrere kritische Punkte gleichzeitig.

Datenmigration und Datenqualität bilden eine zentrale Risikozone. Historische Datensätze enthalten oft Dubletten, fehlende Referenzen oder fachliche Sonderfälle. Ein technischer Import kann erfolgreich durchlaufen, während die Daten fachlich unbrauchbar bleiben.

Schnittstellen verhalten sich unter Last anders als im Test. Partner, Geräte und interne Anwendungen senden unerwartete Formate, wiederholen Anfragen oder reagieren verzögert. Jede zusätzliche Integration erweitert die Zahl möglicher Fehlerpfade.

Rollback wird komplex, sobald Daten in der neuen Plattform verändert wurden. Ein Zurückschalten der Anwendung genügt dann häufig nicht. Änderungen müssen zurückübertragen, synchronisiert oder fachlich bewertet werden. Das kann die Wiederherstellung erheblich erschweren.

Der Stichtag erzeugt organisatorischen Druck. Fachbereiche müssen Prozesse umstellen, Support-Teams brauchen neue Diagnosewege und Entwickler müssen gleichzeitig Fehler beheben sowie offene Funktionen fertigstellen. Ein enger Terminplan macht Abweichungen teuer.

Zu den Big-Bang-Migration Vor- und Nachteilen gehört deshalb eine klare Abwägung. Der Ansatz kann bei einem kleinen System mit stabilen Anforderungen, vollständiger Testabdeckung, geringer Integrationsdichte und einem belastbaren Rückfallplan sinnvoll sein. Für stark vernetzte Legacy-Systeme bietet eine schrittweise Migration meist bessere Kontrollpunkte.

Wann ist eine schrittweise Migration die bessere Wahl?

Eine schrittweise Migration ist die bessere Wahl, wenn technische Abhängigkeiten, laufender Betrieb und fachliche Unsicherheit eine zentrale Umstellung riskant machen. Die wichtigsten Entscheidungskriterien für Systemmodernisierung liegen dabei in der Veränderbarkeit des Systems, der Kritikalität seiner Prozesse und der Fähigkeit des Teams, Übergangszustände zu betreiben.

Folgende Fragen helfen bei der Einordnung:

• Lassen sich fachliche Verantwortlichkeiten klar voneinander trennen?
• Gibt es Schnittstellen oder Ereignisse, über die neue Komponenten angebunden werden können?
• Wie kritisch ist eine Betriebsunterbrechung für Umsatz, Produktion oder Kundenservice?
• Sind Datenbesitz und Synchronisation zwischen alten und neuen Komponenten beherrschbar?
• Verfügt das Team über Tests, Monitoring und Domänenwissen für kontrollierte Releases?

Eine schrittweise Migration eignet sich besonders für Systeme mit hoher Betriebsrelevanz, vielen Integrationen und wechselnden Anforderungen. Jeder abgeschlossene Abschnitt liefert Erkenntnisse über Datenqualität, Architektur und tatsächliches Nutzerverhalten. Diese Erkenntnisse fließen in die nächsten Schritte ein und reduzieren Fehlentscheidungen.

Technische Abhängigkeiten bei Legacy-Systemen können den Ansatz erschweren. Eine Funktion lässt sich fachlich sauber schneiden, hängt aber möglicherweise an gemeinsamen Tabellen, globalen Transaktionen oder impliziten Seiteneffekten. Dann braucht es zunächst eine Entkopplungsschicht, ein Anti-Corruption Layer oder eine gezielte Datenreplikation.

Eine komplette Neuentwicklung kann trotzdem die bessere Entscheidung sein, wenn der alte Code kaum testbar ist, zentrale Geschäftslogik untrennbar vermischt wurde oder die Zielarchitektur einen grundlegenden Plattformwechsel erfordert. Die Frage „Wann lohnt sich eine Neuentwicklung?“ beantwortet sich über Risiko, Lernfähigkeit und langfristige Betriebskosten. Ein sauber begrenzter Pilot schafft dafür meist eine bessere Grundlage als eine rein theoretische Architekturentscheidung.

Für eine Legacy-Migration ohne Betriebsunterbrechung braucht es schließlich mehr als neue Technologie. Du brauchst klare Verantwortlichkeiten, beobachtbare Übergänge, reversible Schritte und eine konsequente Entscheidung darüber, wann alte Komponenten tatsächlich abgeschaltet werden. Sonst wächst aus dem Übergang schnell ein dauerhaftes Nebeneinander zweier Systeme. Das ist technisch machbar, organisatorisch aber selten eine Freude.