Legacy-Modernisierung ohne Big-Bang: Das Strangler-Fig-Pattern
Pragmatische Strategie für IT-Entscheider im Mittelstand zur risikoarmen Modernisierung von 15-20 Jahre alten ERP- und Legacy-Systemen. Schrittweise Migration ohne Business-Disruption, mit ROI-Kalkulation und Change-Management-Framework.
Legacy-Modernisierung ohne Big-Bang: Das Strangler-Fig-Pattern
Sie sind IT-Entscheider in einem erfolgreichen mittelständischen Unternehmen. Ihr ERP-System ist 18 Jahre alt. Es läuft. Es ist stabil. Aber: Jede Änderung dauert Monate. Neue Features sind unmöglich. Die Wartungskosten explodieren. Und die wenigen Entwickler, die das System noch verstehen, gehen in Rente.
Der Vorstand drängt auf "Digitalisierung". Die Fachabteilungen fordern neue Features. Die Wettbewerber sind agiler. Und Sie wissen: Wir müssen modernisieren – aber wie, ohne das Business zu gefährden?
Der große Big-Bang-Rewrite? Riskant. Teuer. Dauert 3-5 Jahre. Und die Erfolgsquote liegt bei unter 30%. Das können Sie sich nicht leisten.
Die Alternative? Das Strangler-Fig-Pattern – eine bewährte Strategie für schrittweise, risikoarme Legacy-Modernisierung. Benannt nach einer Pflanzenart (Würgefeige), die langsam einen alten Baum umschließt, bis dieser ersetzt ist.
In diesem Artikel zeige ich Ihnen, wie Sie Ihre Legacy-Systeme pragmatisch modernisieren – ohne Business-Disruption, mit messbarem ROI, und Zustimmung vom Vorstand.
Das Problem: Warum Legacy-Systeme zum Albtraum werden
Die Symptome des Legacy-Albtraums
Technisch:
- Veraltete Technologie: COBOL, Visual Basic 6, PowerBuilder, SAP R/3 von 2005
- Keine Dokumentation: Der ursprüngliche Architekt ist vor 10 Jahren gegangen
- Monolithische Architektur: Ein 500.000-Zeilen-Codebase, alles miteinander verwoben
- Keine Tests: Jede Änderung ist ein russisches Roulette
- Deployment-Angst: Production-Releases nur nachts, mit allen Entwicklern on-call
Geschäftlich:
- Feature-Entwicklung: 9-12 Monate für neue Features (Konkurrenten: 2-3 Wochen)
- Wartungskosten: 70-80% des IT-Budgets gehen in "Keeping the lights on"
- Vendor-Lock-in: €1.2M/Jahr an einen Legacy-Dienstleister, der Sie nicht gehen lassen will
- Compliance-Risiken: DSGVO, NIS2, ISO-27001 – schwer umsetzbar auf altem System
- Recruiting: Kein junger Entwickler will mit 20 Jahre alter Technologie arbeiten
Organisatorisch:
- Wissenssilos: Nur 2-3 Personen verstehen kritische Module
- Change-Resistance: "Wir ändern das System nicht, es könnte kaputtgehen"
- Business-Abhängigkeit: Das Legacy-System IST das Business – Ausfall = Katastrophe
Warum der Big-Bang-Rewrite keine Lösung ist
Die Verlockung ist groß: "Wir schreiben alles neu. In 2 Jahren haben wir ein modernes System."
Die Realität:
- Projekte dauern 2-3x länger als geplant: Aus 2 Jahren werden 5 Jahre
- Kosten explodieren: €3M Budget werden €8M
- Erfolgsquote: 28%: 72% der Big-Bang-Rewrites scheitern oder liefern nicht den versprochenen Wert
- Business-Disruption: Während der Entwicklung? Keine neuen Features. Nur "Warten auf das neue System"
Warum scheitern Big-Bang-Rewrites?
- Moving Target: Das Business ändert sich während der Entwicklung. Nach 3 Jahren ist Ihr neues System bereits veraltet.
- Unterschätzte Komplexität: Legacy-Systeme haben 20 Jahre gewachsene Business-Logik. Vieles ist undokumentiert. Sie entdecken Komplexität erst beim Rewrite.
- Zweimal bezahlen: Sie bezahlen für Wartung des alten Systems UND Entwicklung des neuen – parallel, für Jahre.
- Organisatorischer Widerstand: Die Organisation muss sich auf einmal komplett umstellen. Überfordung garantiert.
Es gibt einen besseren Weg.
Das Strangler-Fig-Pattern: Konzept & Vorteile
Was ist das Strangler-Fig-Pattern?
Das Pattern ist benannt nach der Würgefeige (Strangler Fig), einer tropischen Pflanze:
- Ein Vogel lässt einen Samen auf einem Baum fallen
- Der Samen wächst und schlingt sich um den Baum
- Über Jahre hinweg umschließt die Feige den alten Baum vollständig
- Der alte Baum stirbt ab und wird durch die Feige ersetzt
- Die Feige steht alleine – mit derselben Form wie der alte Baum
Übersetzung auf Software:
- Das neue System wächst schrittweise um das alte herum
- Feature für Feature wird vom alten zum neuen System migriert
- Während der Migration funktioniert beides parallel
- Wenn das alte System leer ist, schalten Sie es ab
- Das neue System hat alle Features des alten – plus neue Möglichkeiten
Die 4 Kern-Prinzipien
1. Inkrementell, nicht Big-Bang
Statt:
- "Wir migrieren alles auf einmal in 3 Jahren"
Machen Sie:
- "Wir migrieren ein Modul/Feature pro Quartal, über 3-5 Jahre"
Vorteil: Risiko ist verteilt. Jeder Schritt ist überschaubar und reversibel.
2. Parallel-Betrieb (Koexistenz)
Statt:
- "Am Go-Live-Tag schalten wir vom alten auf neues System um"
Machen Sie:
- "Alte und neue Systeme laufen parallel, kommunizieren über APIs"
Vorteil: Kein plötzlicher Umstieg. Graduelle Migration. Rollback jederzeit möglich.
3. Business-Value first
Statt:
- "Wir migrieren technisch sinnvoll (Datenbank zuerst, dann Backend, dann Frontend)"
Machen Sie:
- "Wir migrieren die Module, die den höchsten Business-Value oder das größte Risiko haben"
Vorteil: ROI ist frühzeitig sichtbar. Vorstand sieht Fortschritt, nicht nur Kosten.
4. API-First (Fassade)
Statt:
- "Direkter Zugriff auf Datenbanken/Module"
Machen Sie:
- "Alle Zugriffe über APIs. APIs können auf altes oder neues System routen"
Vorteil: Flexibilität. Sie können Backend austauschen ohne Frontend zu ändern.
Die Architektur: Wie es funktioniert
┌─────────────────────────────────────────────────────┐
│ Benutzer │
└───────────────────┬─────────────────────────────────┘
│
┌───────────────────▼─────────────────────────────────┐
│ API-Gateway / Fassade │
│ (Routing-Logik: Alt oder Neu? Feature-Flags) │
└───────┬────────────────────────────┬────────────────┘
│ │
┌───────▼────────────┐ ┌──────────▼─────────────┐
│ Legacy-System │ │ Neues System │
│ (ERP, Monolith) │◄───┤ (Microservices, │
│ │ │ Cloud-Native) │
│ - Module A (alt) │ │ - Module C (neu) │
│ - Module B (alt) │ │ - Module D (neu) │
└────────────────────┘ └────────────────────────┘
│ │
┌────▼─────┐ ┌────▼────┐
│ Legacy │ │ Neue │
│ DB │◄─────────────┤ DB │
└──────────┘ Sync/ETL └─────────┘
Key Components:
- API-Gateway/Fassade: Entscheidet, ob Request an alt oder neu geht
- Feature-Flags: Granulare Kontrolle (z.B. "User-Gruppe A nutzt neu, B nutzt alt")
- Daten-Synchronisation: Bi-direktional während Übergangsphase
- Monitoring: Beide Systeme gleichzeitig überwachen
Die 6-Phasen-Roadmap zur Legacy-Modernisierung
Phase 1: Assessment & Business-Case (4-6 Wochen)
Ziel: Verstehen, was Sie haben, und überzeugen Sie den Vorstand.
Aktivitäten:
Legacy-System-Inventur:
- Welche Module/Features gibt es?
- Welche sind geschäftskritisch?
- Wo ist technische Schuld am höchsten?
- Wer versteht noch welchen Teil?
Dependency-Mapping:
- Welche Module hängen voneinander ab?
- Wo sind die größten Kopplungen?
- Welche Schnittstellen existieren bereits?
Risiko-Assessment:
- Compliance-Risiken (DSGVO, NIS2, ISO-27001)
- Business-Continuity-Risiken (Was passiert, wenn System X ausfällt?)
- Vendor-Lock-in-Risiken (Abhängigkeit von alten Dienstleistern)
- Wissens-Risiken (Nur Person Y versteht Modul Z)
Business-Case erstellen:
Kosten des Status Quo (über 5 Jahre):
- Wartungskosten: €6M (€1.2M/Jahr)
- Opportunity-Kosten: €4M (verloren durch Agilität-Mangel)
- Compliance-Risiken: €2M (potenzielle Strafen)
- TOTAL: €12M
Kosten der Modernisierung (über 5 Jahre):
- Modernisierungs-Projekt: €4M
- Parallel-Betrieb: €1M
- Training & Change-Management: €500k
- TOTAL: €5.5M
NET BENEFIT: €6.5M über 5 Jahre
Deliverable: 40-Seiten Business-Case-Dokument für Vorstand, mit Risiko-Analyse und ROI-Kalkulation.
Phase 2: Strategische Planung (4-6 Wochen)
Ziel: Definieren Sie die Ziel-Architektur und Migrations-Sequenz.
Aktivitäten:
Ziel-Architektur skizzieren:
- Cloud-Strategie (AWS/Azure/GCP oder Hybrid?)
- Microservices vs. Modular Monolith?
- Technologie-Stack (z.B. .NET Core, Java Spring, Node.js)
- Datenbank-Strategie (SQL, NoSQL, Event-Sourcing?)
Migrations-Sequenz festlegen:
Priorisierung nach:
- Business-Value: Welche Module liefern schnellsten ROI?
- Risiko: Welche Module sind am kritischsten/fragil?
- Abhängigkeiten: Welche Module können isoliert migriert werden?
Beispiel-Sequenz (E-Commerce ERP):
| Phase | Modul | Warum zuerst? | Dauer | Kosten |
|---|---|---|---|---|
| 1 | Produkt-Katalog-API | Hoher Business-Value (neue Features möglich), niedrige Komplexität | 3 Monate | €150k |
| 2 | Order-Management (Neu-Orders) | Geschäftskritisch, aber nur neue Orders migrieren | 4 Monate | €200k |
| 3 | CRM-Integration (Neu) | Vendor-Lock-in eliminieren, hohe Kosten sparen | 3 Monate | €120k |
| 4 | Reporting & Analytics | Legacy-System kann nicht, neue Möglichkeiten schaffen | 5 Monate | €180k |
| 5 | Historische Order-Migration | Risiko niedrig, Daten-Migration | 6 Monate | €250k |
| 6 | Legacy-System-Decommission | Finale Ablösung | 2 Monate | €100k |
Total: 23 Monate, €1M
- API-Strategie definieren:
- Welche APIs brauchen Sie?
- REST vs. GraphQL vs. gRPC?
- API-Gateway-Technologie (Kong, AWS API Gateway, Azure APIM?)
- Authentication/Authorization (OAuth2, SAML?)
Deliverable: 60-Seiten Architektur-Dokument mit Ziel-State, Migrations-Roadmap, und Technologie-Entscheidungen.
Phase 3: Pilot-Projekt (8-12 Wochen)
Ziel: Proof-of-Concept mit einem nicht-kritischen Modul. Lernen & Iterieren.
Warum Pilot?
- Risiko minimieren: Wenn es scheitert, ist der Schaden begrenzt
- Learnings sammeln: Welche Challenges gibt es wirklich?
- Team-Training: Neue Technologien in geschütztem Umfeld lernen
- Vorstand überzeugen: Greifbarer Fortschritt, nicht nur Theorie
Pilot-Kriterien:
- Nicht-geschäftskritisch: Wenn es schief geht, bricht nicht das Business zusammen
- Überschaubare Komplexität: 2-3 Monate Entwicklung
- Messbar: Klare Success-Metriken (z.B. "10x schnellere Datei-Verarbeitung")
- Sichtbar: Etwas, das der Vorstand/Fachabteilungen sehen können
Beispiel-Pilot: Produkt-Katalog-API
Vorher:
- Produkt-Daten im Legacy-ERP, XML-Export über Nacht
- Änderungen dauern 24h, bis sie in E-Commerce-Shop sichtbar sind
- Keine Bilder, keine Rich-Content
Pilot-Scope:
- Neue API auf Azure Functions (serverless)
- Liest Produkt-Daten aus Legacy-ERP (über existierende Schnittstelle)
- Reichert an mit Bildern aus Azure Blob Storage
- Liefert an E-Commerce-Shop via REST-API
- Real-Time-Updates (< 1 Minute statt 24h)
Ergebnisse nach 12 Wochen:
- ✅ API läuft produktiv
- ✅ 95% schnellere Updates (24h → 1 Minute)
- ✅ Neue Features möglich (Rich-Content, Bilder)
- ✅ €40k/Jahr Kosten gespart (alte Batch-Jobs eliminiert)
- ✅ Vorstand begeistert: "So schnell haben wir noch nie Features geliefert"
Learnings:
- Daten-Synchronisation war komplexer als gedacht (aber machbar)
- Team brauchte 2 Wochen Training in Azure
- Monitoring-Setup dauerte länger als erwartet
- Aber: Pilot war ein voller Erfolg
Phase 4: Iterative Migration (12-36 Monate)
Ziel: Modul für Modul migrieren, basierend auf Learnings vom Pilot.
Rhythmus:
- Quartalsweise Releases: Alle 3 Monate geht ein neues Modul live
- Parallel-Betrieb: Alt und neu laufen parallel während Migration
- Feature-Flags: Graduelle Umstellung (erst 10% Traffic, dann 50%, dann 100%)
- Monitoring: Beide Systeme gleichzeitig überwachen
Beispiel: Order-Management-Migration
Woche 1-4: Vorbereitung
- API-Design für Order-Service
- Datenbank-Schema für neue Orders
- Sync-Mechanismus Legacy ↔ Neu
Woche 5-12: Entwicklung
- Order-Service implementieren
- Testing (Unit, Integration, E2E)
- Security-Review, Compliance-Check
Woche 13-14: Deployment & Pilot
- Deploy zu Production (parallel zu Legacy)
- Feature-Flag: 5% des Traffics auf neues System
- Monitoring: Vergleich Alt vs. Neu
Woche 15-16: Rollout
- Feature-Flag: 25% → 50% → 100%
- Bei jedem Schritt: Monitoring, Incident-Response bereit
- Rollback-Plan bereit (falls kritische Issues)
Woche 17-20: Stabilisierung
- Bug-Fixes, Performance-Tuning
- User-Feedback sammeln und umsetzen
- Documentation & Runbooks
Result:
- Neues Order-System läuft produktiv
- Legacy-Order-System läuft parallel (für historische Orders)
- Business-Continuity garantiert
Phase 5: Daten-Migration (variiert, oft 6-12 Monate)
Ziel: Historische Daten vom alten ins neue System migrieren.
Herausforderungen:
- Datenvolumen: 20 Jahre Daten = Terabytes
- Daten-Qualität: Inkonsistenzen, Duplikate, fehlende Werte
- Downtime-Vermeidung: Migration ohne Business-Disruption
- Daten-Transformation: Altes Schema ≠ Neues Schema
Strategie:
Phase 5a: Data-Cleansing (vorab, parallel)
- Identifizieren: Welche Daten sind wichtig? (80/20-Regel: 20% der Daten werden 80% genutzt)
- Cleansing: Duplikate entfernen, Inkonsistenzen fixen
- Archivierung: Selten genutzte Daten archivieren (z.B. Orders > 10 Jahre alt)
Phase 5b: Bulk-Migration (off-peak, schrittweise)
- Wochenenden/Nachts: Bulk-Daten-Transfers
- Inkrementelle Migration: Nicht alles auf einmal
- Validation: Automated checks (Anzahl Records, Checksums)
Phase 5c: Delta-Sync (während Parallel-Betrieb)
- Continuous sync: Änderungen in Legacy → replizieren zu Neu
- Bi-direktional (falls nötig): Neu → Legacy (während Transition)
Example: Order-History-Migration
- 2.5M historische Orders (18 Jahre)
- Priorisierung: Orders der letzten 3 Jahre (80% der Anfragen)
- Strategie:
- Woche 1-2: Migriere Orders Jahr 2022-2024 (300k Orders)
- Woche 3-4: Migriere Orders Jahr 2020-2021 (200k Orders)
- Woche 5-8: Migriere Orders Jahr 2015-2019 (1M Orders, parallel, niedrige Prio)
- Woche 9+: Archiviere Orders < 2015 (1M Orders, Read-Only-Archive)
Result: 80% der relevanten Daten in 4 Wochen, 100% in 8 Wochen, ohne Downtime.
Phase 6: Legacy-Decommission (2-4 Monate)
Ziel: Das alte System endgültig abschalten.
Aktivitäten:
Finale Validation:
- Alle Features im neuen System?
- Alle Daten migriert?
- Alle Integrationen funktionieren?
Stakeholder-Sign-Off:
- Fachabteilungen: "Wir können mit neuem System arbeiten"
- Compliance-Officer: "Alle Anforderungen erfüllt"
- Vorstand: "ROI wie versprochen geliefert"
Abschaltung:
- Grace-Period: 3 Monate Read-Only (falls Rollback nötig)
- Nach Grace-Period: Vollständige Abschaltung
- Hardware/Lizenzen kündigen
Celebration:
- Interne Communication: "Wir haben es geschafft!"
- Lessons-Learned-Dokument
- Team feiern (Bonus, Team-Event)
Change-Management: Die Organisation mitnehmen
Technische Migration ist nur 30% der Arbeit. Organisatorisches Change-Management ist 70%.
Die 4 Widerstände
1. "Das alte System funktioniert doch"
Realität: Ja, für Status Quo. Aber nicht für Zukunft.
Überwinden:
- Zeigen Sie Kosten des Status Quo (Opportunity-Kosten, Risiken)
- Pilot-Projekt: Greifbare Verbesserungen demonstrieren
2. "Wir haben keine Zeit für Änderungen"
Realität: Sie haben keine Zeit, NICHT zu ändern.
Überwinden:
- Phasenweise Migration: Kein Big-Bang, sondern kleine Schritte
- Quick Wins: Frühe Erfolge zeigen ("Schaut, es lohnt sich")
3. "Ich verliere meine Expertise"
Realität: Mitarbeiter fürchten Bedeutungsverlust.
Überwinden:
- Requalifizierung: Schulungen in neuen Technologien
- Involvement: Mitarbeiter sind Teil der Lösung, nicht Opfer
4. "Zu riskant, was wenn es schief geht?"
Realität: Parallel-Betrieb minimiert Risiko.
Überwinden:
- Rollback-Pläne: Zeigen Sie, dass Risiko beherrschbar ist
- Pilot-Projekt: Proof-of-Concept ohne Risiko
Fazit: Pragmatismus schlägt Perfektion
Legacy-Modernisierung ist kein technisches Problem – es ist ein Business-Problem, gelöst mit Technologie.
Die Erfolgsfaktoren:
- Inkrementell, nicht Big-Bang: Kleine Schritte, häufige Erfolge
- Business-Value first: Migrieren Sie, was ROI liefert, nicht was technisch "sauber" ist
- Parallel-Betrieb: Risiko minimieren durch Koexistenz
- Change-Management: Die Organisation ist wichtiger als die Technologie
- Langfristigkeit: 3-5 Jahre sind normal. Wer schneller will, scheitert meist
Das Strangler-Fig-Pattern ist kein Silver Bullet. Es ist harte Arbeit, über Jahre. Aber es funktioniert – wenn Sie es richtig machen.
Und am Ende? Sie haben ein modernes System, ohne dass das Business jemals stillstand. Sie haben den Vorstand überzeugt mit greifbaren Erfolgen. Und Sie haben Ihre Organisation in die Zukunft geführt.
Weitere Ressourcen
Legacy-Modernisierung erfolgreich umsetzen?
- Legacy-Modernisierung & Enterprise-Architektur Services – Wie ich bei risikoarmer Transformation helfe
- Fallstudie: €2.5M TCO-Reduktion durch Asset-Management-Modernisierung – Konkretes Beispiel aus dem Finanzsektor
- Mein Beratungsansatz: Business-First, pragmatisch, messbar – Die Philosophie hinter meiner Arbeit
Bereit für Ihre Legacy-Modernisierung? Ich habe über 8 mittelständische Unternehmen bei pragmatischer Legacy-Modernisierung begleitet – von Assessment über Strategie bis Umsetzungs-Begleitung. Lassen Sie uns über Ihre spezifische Situation sprechen.