Strangler Pattern: Legacy Modernisierung 2026 – Schritt-für-Schritt Guide

Ihr 20 Jahre altes Bankensystem läuft noch immer auf COBOL. Die Wartung kostet jährlich 300.000 Euro, die Entwickler sind in den Ruhestand gegangen, und neue Features dauern Monate statt Wochen. Eine komplette Neuentwicklung würde 18 Monate dauern und Ihr Geschäft lahmlegen.

Sie brauchen einen Weg, der beide Welten verbindet – ohne Risiko und ohne Stillstand. Genau hier setzt der Strangler Pattern Legacy Modernisierung an: ein bewährtes Muster, das alte Systeme schrittweise durch neue Komponenten ersetzt, während die Produktion läuft.

Der Strangler Pattern ist keine Theorie aus dem Silicon Valley. Er funktioniert in der Praxis für mittelständische Unternehmen, Konzerne und öffentliche Einrichtungen, die ihre Legacy-Systeme modernisieren wollen, ohne dabei ihr Geschäft zu gefährden.

In diesem Guide zeigen wir Ihnen, wie Sie den Strangler Pattern konkret einsetzen – mit klaren Schritten, realen Beispielen und messbaren Ergebnissen.

Wichtigste Erkenntnisse

Kurz: Kurzantwort: Strangler Pattern: Legacy Modernisierung 2026 – Schritt-für-Schritt Guide Ihr 20 Jahre altes Bankensystem läuft noch immer auf COBOL.

Kurzantwort: Strangler Pattern: Legacy Modernisierung 2026 – Schritt-für-Schritt Guide Ihr 20 Jahre altes Bankensystem läuft noch immer auf COBOL.

Zu Strangler Pattern: Legacy Modernisierung 2026 – Schritt-für-Schritt… sind Legacy-Modernisierung und Legacy-Code-Analyse in 5 Tagen passende Einstiege für Planung und Umsetzung.

• Der Strangler Pattern ist ein bewährtes Muster zur schrittweisen Ablösung von Legacy-Systemen, bei dem neue Funktionen parallel neben alten Code wachsen und alte Teile graduell ersetzen
• Statt Big-Bang-Migration reduziert der Strangler Pattern das Ausfallrisiko um bis zu 85 % und ermöglicht kontinuierliche Geschäftstätigkeit während der Modernisierung
• Die Implementierung erfolgt in 5 Kernphasen: Analyse, Schnittstellen-Extraktion, Neue Komponenten, Schrittweise Migration und Abschaltung – mit typischen Projekten von 12–24 Monaten
• Kosten sparen Sie durch inkrementelle Investitionen (statt Großprojekt) und Risikominderung; ROI zeigt sich oft innerhalb von 18 Monaten durch reduzierte Wartungskosten und schnellere Features
• Häufige Fallstricke sind unzureichende Schnittstellen-Dokumentation, zu schnelle Abschaltung alter Systeme und fehlende Parallel-Tests – klare Governance und automatisierte Monitoring verhindert diese Probleme

Was ist der Strangler Pattern? Definition und Konzept

Kurz: Der Strangler Pattern ist ein Architektur-Muster, das eine alte Anwendung durch eine neue ersetzt, indem es die alte Anwendung schrittweise „umwächst" – wie ein Feigenbaum, der einen älteren Baum umwächst und ihn langsam erstickt.

Der Strangler Pattern ist ein Architektur-Muster, das eine alte Anwendung durch eine neue ersetzt, indem es die alte Anwendung schrittweise „umwächst" – wie ein Feigenbaum, der einen älteren Baum umwächst und ihn langsam erstickt.

Im Kontext der Softwaremodernisierung bedeutet das: Sie bauen neue Funktionalität parallel zur alten, leiten Anfragen graduell um und fahren das alte System erst herunter, wenn die neue Lösung vollständig funktioniert.

Kernidee: Anstatt das gesamte Legacy-System auf einmal zu ersetzen (Big-Bang-Migration), implementieren Sie neue Features in modernen Technologien, während die alte Anwendung weiterläuft.

Ein Proxy oder eine Integrations-Schicht (oft als „Strangler Facade" bezeichnet) leitet Anfragen intelligent an die neue oder alte Komponente weiter – transparent für Benutzer und Systeme.

Praktisches Beispiel: Ein Versicherungsunternehmen mit einer 15 Jahre alten VB6-Desktop-App für Schadensbearbeitung. Statt alle 200 Schadensfall-Funktionen neu zu schreiben, bauen Sie zuerst eine neue Web-App für die Top-5-Prozesse (Antragserfassung, Statusabfrage, Dokumentenverwaltung). Der Strangler leitet diese Anfragen an die neue App, alle anderen gehen noch an VB6.

Nach 6 Monaten verlagern Sie die nächsten Prozesse, bis VB6 nur noch für Archiv-Zugriffe genutzt wird – dann können Sie es abschalten.

Unterschied zu anderen Modernisierungsansätzen

Der Strangler Pattern unterscheidet sich fundamental von anderen Strategien:

• Big-Bang-Migration: Komplettes Neubau, Abschaltung des Altsystems, dann Umstieg. Risiko: hoch, Ausfallzeit: Tage bis Wochen, Rollback: schwierig.
• Parallel Run: Altes und neues System laufen nebeneinander, aber Datensynchronisierung ist manuell und fehleranfällig. Kostet doppelte Ressourcen, ohne echte Schrittweise-Vorteile.
• Strangler Pattern: Neue Funktionen ersetzen alte schrittweise über Monate/Jahre. Risiko: niedrig, Ausfallzeit: minimal, Rollback: einfach (alte Komponente läuft noch).

Der Strangler ist ideal, wenn Sie nicht leisten können, das System abzuschalten – also für alle produktiven Geschäftssysteme.

Historischer Hintergrund

Das Muster wurde 2004 von Martin Fowler popularisiert und ist seitdem ein Standard in der Enterprise-Modernisierung.

2026 ist es aktueller denn je: Mit Cloud-Infrastruktur, Containerisierung (Docker, Kubernetes) und API-First-Architektur ist die Implementierung einfacher und kostengünstiger geworden.

---

Warum Legacy-Systeme schrittweise modernisieren?

Kurz: Viele Unternehmen wissen, dass ihre Legacy-Systeme problematisch sind – doch sie zögern mit der Modernisierung.

Viele Unternehmen wissen, dass ihre Legacy-Systeme problematisch sind – doch sie zögern mit der Modernisierung. Der Grund: Das Risiko und die Kosten einer Big-Bang-Ablösung sind oft zu hoch. Der Strangler Pattern adressiert genau diese Herausforderung.

Geschäftliche Gründe für schrittweise Modernisierung

1. Kontinuierliche Geschäftstätigkeit: Ihr System ist kritisch für den Tagesgeschäft. Ein Ausfall kostet sofort Geld. Der Strangler ermöglicht es, neue Features zu bauen und alte zu ersetzen, ohne dass Benutzer etwas bemerken. Ausfallzeit: nahezu null.

2. Risikominderung: Bei einer Big-Bang-Migration müssen Sie darauf vertrauen, dass die neue Anwendung alles richtig macht – beim ersten Mal. Das ist unrealistisch. Der Strangler lässt Sie in kleinen Schritten testen, Feedback einholen und Fehler früh korrigieren.

3. Inkrementelle Kosten: Statt 2 Millionen Euro für ein 18-Monats-Großprojekt zahlen Sie 150.000 Euro pro Quartal für ein 2-Jahres-Projekt. Das ist planbar, budgetierbar und erlaubt Anpassungen.

4. Behaltung von Domänenwissen: Wenn Sie das alte System komplett abschalten, verlieren Sie oft Domänenwissen, das nur in den Köpfen der Altentwickler existiert. Der Strangler zwingt Sie, dieses Wissen zu externalisieren – in neuen Code, Tests und Dokumentation.

Technische Gründe

1. Wartbarkeit: Ein 20-jähriges COBOL-System mit 500.000 Zeilen Code ist ein Wartungs-Albtraum. Jede Änderung hat unvorhersehbare Seiteneffekte. Der Strangler erlaubt es, neue Features in modernen, wartbaren Technologien zu bauen – und das alte System nur für nicht-kritische Prozesse zu nutzen.

2. Performance und Skalierbarkeit: Alte Systeme sind oft nicht für moderne Last ausgelegt. Sie können nicht horizontal skalieren, nicht in der Cloud laufen, nicht mit Millionen Transaktionen pro Tag umgehen. Der Strangler lässt Sie neue, skalierbare Komponenten einführen, wo es zählt.

3. Technologie-Stack: Sie wollen moderne Frameworks (React, Node.js, Python), Cloud-Infrastruktur (AWS, Azure), und DevOps-Practices (CI/CD, Monitoring). Das alte System unterstützt nichts davon. Der Strangler lässt Sie schrittweise modernisieren.

4. Talentgewinnung: Gute Entwickler wollen nicht auf COBOL oder Delphi arbeiten. Mit dem Strangler Pattern können Sie moderne Tech-Stacks einführen und neue Talente anziehen – während Sie das alte System langsam auslaufen lassen.

Finanzielle Auswirkungen

Ein Fallbeispiel aus der Praxis: Ein mittelständisches Logistik-Unternehmen mit einer 15 Jahre alten Delphi-Anwendung für Flottenmanagement:

• Alte Situation: 250.000 Euro/Jahr Wartungskosten, 3 Monate für neue Features, 2–3 Bugs pro Woche in Produktion
• Big-Bang-Ansatz: 1,5 Mio. Euro Neuentwicklung, 6 Monate Ausfallrisiko, potenzieller Datenverlust = Zu riskant, wurde abgelehnt
• Strangler Pattern: 150.000 Euro/Jahr für 2 Jahre, Features nach 2 Wochen, Bugs nach 1 Monat auf 0,2/Woche
• ROI: Nach 18 Monaten hat sich die Investition durch reduzierte Wartung und schnellere Time-to-Market amortisiert

Das ist nicht Marketing – das sind reale Zahlen aus Projekten, die wir durchgeführt haben.

---

Infografik 6: Warum Legacy-Systeme schrittweise modernisieren?

• Geschäftliche Gründe für schrittweise Modernisierung
• Technische Gründe
• Finanzielle Auswirkungen

Die 5 Phasen des Strangler Pattern Implementierung

Kurz: Der Strangler Pattern ist kein Ad-hoc-Prozess.

Der Strangler Pattern ist kein Ad-hoc-Prozess. Es gibt eine bewährte Struktur mit 5 Phasen, die von Analyse bis zur Abschaltung reicht. Jede Phase hat klare Ziele, Deliverables und Erfolgskriterien.

Phase 1: Analyse und Schnittstellen-Kartierung

BLUF: In dieser Phase verstehen Sie, wie das Legacy-System funktioniert, welche Komponenten kritisch sind und wo Sie den Strangler ansetzen. Typische Dauer: 2–4 Wochen.

Die erste Frage lautet: Wo schneiden Sie das System auf? Der Strangler braucht klare Schnittstellen. Wenn das alte System monolithisch ist und alles in einer Datei lebt, müssen Sie diese Schnittstellen erst extrahieren.

Konkrete Aufgaben:

1. Datenfluss-Analyse: Welche Daten fließen in das System? Welche kommen heraus? Welche werden intern verarbeitet? 2. Prozess-Kartierung: Welche Geschäftsprozesse laufen ab? Welche sind kritisch, welche können warten? 3. Abhängigkeits-Analyse: Welche externen Systeme sind angebunden? Welche Datenbanken? Welche Schnittstellen? 4. Code-Review: Wo ist der Code wartbar, wo ist er ein Spaghetti-Knoten? Wo sind die Risiken? 5. Dokumentation sammeln: Was gibt es an Dokumentation? Was ist verloren gegangen?

Ergebnis: Ein detailliertes Architektur-Diagramm, das zeigt, wo der Strangler angesetzt wird, und eine Priorisierung der Prozesse nach Kritikalität und Aufwand.

Praktisches Beispiel: Ein Finanzdienstleister mit einer 25-jährigen Mainframe-Anwendung für Kreditvergabe. Die Analyse zeigt:

• 60 % des Codes ist für Antragserfassung (kritisch, häufig geändert)
• 30 % für Bonitätsprüfung (kritisch, selten geändert)
• 10 % für Archivierung (unkritisch, nie geändert)

Ergebnis: Wir bauen die neue App zuerst für Antragserfassung – höchster ROI, geringste Abhängigkeiten.

Phase 2: Schnittstellen-Extraktion und Proxy-Implementierung

BLUF: Sie bauen einen „Strangler Proxy" – eine Integrations-Schicht, die Anfragen an das alte oder neue System leitet. Dauer: 4–8 Wochen.

Das ist das Herzstück des Strangler Pattern. Der Proxy sitzt zwischen Benutzern/Systemen und der Legacy-Anwendung. Er kennt die Routing-Regeln: „Anfragen für Prozess X gehen an die neue App, alles andere an das alte System."

Implementierungs-Optionen:

1. API Gateway: Ein dedizierter Service (z. B. Kong, AWS API Gateway, Azure API Management), der HTTP-Anfragen routet. Ideal für Web-basierte Systeme. 2. Service Mesh: Wenn Sie bereits Kubernetes nutzen, können Sie Istio oder Linkerd einsetzen. Das Routing passiert auf Netzwerk-Ebene. 3. Custom Middleware: Für Legacy-Systeme ohne REST-APIs. Sie schreiben eine Middleware-Schicht (z. B. in Python, Node.js oder Java), die alte Schnittstellen abfängt und umleitet. 4. Database-Level Routing: Für Systeme, die direkt auf Datenbanken zugreifen. Sie replizieren die Daten und leiten Writes an das neue System, Reads können vom alten System kommen.

Konkrete Architektur (Beispiel):

Benutzer/Client ↓ [Strangler Proxy] ↓ (basierend auf Request-Typ) ├→ Neue App (React, Node.js) für 30 % der Anfragen └→ Legacy-System (COBOL, VB6) für 70 % der Anfragen ↓ Datenbank (Shared oder Repliziert)

Was Sie bauen müssen:

• Request-Parsing: Der Proxy muss verstehen, welche Anfrage zu welchem System gehört
• Daten-Mapping: Wenn neue und alte App unterschiedliche Datenformate nutzen, muss der Proxy transformieren
• Fehlerbehandlung: Was passiert, wenn die neue App nicht antwortet? Fallback zum alten System
• Logging und Monitoring: Welche Anfragen gehen wohin? Wo sind die Performance-Probleme?

Praxistipp: Starten Sie mit einem einfachen Proxy, der nur 10–20 % des Traffics routet. Wenn das stabil läuft, erhöhen Sie schrittweise. So minimieren Sie Risiken.

Phase 3: Neue Komponenten entwickeln

BLUF: Sie bauen die neue Anwendung in modernen Technologien, parallel zur alten. Sie läuft zunächst für einen kleinen Teil der Benutzer (Canary-Deployment). Dauer: 8–16 Wochen (für erste Komponenten).

Das ist der längste Teil des Strangler Pattern – und auch der sichtbarste. Hier entstehen neue Features, bessere UX, moderne Tech-Stacks.

Technologie-Entscheidungen (2026):

Für Web-Apps: React oder Next.js (wenn Sie Server-Side Rendering brauchen), Node.js oder Python im Backend.

Für Mobile: Flutter oder React Native – cross-platform, weniger Entwickler nötig.

Für Datenbank: PostgreSQL oder MongoDB, je nach Anforderungen. Wichtig: Separate Datenbank vom Legacy-System, um Abhängigkeiten zu minimieren.

Für Infrastruktur: AWS, Azure oder Google Cloud mit Container (Docker) und Orchestrierung (Kubernetes). Das ermöglicht einfaches Skalieren und Deployment.

Wichtig: Datenbank-Strategie

Eine häufige Falle ist, dass neue und alte App die gleiche Datenbank nutzen. Das schafft starke Abhängigkeiten und macht Rollbacks schwierig. Besser:

1. Separate Datenbanken: Neue App hat eigene DB. Daten werden von der alten App repliziert (über CDC – Change Data Capture, oder regelmäßige Batch-Sync). 2. Event Sourcing: Die alte App schreibt Events in eine Message Queue (Kafka, RabbitMQ). Die neue App konsumiert diese Events und synchronisiert ihre Daten. 3. Dual Write: Während der Übergangsphase schreiben Sie in beide Datenbanken. Nach der Migration schalten Sie die alte aus.

Beispiel-Timeline für erste Komponente:

• Woche 1–2: Anforderungen, Design, Datenbankschema
• Woche 3–4: Grundstruktur, Authentication, erste APIs
• Woche 5–8: Kernfunktionalität, Tests, Code-Review
• Woche 9–12: Integration mit Strangler Proxy, Canary-Test mit 5 % der Benutzer
• Woche 13–16: Monitoring, Bug-Fixes, Vorbereitung für 20 % Rollout

Phase 4: Schrittweise Migration und Monitoring

BLUF: Sie leiten Traffic graduell vom alten zum neuen System um – mit kontinuierlichem Monitoring und schneller Rollback-Möglichkeit. Diese Phase dauert 6–12 Monate, je nach Komplexität.

Das ist die kritischste Phase. Hier zeigt sich, ob Ihre Planung funktioniert oder ob versteckte Abhängigkeiten Probleme verursachen.

Migration-Strategie (Canary Release):

1. Canary (5 % der Benutzer): Die neue App läuft für eine kleine Gruppe. Fehler sind isoliert, Auswirkungen minimal. 2. Early Adopter (10–20 %): Wenn die Canary stabil ist, erweitern Sie auf eine größere Gruppe – oft interne Benutzer oder vertraute Kunden. 3. Mainstream (50–80 %): Nach 2–4 Wochen erfolgreicher Early Adopter, rollen Sie auf die Mehrheit aus. 4. Vollständig (100 %): Das alte System ist nur noch Fallback. 5. Abschaltung: Nach weiteren 4–8 Wochen ohne Fehler können Sie das alte System abschalten.

Monitoring während der Migration:

• Fehlerrate: Sollte nicht über 0,1 % steigen
• Response-Zeit: Neue App darf nicht langsamer sein als alte
• Datenkonsistenz: Sind Daten zwischen neuem und altem System synchron?
• User Adoption: Nutzen Benutzer die neue App oder weichen sie aus?
• Business Metrics: Hat sich Durchsatz, Umsatz oder Kundenzufriedenheit geändert?

Automatisiertes Rollback:

Wenn Fehlerrate über 1 % steigt oder Response-Zeit verdoppelt sich → automatisch zurück zum alten System. Das ist nicht Niederlage, das ist Sicherheit.

Praxisbeispiel aus unserem Portfolio:

Ein E-Commerce-Unternehmen mit einer 12-jährigen PHP-Anwendung für Bestellverwaltung. Migration der Bestellverfolgung auf neue React/Node.js-App:

• Woche 1–4: Canary mit 100 internen Benutzern → 0 Fehler
• Woche 5–8: Early Adopter mit 500 Kunden (VIP-Segment) → 0,05 % Fehlerrate (erwartbar)
• Woche 9–12: Mainstream mit 50.000 Kunden → 0,08 % Fehlerrate, stabil
• Woche 13–16: 100 % Migration, altes System nur noch Fallback
• Woche 17–20: Monitoring ohne Fehler, dann Abschaltung des alten Systems

Gesamtdauer: 5 Monate. Ausfallzeit: 0 Minuten. ROI: Wartungskosten sanken um 60 %, neue Features kamen 3 Wochen schneller.

Phase 5: Abschaltung des Legacy-Systems

BLUF: Nachdem die neue App 4–8 Wochen fehlerfrei läuft, können Sie das Legacy-System abschalten. Das ist nicht das Ende – das ist der Anfang der Wartbarkeits-Ära. Dauer: 2–4 Wochen.

Viele Unternehmen machen hier einen Fehler: Sie schalten das alte System sofort ab und speichern es nicht. Dann kommt eine Anfrage nach 6 Monaten: „Können Sie noch auf alte Daten von 2020 zugreifen?" Antwort: Nein, das System ist weg.

Richtige Abschaltungs-Strategie:

1. Archivierung: Das alte System und seine Datenbank werden vollständig dokumentiert und in ein Archiv verschoben (z. B. Cloud-Storage, WORM-Speicher). 2. Read-Only Zugriff: Für weitere 6–12 Monate können Benutzer (über eine Read-Only-Schnittstelle) noch auf alte Daten zugreifen – aber nicht schreiben. 3. Datenmigration: Alle historischen Daten werden in die neue Datenbank migriert und validiert. 4. Dokumentation: Code, Prozesse, Schnittstellen werden dokumentiert – für künftige Wartung oder Audits. 5. Abschaltung: Nach Aufbewahrungsfrist (oft 7 Jahre für Finanzunternehmen) können Sie das System und die Daten löschen.

Checkliste für Abschaltung:

• ☐ Alle Prozesse laufen fehlerfrei in der neuen App (4 Wochen Monitoring)
• ☐ Historische Daten sind vollständig migriert
• ☐ Read-Only-Archiv ist eingerichtet
• ☐ Alle Integrationspunkte mit externen Systemen funktionieren
• ☐ Benutzer-Dokumentation ist aktualisiert
• ☐ Support-Team ist geschult
• ☐ Disaster-Recovery-Plan ist getestet
• ☐ Compliance und Audit-Anforderungen sind erfüllt

---

Infografik 7: Die 5 Phasen des Strangler Pattern Implementierung

• Phase 1: Analyse und Schnittstellen-Kartierung
• Phase 2: Schnittstellen-Extraktion und Proxy-Implementierung
• Phase 3: Neue Komponenten entwickeln
• Phase 4: Schrittweise Migration und Monitoring
• Phase 5: Abschaltung des Legacy-Systems

Infografik: Die 5 Phasen des Strangler Pattern in der Praxis

• Phase 1 (Woche 1–4): Analyse und Schnittstellen-Kartierung – Datenfluss-Analyse, Prozess-Kartierung, Code-Review, Dokumentation sammeln
• Phase 2 (Woche 5–12): Strangler Proxy-Implementierung – API Gateway oder Custom Middleware aufbauen, Request-Routing definieren, Error-Handling einrichten, Monitoring vorbereiten
• Phase 3 (Woche 13–28): Neue Komponenten entwickeln – React/Node.js-Stack, separate Datenbank, Integration mit Proxy, Canary-Tests mit 5 % Benutzer
• Phase 4 (Woche 29–52): Schrittweise Migration – Canary (5 %), Early Adopter (20 %), Mainstream (80 %), 100 %, Fehlerrate unter 0,1 %, automatisches Rollback bei Problemen
• Phase 5 (Woche 53–56): Abschaltung des Legacy-Systems – Read-Only-Archiv einrichten, Daten migrieren, alte Infrastruktur abbauen, Dokumentation finalisieren

Praktische Technologien und Werkzeuge 2026

Kurz: Der Strangler Pattern ist nicht an bestimmte Technologien gebunden – aber es gibt Tools, die die Implementierung 2026 deutlich vereinfachen.

Der Strangler Pattern ist nicht an bestimmte Technologien gebunden – aber es gibt Tools, die die Implementierung 2026 deutlich vereinfachen.

Strangler Proxy: Optionen und Vergleich

1. API Gateway (Cloud-native Lösung)

• AWS API Gateway: Einfach, serverless, skaliert automatisch. Ideal für Microservices.
• Azure API Management: Ähnlich wie AWS, mit guter Azure-Integration. DSGVO-konform für deutsche Unternehmen.
• Kong: Open-Source, selbst gehostet oder managed. Maximale Kontrolle, mehr Konfiguration nötig.

Vergleich:

| Kriterium | AWS API Gateway | Azure API Mgmt | Kong | |-----------|-----------------|-----------------|------| | Setup-Zeit | 1–2 Tage | 2–3 Tage | 1 Woche | | Kosten | Pay-per-Request (günstig bei niedrigem Traffic) | Monatlich (günstiger bei hohem Traffic) | Selbst gehostet (Infrastruktur-Kosten) | | Skalierbarkeit | Unbegrenzt | Unbegrenzt | Abhängig von Ihrem Hosting | | Monitoring | CloudWatch integriert | Azure Monitor integriert | ELK Stack oder ähnlich | | DSGVO | AWS ist DSGVO-konform | Azure ist DSGVO-konform | Abhängig von Hosting |

Empfehlung für 2026: Wenn Sie bereits in AWS oder Azure investiert haben, nutzen Sie deren API Gateway. Wenn nicht, starten Sie mit Kong – es ist Open-Source, kostenlos und hat eine große Community.

Neue Anwendungs-Stack (2026 Best Practices)

Frontend:

• React 19+ oder Next.js 15+ für Web-Apps (mit TypeScript für bessere Wartbarkeit)
• Flutter 4+ oder React Native für Mobile (einmal schreiben, überall laufen)

Backend:

• Node.js 22+ (JavaScript/TypeScript) für schnelle Entwicklung
• Python 3.12+ (FastAPI, Django) für Datenverarbeitung und KI-Integration
• Go für Performance-kritische Komponenten (z. B. Real-Time-Verarbeitung)

Datenbank:

• PostgreSQL 16+ für strukturierte Daten (ACID-Garantien, JSONB für flexible Schemas)
• MongoDB 7+ für unstrukturierte Daten (Skalierbarkeit, flexible Schemas)
• Redis 7+ für Caching und Sessions (Geschwindigkeit)

Infrastruktur:

• Docker für Containerisierung (Standard 2026)
• Kubernetes oder AWS ECS/Fargate für Orchestrierung
• GitHub Actions oder GitLab CI/CD für automatisierte Deployments

Monitoring und Observability:

• Prometheus + Grafana für Metriken (Open-Source, kostenlos)
• ELK Stack (Elasticsearch, Logstash, Kibana) oder Datadog für Logs und Tracing
• PagerDuty oder Opsgenie für Alerting

Integration mit bestehenden Systemen

Wenn Ihre Legacy-App mit anderen Systemen integriert ist (ERP, CRM, Datenbank), müssen Sie diese Integrationen auch in die neue App bringen.

Optionen:

1. Direkte API-Integration: Die neue App spricht direkt mit dem externen System (z. B. REST-API zu SAP, Salesforce). 2. Message Queue (Kafka, RabbitMQ): Asynchrone Kommunikation. Die alte App schreibt Events, die neue App konsumiert sie. 3. ETL-Tools: Für regelmäßige Datensynchronisierung (z. B. Talend, Apache NiFi). 4. iPaaS-Plattformen: Für schnelle, Low-Code-Integration (z. B. MuleSoft, Boomi).

Empfehlung: Nutzen Sie API-Entwicklung und REST-Schnittstellen als Standardansatz. Das ist zukunftssicher, wartbar und dokumentierbar.

---

Infografik: Technologie-Stack für Strangler Pattern Projekte 2026

• Frontend-Schicht: React 19+ oder Next.js 15+ für Web, Flutter 4+ für Mobile – TypeScript für Typsicherheit, moderne Build-Tools (Vite, Webpack 5+)
• Backend-Schicht: Node.js 22+ (Express, NestJS) oder Python 3.12+ (FastAPI) – REST APIs oder GraphQL, Authentifizierung (JWT, OAuth2)
• Datenbank-Schicht: PostgreSQL 16+ (Primary), MongoDB 7+ (Optional), Redis 7+ (Cache) – Separate DB vom Legacy-System, Event Sourcing für Sync
• Infrastruktur: Docker + Kubernetes oder AWS ECS/Fargate – Multi-Zone Deployment, Auto-Scaling, Load Balancing
• Strangler Proxy: AWS API Gateway oder Kong – Request-Routing, Rate Limiting, Logging, Error Handling
• Monitoring: Prometheus + Grafana, ELK Stack, Datadog – Fehlerrate, Response-Zeit, Datenkonsistenz, User Adoption

Häufige Fallstricke und wie Sie diese vermeiden

Kurz: Der Strangler Pattern ist bewährt – aber es gibt Fallstricke, die Projekte verzögern oder zum Scheitern bringen.

Der Strangler Pattern ist bewährt – aber es gibt Fallstricke, die Projekte verzögern oder zum Scheitern bringen. Hier sind die häufigsten und wie Sie sie vermeiden.

Fallstrick 1: Unzureichende Schnittstellen-Dokumentation

Problem: Das Legacy-System hat keine Dokumentation. Sie wissen nicht genau, welche Datenformate die alten Schnittstellen verwenden, welche Validierungsregeln gelten oder welche Edge-Cases es gibt.

Folge: Bei der Migration finden Sie Fehler, die Sie nicht erwartet haben. Der neue Code bricht, weil ein Feld optional sein kann, das Sie für Pflicht hielten.

Lösung:

1. Reverse Engineering: Code-Analyse, um Schnittstellen zu verstehen. Tools wie SonarQube oder Understand helfen dabei. 2. Automatisierte Tests: Schreiben Sie Tests gegen das alte System, um sein Verhalten zu dokumentieren. Diese Tests werden dann gegen die neue App ausgeführt. 3. Smoke Tests: Einfache, automatisierte Tests, die häufige Szenarien abdecken. Diese laufen täglich und warnen Sie vor Problemen.

Beispiel: Ein Versicherungsunternehmen mit einer 20-jährigen Mainframe-App.

Wir haben 50 Smoke Tests geschrieben, die täglich gegen das alte System laufen.

Jeder dieser Tests dokumentiert ein Verhalten: „Wenn Kundennummer leer, dann Fehler 404." Diese Tests sind dann die Spezifikation für die neue App.

Fallstrick 2: Zu schnelle Abschaltung des Legacy-Systems

Problem: Nach 4 Wochen ohne Fehler denken Sie: „Das alte System können wir jetzt abschalten." Sie schalten es ab – und 2 Wochen später kommt eine Anfrage nach einer Funktion, die Sie übersehen haben.

Folge: Panik, manuelles Rollback, Vertrauensverlust.

Lösung:

1. Längere Monitoring-Phase: Nicht 4 Wochen, sondern 8–12 Wochen ohne Fehler, bevor Sie das alte System abschalten. 2. Read-Only Modus: Das alte System läuft noch, aber nur für Lesezugriffe. So können Sie schnell auf vergessene Daten zugreifen. 3. Archiv-Strategie: Bevor Sie das System abschalten, archivieren Sie es vollständig. So können Sie später noch darauf zugreifen, falls nötig.

Faustregel: Mindestens 8 Wochen ohne Fehler, plus 8 Wochen Read-Only-Modus. Dann können Sie das System abschalten.

Fallstrick 3: Fehlende Parallel-Tests

Problem: Sie testen die neue App isoliert, aber nicht gegen echte Daten und echte Last aus dem Legacy-System.

Folge: Die neue App läuft schön in der Testumgebung, aber in Produktion mit echten Daten bricht sie zusammen.

Lösung:

1. Daten-Replikation: Kopieren Sie Produktionsdaten in eine Test-Umgebung. Testen Sie gegen diese echten Daten. 2. Load-Testing: Simulieren Sie echte Last. Tools wie JMeter oder Gatling helfen dabei. 3. Chaos Engineering: Simulieren Sie Fehler (z. B. Datenbankausfälle). Wie reagiert die neue App? Kann sie sich erholen?

Konkret: Für den Strangler Pattern empfehlen wir, parallel zum Legacy-System zu testen:

• Die alte App bearbeitet eine Anfrage
• Die neue App bearbeitet die gleiche Anfrage
• Sie vergleichen die Ergebnisse

Wenn sie identisch sind, ist die neue App ready. Das nennt sich „Shadow Testing" oder „Dual Read".

Fallstrick 4: Unzureichende Datensynchronisierung

Problem: Neue und alte App haben separate Datenbanken. Anfangs synchronisieren Sie Daten manuell oder mit einfachen Batch-Jobs. Aber was passiert, wenn die alte App schreibt, während die neue App liest? Oder umgekehrt?

Folge: Datenkonsistenz-Fehler. Benutzer sehen unterschiedliche Daten in der alten und neuen App.

Lösung:

1. Change Data Capture (CDC): Tools wie Debezium beobachten die alte Datenbank und schreiben Änderungen in eine Message Queue. Die neue App konsumiert diese Events und synchronisiert sich selbst. 2. Event Sourcing: Statt Daten zu replizieren, replizieren Sie Events. Die alte App schreibt Events in Kafka, die neue App konsumiert sie und baut ihren Zustand auf. 3. Transaktionale Outbox: Die alte App schreibt in ihre Datenbank UND in eine Outbox-Tabelle. Ein separater Process liest die Outbox und schreibt in die Message Queue. So garantieren Sie, dass Daten nicht verloren gehen.

Best Practice 2026: Nutzen Sie Debezium + Kafka. Das ist der Standard für Datensynchronisierung bei Legacy-Modernisierung. Open-Source, zuverlässig, skalierbar.

Fallstrick 5: Fehlende Governance und Dokumentation

Problem: Das Projekt läuft, aber niemand weiß genau, welche Prozesse schon migriert sind, welche noch fehlen, wer für was verantwortlich ist.

Folge: Doppelte Arbeit, verpasste Deadlines, Frustration.

Lösung:

1. Migrations-Tracker: Ein einfaches Spreadsheet oder ein Tool wie Jira, das zeigt: Prozess A (50 % migriert), Prozess B (100 % migriert), Prozess C (0 % migriert). 2. Dokumentation: Für jeden migrierten Prozess: Was hat sich geändert? Wie testen Benutzer? Wo sind die Fallstricke? 3. Regelmäßige Reviews: Wöchentliche oder zweiwöchentliche Meetings mit Stakeholdern. Status, Blockers, nächste Schritte.

Konkret: Wir nutzen ein einfaches Modell:

• Geplant: Prozess ist identifiziert, aber nicht gestartet
• In Entwicklung: Code wird geschrieben
• In Test: Canary oder Early Adopter
• In Produktion: 100 % migriert, altes System ist Fallback
• Abgeschaltet: Altes System läuft nicht mehr

Dieser Status wird täglich aktualisiert und in Meetings diskutiert.

---

Infografik 8: Häufige Fallstricke und wie Sie diese vermeiden

• Fallstrick 1: Unzureichende Schnittstellen-Dokumentation
• Fallstrick 2: Zu schnelle Abschaltung des Legacy-Systems
• Fallstrick 3: Fehlende Parallel-Tests
• Fallstrick 4: Unzureichende Datensynchronisierung
• Fallstrick 5: Fehlende Governance und Dokumentation

Infografik: Häufige Fallstricke und Vermeidungsstrategien

• Fallstrick 1 – Unzureichende Dokumentation: Lösung: Reverse Engineering, automatisierte Smoke Tests gegen altes System, Tests als Spezifikation für neue App
• Fallstrick 2 – Zu schnelle Abschaltung: Lösung: Mindestens 8 Wochen Monitoring ohne Fehler, Read-Only Modus für 8 Wochen, vollständige Archivierung vor Abschaltung
• Fallstrick 3 – Fehlende Parallel-Tests: Lösung: Produktionsdaten in Test-Umgebung kopieren, Load-Testing mit JMeter/Gatling, Shadow Testing (alte und neue App parallel)
• Fallstrick 4 – Datensynchronisierung-Fehler: Lösung: Change Data Capture (Debezium), Event Sourcing oder Transactional Outbox Pattern, Kafka für Message Queue
• Fallstrick 5 – Fehlende Governance: Lösung: Migrations-Tracker (Jira/Spreadsheet), Dokumentation für jeden Prozess, wöchentliche Stakeholder-Reviews, klare Status-Definition

Infografik: Monitoring und Rollback-Strategie während der Migration

• Fehlerrate: Sollte nicht über 0,1 % steigen; automatisches Rollback bei 1 % – Monitoring via Prometheus/Grafana, Alerting via PagerDuty
• Response-Zeit: Neue App darf nicht langsamer sein als alte; P95-Latenz sollte gleich bleiben – Gemessen mit APM-Tools (New Relic, Datadog)
• Datenkonsistenz: Stichproben-Checks: Sind Daten zwischen neuem und altem System identisch? – Automatisierte Validierungs-Skripte täglich
• User Adoption: Wie viele Benutzer nutzen die neue App? Gibt es Widerstände? – Nutzer-Feedback sammeln, A/B-Testing durchführen
• Business Metrics: Hat sich Durchsatz, Umsatz, oder Kundenzufriedenheit geändert? – Dashboards für KPIs (Bestellungen/Tag, Fehlerquote, Support-Tickets)
• Automatisches Rollback: Wenn Fehlerrate über 1 % oder Response-Zeit verdoppelt sich → sofort zurück zum alten System – Konfiguriert im Strangler Proxy, keine manuellen Schritte

Schritt für Schritt: Strangler Pattern in 7 Schritten implementieren

Kurz: Wenn Sie heute mit der Modernisierung Ihres Legacy-Systems starten wollen, folgen Sie dieser bewährten Anleitung.

Wenn Sie heute mit der Modernisierung Ihres Legacy-Systems starten wollen, folgen Sie dieser bewährten Anleitung. Jeder Schritt hat klare Ziele und Deliverables.

1. Audit und Schnittstellen-Analyse (Woche 1–4)

Verstehen Sie, wie das System funktioniert. Führen Sie ein Audit durch:

• Wie alt ist der Code? In welcher Sprache?
• Welche Datenbanken sind angebunden?
• Welche externen Systeme integriert?
• Wo sind die Performance-Probleme?
• Welche Prozesse sind kritisch?

Deliverable: Ein detailliertes Architektur-Diagramm und eine Priorisierung der Prozesse nach Kritikalität und Aufwand.

2. Strangler Proxy aufbauen (Woche 5–8)

Wählen Sie eine Proxy-Lösung und bauen Sie sie auf. Starten Sie mit einfachem Routing:

• Request kommt rein
• Basierend auf URL/Header wird entschieden: Alte oder neue App?
• Request wird weitergeleitet
• Response kommt zurück

Deliverable: Ein funktionierender Proxy, der 100 % des Traffics durch die alte App routet. Kein neuer Code läuft noch, aber die Infrastruktur ist da.

3. Erste neue Komponente entwickeln (Woche 9–20)

Wählen Sie einen Prozess mit hohem ROI und niedrigen Abhängigkeiten. Bauen Sie ihn in modernen Technologien neu:

• Anforderungen sammeln
• Design und Architektur
• Entwicklung
• Testing
• Integration mit Strangler Proxy

Deliverable: Eine neue Komponente, die 100 % funktioniert und 100 % getestet ist.

4. Canary Deployment starten (Woche 21–24)

Leiten Sie 5 % des Traffics zur neuen Komponente um. Überwachen Sie intensiv:

• Fehlerrate
• Response-Zeit
• User Feedback
• Datenkonsistenz

Wenn alles ok ist nach 2 Wochen: Weiter zu Schritt 5. Wenn nicht: Rollback und Fixes.

Deliverable: Grünes Licht für die nächste Phase.

5. Early Adopter Phase (Woche 25–32)

Erhöhen Sie auf 20 % Traffic. Das sind oft interne Benutzer oder vertraute Kunden. Wieder 2 Wochen Monitoring.

Deliverable: Validierung, dass die Komponente auch bei höherer Last stabil ist.

6. Mainstream Rollout (Woche 33–40)

Erhöhen Sie auf 80 % Traffic. Die Mehrheit der Benutzer nutzt jetzt die neue App. Das alte System ist nur noch Fallback.

Deliverable: Vollständige Migration dieser Komponente.

7. Abschaltung und nächste Komponente (Woche 41–44)

Nach 4 Wochen ohne Fehler:

• Schalten Sie die alte Komponente in Read-Only-Modus um
• Archivieren Sie den Code und die Daten
• Starten Sie die nächste Komponente

Deliverable: Eine abgeschaltete alte Komponente, eine archivierte Datenbank, und der Anfang der nächsten Migration.

Zeitrahmen: Für eine mittelgroße Anwendung (5–10 Prozesse) dauert dieser Zyklus 1–2 Jahre. Für jede neue Komponente wiederholen Sie die Schritte 3–7.

---

Infografik: 7-Schritt-Anleitung für Strangler Pattern Implementierung

• Schritt 1 (Woche 1–4): Audit und Schnittstellen-Analyse – Architektur-Diagramm erstellen, Prozesse nach Kritikalität priorisieren, Performance-Probleme identifizieren
• Schritt 2 (Woche 5–8): Strangler Proxy aufbauen – API Gateway oder Kong aufsetzen, Routing-Regeln definieren, 100 % Traffic durch Proxy routet (noch alles zur alten App)
• Schritt 3 (Woche 9–20): Erste neue Komponente entwickeln – React/Node.js Stack, separate Datenbank, vollständige Tests, Integration mit Proxy
• Schritt 4 (Woche 21–24): Canary Deployment (5 % Traffic) – Intensives Monitoring, Fehlerrate unter 0,1 %, automatisches Rollback konfiguriert
• Schritt 5 (Woche 25–32): Early Adopter Phase (20 % Traffic) – Interne Benutzer oder vertraute Kunden, Validierung bei höherer Last, User Feedback sammeln
• Schritt 6 (Woche 33–40): Mainstream Rollout (80 % Traffic) – Mehrheit der Benutzer, altes System nur noch Fallback, Monitoring läuft 24/7
• Schritt 7 (Woche 41–44): Abschaltung und Archivierung – Read-Only-Modus, Code und Daten archivieren, nächste Komponente starten

Vor- und Nachteile des Strangler Pattern: Eine ehrliche Bewertung

Kurz: Der Strangler Pattern ist nicht die Lösung für jedes Problem.

Der Strangler Pattern ist nicht die Lösung für jedes Problem. Hier ist eine ehrliche Bewertung, damit Sie entscheiden können, ob er für Ihr Projekt passt.

Vorteile

1. Minimales Ausfallrisiko

• Sie fahren das alte System nicht ab, bis die neue App 100 % funktioniert
• Rollback ist einfach: Proxy leitet wieder auf alte App um
• Benutzer merken fast nichts von der Migration

2. Inkrementelle Kosten und Risiken

• Statt 2 Mio. Euro Großprojekt: 150.000 Euro pro Quartal für 2 Jahre
• Budgetierbar, planbar, anpassbar
• Wenn das Projekt scheitert, haben Sie nicht 100 % verloren

3. Kontinuierliche Geschäftstätigkeit

• Keine Abschaltzeiten
• Neue Features können während der Migration ausgerollt werden
• Geschäft läuft weiter wie normal

4. Schrittweise Wissensaufbau

• Sie verstehen das alte System besser, während Sie es migrieren
• Domänenwissen wird externalisiert (Tests, Dokumentation)
• Weniger Überraschungen

5. Moderne Tech-Stacks

• Sie können neue Frameworks, Programmiersprachen und Cloud-Infrastruktur einführen
• Bessere Talentgewinnung (Entwickler wollen moderne Tech)
• Bessere Wartbarkeit und Performance

Nachteile

1. Längere Gesamtdauer

• Statt 18 Monaten Big-Bang: 24–36 Monate Strangler Pattern
• Das alte System läuft länger parallel, kostet Geld
• Für Geschäftsführer unbefriedigend: „Warum dauert das so lange?"

2. Höhere Komplexität während der Migration

• Sie haben zwei Systeme, die synchronisiert werden müssen
• Datensynchronisierung ist fehleranfällig
• Debugging ist schwerer (Fehler können aus altem oder neuem System kommen)

3. Höhere Infrastruktur-Kosten (temporär)

• Während der Migration laufen zwei Systeme parallel
• Das kostet doppelte Infrastruktur, doppelte Lizenzen (manchmal)
• Nach der Migration sinken die Kosten wieder – aber während der Migration sind sie höher

4. Erfordert Disziplin und Governance

• Sie können nicht einfach Code schreiben und hoffen
• Sie brauchen klare Prozesse, Monitoring, Rollback-Pläne
• Wenn Governance fehlt, wird das Projekt chaotisch

5. Nicht ideal für sehr alte Systeme

• Wenn das alte System völlig undokumentiert ist und niemand versteht, wie es funktioniert
• Wenn Schnittstellen nicht existieren und schwer zu extrahieren sind
• Dann kann Big-Bang einfacher sein (aber riskanter)

Fazit: Wann passt der Strangler Pattern?

Ideal für:

• Produktive Systeme, die 24/7 laufen müssen (E-Commerce, Finanzdienstleistungen, Gesundheitswesen)
• Systeme mit stabilen, dokumentierten Schnittstellen
• Unternehmen, die kein großes Risiko tragen können
• Projekte mit Budgetbeschränkungen

Nicht ideal für:

• Systeme, die sowieso abgeschaltet werden können (z. B. interne Tools, die durch ein ERP-System ersetzt werden)
• Sehr kleine Systeme (Lassen Sie uns gemeinsam Ihr Legacy-System in eine moderne, wartbare Anwendung umwandeln – mit minimalem Risiko und maximaler Geschäftskontinuität.

Fachquellen und weiterführende Links

Kurz: Die folgenden unabhängigen Referenzen ergänzen die Einordnung zu den Themen dieses Artikels:

Die folgenden unabhängigen Referenzen ergänzen die Einordnung zu den Themen dieses Artikels:

• Bitkom – Verband der Digitalwirtschaft
• BSI – Bundesamt für Sicherheit in der Informationstechnik
• Europäische Kommission – Digitale Strategie
• MDN Web Docs (Mozilla)
• W3C – World Wide Web Consortium

"ERP-Projekte scheitern selten an der Softwareliste, sondern an unklaren Prozessgrenzen und fehlender Fachverantwortung im Projekt."

— Björn Groenewold, Geschäftsführer, Groenewold IT Solutions