Legacy-Modernisierung ohne Big-Bang: Das Strangler-Fig-Pattern

Ihr ERP läuft seit 18 Jahren. Es ist stabil – aber jede Änderung zieht sich über Monate, neue Features scheitern an der Architektur, die Wartungskosten steigen jedes Jahr, und die Handvoll Entwickler, die das System noch durchschauen, geht in den nächsten Jahren in Rente.

Die Geschäftsführung drängt auf Digitalisierung. Die Fachabteilungen wollen neue Funktionen. Der Wettbewerb ist schneller. Sie wissen: Wir müssen modernisieren – ohne den laufenden Betrieb zu gefährden.

Ein Big-Bang-Rewrite dauert drei bis fünf Jahre, verschlingt zweistellige Millionenbeträge und scheitert in den meisten Fällen. Das Strangler-Fig-Pattern liefert die Alternative: schrittweise, risikoarm, parallel zum laufenden Betrieb. Benannt nach der Würgefeige, die einen alten Baum langsam umschließt, bis sie ihn vollständig ersetzt.

Dieser Artikel zeigt, wie Sie Legacy-Systeme pragmatisch ablösen – ohne Business-Disruption, mit messbarem ROI und einer Argumentation, die vor dem Vorstand trägt.

Für wen dieser Artikel relevant ist: CTOs, VPs Engineering und IT-Entscheider im Mittelstand, die vor einer ERP- oder Monolith-Ablösung stehen und einen Weg ohne Big-Bang suchen.

Warum Legacy-Systeme zum Geschäftsrisiko werden

Die typischen Symptome

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 Big-Bang-Rewrites scheitern

Die Verlockung ist groß: "Wir schreiben alles neu. In zwei Jahren haben wir ein modernes System."

Die Realität sieht anders aus. Projekte dauern zwei- bis dreimal länger als geplant, Budgets werden deutlich überschritten, und während der Entwicklung liefern Sie keine neuen Features – Ihre Organisation wartet jahrelang.

Die Gründe sind strukturell:

1. Moving Target: Das Business ändert sich während der Entwicklung. Nach drei Jahren ist das neue System bereits veraltet.
2. Unterschätzte Komplexität: Zwei Jahrzehnte gewachsene Business-Logik sind weitgehend undokumentiert. Die wahre Komplexität entdecken Sie erst beim Rewrite.
3. Doppelte Kosten: Sie finanzieren parallel die Wartung des Altsystems und die Entwicklung des Neusystems – über Jahre.
4. Organisatorischer Widerstand: Die komplette Umstellung auf einen Stichtag überfordert Fachbereiche, Betrieb und Support.

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:

1. Ein Vogel lässt einen Samen auf einem Baum fallen
2. Der Samen wächst und schlingt sich um den Baum
3. Über Jahre hinweg umschließt die Feige den alten Baum vollständig
4. Der alte Baum stirbt ab und wird durch die Feige ersetzt
5. Die Feige steht alleine – mit derselben Form wie der alte Baum

Übersetzung auf Software:

1. Das neue System wächst schrittweise um das alte herum
2. Feature für Feature wird vom alten zum neuen System migriert
3. Während der Migration funktioniert beides parallel
4. Wenn das alte System leer ist, schalten Sie es ab
5. 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:

1. API-Gateway/Fassade: Entscheidet, ob Request an alt oder neu geht
2. Feature-Flags: Granulare Kontrolle (z.B. "User-Gruppe A nutzt neu, B nutzt alt")
3. Daten-Synchronisation: Bi-direktional während Übergangsphase
4. 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:

1. Legacy-System-Inventur:

   • Welche Module/Features gibt es?
   • Welche sind geschäftskritisch?
   • Wo ist technische Schuld am höchsten?
   • Wer versteht noch welchen Teil?

2. Dependency-Mapping:

   • Welche Module hängen voneinander ab?
   • Wo sind die größten Kopplungen?
   • Welche Schnittstellen existieren bereits?

3. 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)

4. 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:

1. 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?)

2. 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):

Total: 23 Monate, €1M

3. 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:
  1. Woche 1-2: Migriere Orders Jahr 2022-2024 (300k Orders)
  2. Woche 3-4: Migriere Orders Jahr 2020-2021 (200k Orders)
  3. Woche 5-8: Migriere Orders Jahr 2015-2019 (1M Orders, parallel, niedrige Prio)
  4. 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:

1. Finale Validation:

   • Alle Features im neuen System?
   • Alle Daten migriert?
   • Alle Integrationen funktionieren?

2. Stakeholder-Sign-Off:

   • Fachabteilungen: "Wir können mit neuem System arbeiten"
   • Compliance-Officer: "Alle Anforderungen erfüllt"
   • Vorstand: "ROI wie versprochen geliefert"

3. Abschaltung:

   • Grace-Period: 3 Monate Read-Only (falls Rollback nötig)
   • Nach Grace-Period: Vollständige Abschaltung
   • Hardware/Lizenzen kündigen

4. 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, das mit Technologie gelöst wird.

Die fünf Erfolgsfaktoren in der Reihenfolge ihrer Wirkung:

1. Inkrementell statt Big-Bang: Kleine Schritte liefern sichtbare Erfolge und halten das Risiko beherrschbar.
2. Business-Value zuerst: Migrieren Sie die Module, die ROI oder Risikoreduktion liefern – nicht die, die technisch am "saubersten" sind.
3. Parallel-Betrieb: Koexistenz von Alt und Neu macht jeden Schritt reversibel.
4. Change-Management: Die Organisation ist wichtiger als die Technologie. 70 Prozent der Arbeit sind nicht-technisch.
5. Langfristige Perspektive: Drei bis fünf 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 diszipliniert umsetzen.

Konkrete erste Schritte für Ihr nächstes Quartal:

1. Führen Sie ein Legacy-Assessment nach Phase 1 durch (Inventur, Dependency-Mapping, Risiko-Bewertung).
2. Rechnen Sie den Business-Case durch – Kosten des Status Quo gegen Modernisierungskosten.
3. Wählen Sie einen Pilot: nicht-kritisch, überschaubar, sichtbar.

Nächste Schritte

• Passende Landing Page: .NET & Legacy Migration Services
• Für CTOs im Mittelstand: CTO-Sparring: Zweitmeinung für strategische Tech-Entscheidungen
• Verwandter Artikel: .NET Framework zu .NET Core migrieren
• Verwandter Artikel: API-First-Strategie: Legacy-Systeme öffnen, ohne sie neu zu bauen
• Gespräch vereinbaren: 60-Min-Strategiegespräch zu Ihrer Legacy-Situation