Altsysteme schrittweise ablösen

Wenn bewährte Software Veränderungen erschwert

Eine Anwendung kann seit Jahren zuverlässig arbeiten und trotzdem zum Hindernis werden: Eine neue Schnittstelle lässt sich nur aufwendig ergänzen, Änderungen betreffen viele voneinander abhängige Funktionen oder für die eingesetzte Technik fehlen inzwischen Fachkenntnisse. Gleichzeitig hängen Auftragsbearbeitung, Service oder Produktion von dieser Software ab.

Wer ein solches Altsystem ablösen möchte, muss deshalb zwei Aufgaben zusammenbringen: Die heutigen Geschäftsprozesse sollen weiterlaufen, während die Software für künftige Anforderungen vorbereitet wird. Ein möglicher Weg ist, einzelne Aufgaben schrittweise an neue Komponenten zu übergeben. Welche davon zuerst an die Reihe kommt, sollte sich am betrieblichen Nutzen und an ihren Abhängigkeiten orientieren.

Was ist das Strangler Pattern?

Das Strangler Pattern, genauer Strangler Fig Pattern, beschreibt die allmähliche Ablösung eines bestehenden Systems. Neue Software entsteht neben der alten und übernimmt nach und nach deren Funktionen. Der Anteil des Altsystems schrumpft, bis die benötigten Aufgaben übertragen sind und es abgeschaltet werden kann.

Der Name geht auf Martin Fowler und das Bild einer Würgefeige zurück, die um einen vorhandenen Baum herumwächst und schließlich eigenständig steht. Auf Software übertragen bedeutet das: Kleine, nutzbare Teile der neuen Lösung gehen bereits in Betrieb, während weitere Teile noch entstehen. Erkenntnisse aus diesen Schritten können in die nächsten Entscheidungen einfließen. Martin Fowler: Strangler Fig.

Das Muster beschreibt den Weg der Ablösung. Die Zielarchitektur wird gesondert gewählt. Im folgenden Beispiel übernehmen Microservices die Aufgaben des Monolithen; für andere Anwendungen kann eine neue, intern klar gegliederte Gesamtlösung passen.

Beispiel: Vom Monolithen zu Microservices

Das folgende Wartungssystem ist ein entworfenes Beispiel zur Veranschaulichung. Ein Industriebetrieb verwaltet darin seine Anlagen, plant Wartungen und erstellt Serviceberichte. Alle drei Bereiche laufen in einer gemeinsam ausgelieferten Anwendung, einem Monolithen, und nutzen eine gemeinsame Datenbank.

Die Wartungsplanung soll künftig neue Terminregeln unterstützen und unabhängig von der Berichtserstellung weiterentwickelt werden. Sie wird deshalb als erster Bereich herausgelöst. Für das Beispiel nehmen wir an, dass sich ihre Zugriffe gezielt umleiten und ihre Abhängigkeiten zur Anlagenverwaltung über eine Schnittstelle abbilden lassen.

1. Einen fachlichen Bereich abgrenzen

Der neue Wartungsdienst übernimmt das Planen, Verschieben und Abschließen von Wartungen samt den dazugehörigen Regeln. Die Anlagenverwaltung bleibt zunächst im Monolithen. Der Dienst benötigt von ihr beispielsweise Anlagenkennung, Standort und Typ.

Damit erhält der erste Microservice eine zusammenhängende fachliche Aufgabe. Die Aufteilung folgt dem Geschäftsprozess; reine Technikschichten wie Oberfläche oder Datenbank bilden dafür keine ausreichende Grenze. AWS beschreibt diesen Zuschnitt als Zerlegung nach fachlichen Fähigkeiten.

Vor der Umsetzung würde ich mit den Anwendern typische Vorgänge und Ausnahmen festhalten: Was passiert bei einer stillgelegten Anlage? Wie werden überfällige Wartungen behandelt? Welche bereits vergebenen Termine müssen erhalten bleiben? Diese Fälle werden später zu Abnahmekriterien für den neuen Dienst.

2. Anfragen gezielt weiterleiten

Vor das bestehende System kommt ein gemeinsamer Zugang, etwa ein API-Gateway oder Reverse Proxy. Diese Fassade entscheidet, welche Komponente eine Anfrage bearbeitet. Zunächst leitet sie sämtliche Anfragen an den Monolithen weiter. Nach der Freigabe des neuen Dienstes übernimmt dieser die Aufrufe zur Wartungsplanung; Anlagenverwaltung und Serviceberichte bleiben beim Altsystem.

Diese Form der Weiterleitung erläutert AWS beim Strangler Fig Pattern. Sie ermöglicht, die technische Zuständigkeit hinter einem bestehenden Zugang zu verändern.

Im Beispiel könnte die Fassade Aufrufe unter /api/wartungen/ an den neuen Dienst schicken. Die übrigen Pfade führen weiterhin zum Monolithen. Eine bestehende Bedienoberfläche kann erhalten bleiben, soweit Schnittstellen und Verhalten kompatibel bleiben.

3. Die Verbindung zum Altsystem begrenzen

Solange die Anlagenverwaltung im Monolithen liegt, fragt der Wartungsdienst benötigte Stammdaten dort über eine vereinbarte Schnittstelle ab. Ein Adapter übersetzt bei Bedarf alte Datenformate und fachliche Bedeutungen in das Modell des neuen Dienstes. So können beispielsweise historische Statuscodes in eindeutige Anlagenzustände überführt werden.

Diese Übersetzung heißt Anti-Corruption Layer. Sie hält Eigenheiten des Altsystems an einer definierten Grenze, damit sich dessen Datenmodell nicht durch die neue Anwendung zieht. Der Adapter kann Bestandteil eines Dienstes sein; dafür ist kein eigener Microservice erforderlich. Microsoft: Anti-Corruption Layer.

Auch interne Zugriffe müssen umgestellt werden: Wenn die alte Berichtsfunktion einen Wartungstermin benötigt, soll sie ihn künftig vom zuständigen Dienst beziehen. Nur die Browseranfragen umzuleiten würde diese Abhängigkeit noch nicht lösen. AWS: Zusammenarbeit zwischen Monolith und neuen Diensten.

4. Daten und Schreibverantwortung übertragen

Zur Ablösung gehören auch die Daten. Eine erste Übernahme kann den vorhandenen Bestand kopieren; anschließend lassen sich weitere Änderungen nachführen, etwa über Change Data Capture (CDC). Dabei werden Änderungen an der Quelldatenbank erfasst und in den neuen Datenbestand übertragen. Vor dem Wechsel sind Vollständigkeit und fachliche Ergebnisse zu prüfen. Microsoft: schrittweise Ablösung einer monolithischen Datenbank.

Für unser Beispiel würde ich die Verantwortung so festlegen:

1. Vorbereitung: Der Monolith bleibt für Änderungen an Wartungen zuständig. Der neue Datenbestand dient zunächst der Übernahme und Prüfung.
2. Abgleich: Geplante Termine, Anlagenzuordnungen und Bearbeitungsstände werden verglichen. Testläufe dürfen keine echten Wartungsaufträge oder Benachrichtigungen doppelt auslösen.
3. Umschaltung: Neue Schreibzugriffe auf Wartungen werden für ein vereinbartes Zeitfenster angehalten, laufende Änderungen abgeschlossen und verbleibende Datenänderungen übernommen. Nach der Prüfung wechseln sämtliche Schreibwege dieses Bereichs zum neuen Dienst, auch Hintergrundaufgaben und Importe.
4. Neuer Betrieb: Nur der Wartungsdienst entscheidet über Änderungen an Wartungen. Andere Komponenten greifen über seine Schnittstelle zu. Die Anlagenstammdaten bleiben bis zu ihrer eigenen Migration beim Monolithen.

Das Zeitfenster betrifft hier die Wartungsplanung. Seine Dauer muss erprobt und mit dem Betrieb abgestimmt werden. AWS beschreibt Schreibstopp, abschließenden Datenabgleich und Umleitung als Bestandteile einer geplanten Umschaltung.

5. Den Wechsel prüfen und Rückwege vorbereiten

Im Beispiel müssen nach der Umschaltung bestehende Termine sichtbar sein, Terminänderungen funktionieren und Berichte den richtigen Stand erhalten. Zusätzlich würde ich Antwortzeiten, Fehler und liegen gebliebene Hintergrundaufgaben beobachten. Vorab wird festgelegt, wer bei Problemen entscheidet und welche Abweichungen einen Abbruch erfordern.

Ein Rückweg muss neue Daten berücksichtigen: Hat der Wartungsdienst bereits Termine geändert, enthält die alte Datenbank diese Änderungen möglicherweise nicht. Dann reicht es nicht, Anfragen wieder auf den Monolithen zu lenken. Änderungen müssen gegebenenfalls zurückübertragen werden; alternativ wird die neue Lösung gezielt repariert. Die Voraussetzungen dafür gehören vor dem Wechsel erprobt. AWS: Rollback nach einer Migration.

6. Weitere Bereiche übernehmen und Altteile abschalten

Nach einem stabilen ersten Schritt folgen im Beispiel Anlagenverwaltung und Serviceberichte. Für jeden Bereich werden Schnittstellen, Datenübernahme und Betriebsübergang erneut geklärt. Die Tabelle zeigt jeweils den Zustand nach einer abgeschlossenen Übernahme:

Vor dem Abschalten wird geprüft, ob noch Benutzer, Schnittstellen, Berichte oder Hintergrundaufgaben auf alte Funktionen zugreifen. Benötigte historische Daten müssen weiterhin zugänglich sein. Erst wenn diese Abhängigkeiten aufgelöst sind, können alte Funktionen und schließlich der Monolith entfallen. Die Fassade kann bei Bedarf als gemeinsamer Zugang erhalten bleiben. Microsoft: Abschluss einer Strangler-Migration.

Welchen Nutzen hat die schrittweise Ablösung?

Für einen Betrieb kann dieses Vorgehen mehrere Vorteile haben:

• Früher nutzbare Verbesserungen: Im Beispiel steht die neue Wartungsplanung bereit, während die Berichtsfunktion noch im bisherigen System läuft.
• Begrenztere Änderungen je Übergang: Jeder Schritt hat einen fachlichen Umfang, der gezielt geprüft und mit den betroffenen Anwendern abgestimmt werden kann.
• Lernen aus dem laufenden Betrieb: Erfahrungen mit Datenqualität, Schnittstellen und Bedienung fließen in die nächsten Übernahmen ein.
• Sichtbarer Fortschritt: Neben neuen Funktionen wird erkennbar, welche Altteile bereits entfallen und welche Abhängigkeiten noch bestehen.

Fowler beschreibt frühe Nutzbarkeit und Lernen während der Ablösung als wesentliche Gründe für den schrittweisen Ansatz. Gleichzeitig kostet das zeitweilige Nebeneinander zusätzliche Arbeit. Martin Fowler: inkrementelle Modernisierung.

Für unser Beispiel würde ich deshalb auch den Abbau alter Komponenten als Projektziel festhalten. Sonst könnte die neue Wartungsplanung dauerhaft neben einer weiterhin gepflegten alten Implementierung stehen. Messbar wäre der Fortschritt etwa an abgeschalteten Funktionen, verbleibenden direkten Datenbankzugriffen und dem Aufwand für Änderungen an der Planung. Konkrete Einsparungen lassen sich erst am jeweiligen System bewerten.

Wann passen Microservices als Ziel?

Microservices können sinnvoll sein, wenn fachliche Bereiche unabhängig verändert, bereitgestellt oder skaliert werden sollen. Dafür braucht es klare Verantwortlichkeiten und einen Betrieb, der mehrere Dienste überwachen und Fehler über deren Grenzen hinweg verfolgen kann. Die gemeinsame Fassade muss ebenfalls ausreichend verfügbar und leistungsfähig sein. AWS: Möglichkeiten und Betriebsrisiken des Strangler-Ansatzes.

Bei einer überschaubaren Anwendung würde ich auch einen modularen Monolithen prüfen: eine gemeinsam ausgelieferte Anwendung mit klar getrennten internen Bereichen. Das kann den Aufwand für Betrieb und Abstimmung kleiner halten. Fowler diskutiert die zusätzlichen Kosten mehrerer Dienste und die Bedeutung tragfähiger Modulgrenzen in Monolith First.

Für die schrittweise Ablösung muss außerdem das bestehende System lange genug weiterbetrieben werden können. Zugriffe müssen sich umleiten und alte Zuständigkeiten auflösen lassen. Eine sehr kleine Anwendung oder ein System, das kurzfristig vollständig abgeschaltet werden muss, kann einen anderen Migrationsweg erfordern. Microsoft: Einsatzgrenzen des Strangler Patterns.

Mehr zu den Zielarchitekturen und ihrem Aufwand erläutert der Artikel über verteilte Systeme, Microservices und Event Sourcing.

Projekterfahrung: Modernisierung bei Jungheinrich

Bei Jungheinrich wirkte ich an der schrittweisen Modernisierung des Flottenmanagements mit. Die bestehende Anwendung wurde im laufenden Betrieb weiterentwickelt und um neue Funktionen ergänzt. Zu meinem Beitrag gehörten die gemeinsame Konzeption der Ablösungsstrategie sowie die Entwicklung von Backend-Diensten, Schnittstellen und Weboberflächen, unter anderem für Fahrzeuganbindung und Batteriemanagement. Dabei kamen verteilte Systeme, Microservices und Event Sourcing zum Einsatz.

Die Jungheinrich-Referenz zur Modernisierung des Flottenmanagements beschreibt diese Arbeit. Das Wartungssystem in diesem Artikel veranschaulicht einen möglichen technischen Ablauf unabhängig vom konkreten Kundenprojekt.

Mit einem sinnvollen ersten Schritt beginnen

Vor einer Ablösung würde ich gemeinsam klären: Welcher Geschäftsprozess leidet heute besonders unter den Grenzen der Software? Welche Funktionen werden tatsächlich noch gebraucht? Wo lässt sich ein Bereich abtrennen, dessen Übernahme einen erkennbaren Nutzen bringt?

Eine Prozessanalyse hilft, diesen fachlichen Ausgangspunkt zu bestimmen. Darauf aufbauend lassen sich Schnittstellen zum Bestand und die schrittweise Umsetzung neuer Software planen. Zum ersten Schritt gehören ein nutzbares Ergebnis und eine klare Vorstellung davon, welche alte Zuständigkeit damit entfallen soll.

Quellen und Einordnung

Die technischen Prinzipien stützen sich auf sieben verlinkte Primärquellen von Martin Fowler, AWS und Microsoft, geprüft am 13. September 2026. Das Wartungsbeispiel und seine Migrationsreihenfolge sind eigene Veranschaulichungen. Die Projekterfahrung bezieht sich auf meine Arbeit bei Jungheinrich; daraus werden keine pauschalen Zeit- oder Kosteneinsparungen abgeleitet.