Legacy-Modernisierung mit .NET: Der pragmatische Ansatz

1. Kosten-Explosion

Symptom: Wartungs- und Lizenzkosten steigen Jahr für Jahr, während der Business-Nutzen stagniert
Beispiel: Siebenstellige jährliche Wartungskosten für das ERP – aber neue Features dauern 9-12 Monate

→ Typisch: Der Großteil des IT-Budgets fließt in den reinen Betrieb ("Keep the Lights On"), nur ein Bruchteil in Innovation

2. Vendor-Lock-in

Symptom: Nur noch ein bis zwei Anbieter (oder interne "Legacy-Experten") können das System warten
Beispiel: Sechsstellige Jahresbudgets für einen externen Dienstleister, weil intern niemand die Technologie beherrscht

→ Deutliche Preissteigerungen Jahr für Jahr, keine Verhandlungsmacht

3. Talent-Flucht

Symptom: Gute Entwickler wollen nicht am Legacy-System arbeiten, hohe Fluktuation
Beispiel: Kandidaten sagen im Bewerbungsprozess ab, sobald der veraltete Technologie-Stack zur Sprache kommt

→ Recruiting-Kosten steigen, Wissenssilos entstehen (nur noch zwei, drei Personen verstehen das System)

4. Geschäfts-Agilität leidet

Symptom: Business-Anforderungen dauern Monate statt Wochen, neue Märkte lassen sich nicht erschließen
Beispiel: "Wir können kein Cloud-Angebot aufbauen, weil unser ERP nur on-premises läuft"

→ Time-to-Market leidet, der Wettbewerb zieht vorbei

5. Compliance- & Security-Risiken

Symptom: Das System erfüllt aktuelle Standards nicht (DSGVO, ISO 27001, NIS2)
Beispiel: "Unser Legacy-System kann keine DSGVO-konforme Löschung durchführen"

→ Audit-Findings häufen sich, Business-Risiko steigt

6. Integrations-Albtraum

Symptom: Neue Systeme lassen sich nicht integrieren, APIs fehlen
Beispiel: "Wir können kein modernes CRM anbinden, weil das Legacy-ERP keine REST-APIs hat"

→ Manuelle Workarounds (CSV-Export/-Import): fehleranfällig und langsam

7. End-of-Life & Support-Ende

Symptom: Der Hersteller kündigt das Support-Ende an, es gibt keine Security-Patches mehr
Beispiel: "Windows Server 2012 ist End-of-Life – aber unser Legacy-System läuft nur darauf." Dasselbe gilt für das klassische .NET Framework, das von Microsoft nicht mehr weiterentwickelt wird

→ Kritisches Sicherheitsrisiko, Compliance-Verstöße, Zwang zur Migration

⚠️ Realitäts-Check: Wenn drei oder mehr dieser Symptome auf Sie zutreffen, kostet Ihr Legacy-System Ihre Organisation typischerweise jährlich sechs- bis siebenstellige Beträge an Opportunitätskosten – durch verpasste Geschäftschancen, höhere Betriebskosten und Talentabwanderung.

Das Big-Bang-Szenario

1. Management beschließt: "Wir brauchen ein neues System"
2. 2-3 Jahre Entwicklung des neuen Systems (parallel zum alten System)
3. Ein Wochenende ("Big Bang"): Cutover vom alten zum neuen System
4. Legacy-System wird abgeschaltet
5. Alle Nutzer müssen sofort mit neuem System arbeiten

→ Klingt sauber und effizient. Ist aber extrem riskant.

Beispiel: Healthcare.gov (2013)

Projekt: US-Krankenversicherungs-Portal
Budget: unter $100M geplant, Berichten zufolge weit über $1 Mrd. tatsächlich
Launch: Das System brach am ersten Tag unter der Last zusammen, es folgten monatelange Notfall-Fixes

Beispiel: Lidl SAP-Migration (2018)

Projekt: Ablösung des Warenwirtschaftssystems durch SAP, rund sieben Jahre Projektlaufzeit
Kosten: Medienberichten zufolge etwa €500M investiert
Ergebnis: Projekt gestoppt, Abschreibung, Rückkehr zum Eigensystem

📊 Was Branchenstudien seit Jahren zeigen

• Nur eine Minderheit großer IT-Rewrites bleibt im Zeit- und Budgetrahmen und liefert das gewünschte Ergebnis
• Ein großer Teil überschreitet Budget und Timeline deutlich und funktioniert nur teilweise
• Ein erheblicher Anteil wird abgebrochen oder scheitert komplett – siehe die Beispiele oben

→ Je größer das Projekt, desto schlechter die Quote. Würden Sie diese Wette eingehen?

Die Metapher: die Würgefeige

In der Natur gibt es Feigenarten, die auf anderen Bäumen wachsen. Sie umschlingen den Wirtsbaum langsam, übernehmen dessen Funktion, und irgendwann stirbt der Wirtsbaum ab – die Feige hat ihn bereits ersetzt, ohne dass das Ökosystem zusammenbricht.

Übertragen auf Software: Das neue System "umschlingt" das Legacy-System und übernimmt Schritt für Schritt dessen Funktionen, bis das Legacy-System abgeschaltet werden kann – ohne Unterbrechung des Geschäftsbetriebs.

Die vier Kernprinzipien

Die technische Umsetzung

Das Herzstück ist eine Facade (Routing-Layer), die Requests entweder an Legacy-System oder an neue Komponenten routet:

┌─────────────────────────────────────────────────┐
│              User / Frontend                    │
└───────────────────┬─────────────────────────────┘
                    │
                    ▼
┌─────────────────────────────────────────────────┐
│         Strangler-Facade (API-Gateway)          │
│  • Routing-Logik: Welcher Request an welches    │
│    System? (Feature-Flags, URL-Patterns)        │
│  • Authentication & Authorization               │
│  • Logging & Monitoring                         │
└───────┬────────────────────────────────┬────────┘
        │                                │
        ▼                                ▼
┌───────────────────┐          ┌─────────────────┐
│  Legacy-System    │          │  Neue Systeme   │
│  (alt)            │          │  (modern)       │
│                   │◄─────────┤                 │
│  • ERP-Core       │  API     │  • Microservice │
│  • Reporting      │  Calls   │  • Cloud-Native │
│  • Master-Data    │          │  • REST-APIs    │
└───────────────────┘          └─────────────────┘
        

Wie es funktioniert:

1. Phase 1: Alle Requests gehen zu Legacy-System (via Facade)
2. Phase 2: Erstes neues Feature wird gebaut (z.B. neues Reporting-Modul)
3. Phase 3: Facade routet Reporting-Requests zum neuen Modul, Rest zu Legacy
4. Phase 4: Zweites Feature wird migriert (z.B. User-Management)
5. Phase 5: Facade routet immer mehr Requests zu neuen Komponenten
6. Phase 6: Irgendwann: 100% der Requests gehen zu neuen Komponenten → Legacy-System abschalten

Im .NET-Umfeld lässt sich dieses Pattern besonders gut umsetzen – etwa mit YARP als Reverse-Proxy vor einer ASP.NET-WebForms-Anwendung, während neue Module bereits auf .NET 8 laufen. Wie das konkret aussieht, zeige ich im Artikel Legacy-Modernisierung ohne Big-Bang; wie KI-Coding-Agenten eine solche WebForms-Modernisierung beschleunigen, habe ich separat beschrieben.

💡 Fazit: Strangler-Fig dauert insgesamt länger, liefert aber früher Nutzen – mit geringerem Risiko und deutlich besseren Erfolgsaussichten. Bei geschäftskritischen Enterprise-Systemen ist es fast immer die bessere Wahl.

Phase 1: Assessment & Strategy (4-8 Wochen)

Ziel: Verstehen, was wir haben und was wir brauchen

Aktivitäten:

• System-Inventory: Welche Systeme, Schnittstellen, Daten existieren?
• Code-Analyse: Technologie-Stack, Code-Qualität, Technical-Debt-Hotspots
• Dependency-Mapping: Welche Systeme hängen wovon ab?
• Business-Prozess-Analyse: Welche Geschäftsprozesse laufen über Legacy-System?
• Stakeholder-Interviews: Was sind Pain-Points der Nutzer?
• TCO-Kalkulation: Was kostet uns Status Quo? (Wartung, Opportunitätskosten)

Ergebnisse:

• Dokumentation der Systemlandschaft
• Technical-Debt-Assessment mit Priorisierung
• Modernisierungsstrategie (Strangler-Fig, Replatforming, Ablösung)
• Grobe Roadmap (3-5 Jahre)
• Business-Case (ROI-Kalkulation)

Methodisch entspricht diese Phase einer Technical Due Diligence in eigener Sache – wie Sie dabei systematisch vorgehen, beschreibt mein Leitfaden zur Technical Due Diligence.

Kosten: typischerweise €25k-75k (abhängig von der Systemkomplexität)
Team: Enterprise-Architekt, Business-Analyst, externe Beratung

Phase 2: Quick-Wins & Pilot (3-6 Monate)

Ziel: Frühe Erfolge demonstrieren, Momentum aufbauen

Aktivitäten:

• Quick-Win identifizieren: Welches Feature mit hohem Geschäftsnutzen lässt sich in 3-6 Monaten migrieren?
• Pilot-Projekt definieren: z.B. "Reporting-Modul modernisieren" oder "IoT-Sensor-Integration"
• Technologie-Proof-of-Concept: Strangler-Facade implementieren, erste API bauen
• Pilot-Feature entwickeln: End-to-End-Implementation (Frontend, Backend, Integration mit Legacy)
• User-Testing: Mit 10-20 Power-Usern testen, Feedback sammeln
• Produktiv-Launch: Pilot-Feature für alle Nutzer ausrollen

Beispiele für Pilot-Projekte:

• Reporting-Modernisierung: Legacy-Reports durch moderne BI-Dashboards ersetzen (Tableau, Power BI)
• Mobile-App: Neues mobiles Frontend, das über APIs mit dem Legacy-Backend spricht
• API-Gateway: REST-API-Schicht vor dem Legacy-System, um moderne Integrationen zu ermöglichen
• Erstes .NET-8-Modul: Ein abgegrenztes Modul einer .NET-Framework-Anwendung auf .NET 8 migrieren – als Blaupause für die weitere .NET-Migration

Kosten: typischerweise €75k-250k
Team: 3-5 Entwickler, 1 Product-Owner, 1 Architekt
Erfolgskriterium: Pilot-Feature ist live, positives Nutzer-Feedback, die Geschäftsführung sieht den Nutzen

Phase 3: Iterative Migration (12-24 Monate)

Ziel: Systematische Migration der Kern-Funktionalität

Strategie:

Jetzt beginnt die eigentliche Arbeit: Feature für Feature, Modul für Modul migrieren – pro Quartal zwei bis drei Features oder Module. Jede Migration ist ein Mini-Projekt (6-12 Wochen). KI-gestützte Entwicklung kann diese Phase deutlich beschleunigen; wie Sie Ihr Team dafür aufstellen, zeigt der Artikel KI-Enablement im Engineering-Team.

Priorisierung der Migration:

1. High-Value, Low-Complexity: Features, die viel Geschäftsnutzen liefern und einfach zu migrieren sind (z.B. Reporting, User-Management)
2. High-Value, High-Complexity: Kern-Business-Logik, die kritisch ist (z.B. Order-Management, Invoicing)
3. Low-Value, Low-Complexity: Nice-to-have-Features (z.B. selten genutzte Reports)
4. Low-Value, High-Complexity: Ignorieren oder "Lift-and-Shift" (nicht neu bauen)

Rhythmus:

• Woche 1-2: Feature-Analyse, Design, Story-Mapping
• Woche 3-8: Entwicklung und Testing (parallel läuft das Legacy-System weiter)
• Woche 9-10: User-Acceptance-Testing, Bugfixes
• Woche 11: Produktiv-Rollout (per Feature-Flag: 10% der Nutzer → 50% → 100%)
• Woche 12: Retrospektive, Erkenntnisse dokumentieren, nächstes Feature planen

Kosten: typischerweise €500k-2M (abhängig vom Umfang)
Team: 8-15 Personen (Entwicklung, QA, Produkt, Architektur)
Erfolgskriterium: Der Großteil der kritischen Legacy-Features ist migriert, die Nutzerakzeptanz ist hoch

Phase 4: Datenmigration & Synchronisation (6-12 Monate)

Ziel: Daten vom Legacy-System in das neue System migrieren

Herausforderung:

Die Datenmigration ist oft der schwierigste Teil. Das Legacy-System trägt 15-20 Jahre an Dateninkonsistenzen, Duplikaten und Qualitätsproblemen mit sich. Ein simples "Kopieren" reicht nicht.

Strategie: Dual-Write & inkrementelle Migration

1. Phase 4a: Datenqualitäts-Assessment (4-6 Wochen)
   Welche Daten existieren? Wie gut ist die Datenqualität? Welche Transformationen sind nötig?
2. Phase 4b: Daten-Sync-Mechanismus bauen (8-12 Wochen)
   Bidirektionale Synchronisation zwischen Legacy- und neuem System: Änderungen im Legacy-System werden ins neue System übertragen (und umgekehrt).
3. Phase 4c: Batch-Migration historischer Daten (12-16 Wochen)
   Historische Daten (z.B. Aufträge der letzten zehn Jahre) werden batchweise migriert, validiert und getestet.
4. Phase 4d: Cutover-Vorbereitung (4-6 Wochen)
   Finaler Sync, Konsistenzprüfungen, Rollback-Pläne

Kosten: typischerweise €200k-800k (abhängig von Datenvolumen und Komplexität)
Team: Data-Engineers, DBAs, QA
Risiko: Hoch (Datenverlust, Inkonsistenzen) → braucht intensives Testing

Phase 5: Decommissioning (3-6 Monate)

Ziel: Legacy-System abschalten

Kriterien für die Abschaltung:

• ✅ Alle kritischen Features sind migriert
• ✅ Alle Daten sind migriert und validiert
• ✅ Praktisch keine aktiven Nutzer mehr im Legacy-System
• ✅ Das neue System läuft nachweislich stabil
• ✅ Compliance- und Audit-Anforderungen sind erfüllt
• ✅ Eine Archivierungsstrategie für historische Daten existiert

Decommissioning-Plan:

1. Read-Only-Modus: Das Legacy-System wird schreibgeschützt weiterbetrieben (3-6 Monate Parallelbetrieb)
2. Monitoring: Gehen wirklich keine kritischen Abfragen mehr an das Legacy-System? Kein Traffic mehr?
3. Abschaltung: Das Legacy-System wird abgeschaltet (Backups bleiben erhalten)
4. Datenarchivierung: Legacy-Daten werden gemäß Aufbewahrungspflichten archiviert (häufig zehn Jahre)
5. Infrastruktur-Rückbau: Server und Lizenzen werden gekündigt – ab hier sparen Sie bares Geld

Einsparungen ab jetzt: Wartung, Lizenzen und Betrieb des Altsystems entfallen – je nach System schnell sechs- bis siebenstellige Beträge pro Jahr

Phase 6: Continuous Improvement (ongoing)

Ziel: Das neue System kontinuierlich verbessern

Die Migration ist nicht das Ende, sondern der Anfang. Jetzt haben Sie ein modernes System – nutzen Sie es, um Geschäftsnutzen zu liefern:

• Neue Features: Funktionen bauen, die im Legacy-System unmöglich waren (z.B. Mobile-App, Echtzeit-Analytics, KI-gestützte Funktionen)
• Performance-Optimierung: Lasttests, Caching, Datenbank-Optimierung
• User Experience verbessern: UI/UX-Redesign, A/B-Testing
• Integrations-Ökosystem: APIs für Partner öffnen, Drittanbieter-Tools anbinden
• Kostenoptimierung: Cloud-Kosten optimieren (Right-Sizing, Reserved Instances)

ROI: Neue Features schaffen neuen Umsatz, höhere Kundenzufriedenheit stärkt die Kundenbindung

✅ Timeline-Übersicht

• Phase 1 (Assessment): Monat 1-2
• Phase 2 (Quick-Win/Pilot): Monat 3-8
• Phase 3 (Iterative Migration): Monat 9-32 (parallel zu Phase 4)
• Phase 4 (Data-Migration): Monat 24-36
• Phase 5 (Decommissioning): Monat 36-42
• Phase 6 (Continuous Improvement): Ongoing

Gesamt-Timeline: 3-5 Jahre (abhängig von System-Komplexität)