Viele mittelständische Unternehmen stehen vor demselben Dilemma: Ihre Kernanwendung, oft ein vor zehn oder fünfzehn Jahren entwickelter Monolith in PHP, altem Java/Spring oder proprietären Datenbankskripten, wickelt das gesamte operative Geschäft ab. Gleichzeitig bindet das System enorme Entwicklerressourcen. Jedes neue Feature birgt das Risiko von Seiteneffekten, Entwickler mit Kenntnissen des alten Stacks werden zur Mangelware, und die Ladezeiten steigen stetig.
Die intuitive Reaktion von Geschäftsführern lautet oft: "Wir schreiben das gesamte System auf der grünen Wiese einmal komplett neu."
In der Praxis scheitern bis zu 70 % dieser sogenannten Big-Bang-Relaunches. Warum? Weil die Anforderungen des Altsystems über Jahre organisch gewachsen sind. Unzählige Sonderfälle, regulatorische Ausnahmen und historische Geschäftsregeln sind nicht dokumentiert, sie existieren ausschließlich im alten Quellcode.
Die risikoärmere und bewährte Alternative ist die schrittweise Migration nach dem Strangler Fig Pattern (Würgefeigen-Muster).
Was ist das Strangler Fig Pattern?
Die Metapher stammt aus der Natur: Eine Würgefeige keimt in den oberen Ästen eines Wirtsbaumes, lässt Wurzeln zum Boden wachsen und umschlingt den Stamm über Jahre, bis sie schließlich die tragende Struktur übernimmt, während der alte Baum abstirbt.
In der Software-Architektur bedeutet das: Wir schalten das Altsystem nicht ab. Stattdessen platzieren wir einen Reverse Proxy oder ein modernes API-Gateway (wie Traefik, Envoy oder NGINX) vor das Altsystem.
- Routing: Sämtlicher Datenverkehr läuft zunächst weiterhin an den alten Monolithen.
- Vertikaler Schnitt: Ein einzelner, klar abgrenzbarer Geschäftsbereich (z. B. Authentifizierung, Rechnungsstellung oder Reporting) wird in modernem TypeScript, Next.js oder Go als eigenständiger Dienst neu gebaut.
- Schrittweises Umschalten: Das Gateway leitet Aufrufe für diesen spezifischen Pfad auf den neuen Dienst um.
- Wiederholung: Nach und nach werden weitere Komponenten stranguliert, bis der alte Kern leer ist und abgeschaltet werden kann.
4 Schritte für die erfolgreiche Umsetzung
1. Geschäftsregeln durch Characterization Tests absichern
Bevor auch nur eine Zeile Code umgeschrieben wird, müssen wir das reale Verhalten des Altsystems kennen. Wir schreiben End-to-End- und Integrationstests, die echte Eingaben an das Altsystem senden und die genauen Ausgaben aufzeichnen. Dadurch entsteht ein Sicherheitsnetz: Die neue Komponente muss dieselben Daten wie der alte Monolith liefern.
2. Daten-Synchronisation etablieren
In der Übergangsphase müssen Altsystem und Neusystem oft auf dieselben Daten zugreifen. Bewährt haben sich hier:
- Change Data Capture (CDC): Änderungen in der alten relationalen Datenbank werden per Event (z. B. via Debezium oder Trigger) an das Neusystem gestreamt.
- Dual Writing / Shadow Reads: Neue Schnittstellen schreiben synchron oder asynchron in beide Systeme, um Datenintegrität vor der endgültigen Umschaltung zu garantieren.
3. Kontinuierlicher Mehrwert für Fachabteilungen
Der größte Vorteil für Product Owner und Geschäftsführung: Statt zwei Jahre auf einen fernen Relaunch zu warten, gehen bereits nach 4 bis 8 Wochen die ersten modernen Module live. Das Team sammelt echtes Nutzerfeedback in Produktion und der Return on Investment (ROI) setzt sofort ein.
4. Veralteten Code konsequent löschen
Sobald ein Modul im Neusystem stabil läuft, wird der alte Pfad im Monolithen unwiderruflich gelöscht. So schrumpft die alte Codebase messbar von Sprint zu Sprint.
Typische Stolpersteine und wie man sie vermeidet
- Zu große Schnitte gewählt: Versuchen Sie nicht, die komplexeste Domäne zuerst zu migrieren. Starten Sie mit einem read-only Bereich oder einer unkritischen Funktion, um die Deployment-Pipeline und das Routing einzuschleifen.
- Gemeinsame Datenbank als versteckter Flaschenhals: Wenn Alt- und Neusystem auf dieselben Tabellen mit harten Foreign Keys zugreifen, blockieren sie sich gegenseitig. Bauen Sie saubere Domain-Grenzen und APIs.
- Fehlendes Monitoring: Ohne detailliertes Distributed Tracing (z. B. mit OpenTelemetry) ist bei Fehlern unklar, ob das Gateway, der alte Monolith oder der neue Service das Problem verursacht.
Fazit: Modernisierung als kontrollierter Geschäftsprozess
Software-Modernisierung ist kein IT-Selbstzweck, sondern Risikomanagement und Innovationssicherung. Wer schrittweise vorgeht, behält die volle Kontrolle über Budget, Qualität und Betriebszeiten.
Planen Sie die Modernisierung eines gewachsenen Systems? Erfahren Sie mehr über unseren Ansatz auf unserer Leistungsseite zur Legacy-Modernisierung oder fordern Sie ein unverbindliches Modernisierungs-Audit an.