Legacy-Modernisierung

Ihre Software ist 10+ Jahre alt, kritisch für den Betrieb –
aber niemand traut sich ran?

Ich modernisiere Ihre Legacy-Software im laufenden Betrieb – kein Big-Bang, sondern kontrollierte Inkremente.

Dabei arbeite ich mich bewusst in alte Technologien, unvollständig dokumentierte Fachlogik und gewachsene Schnittstellen ein – auch wenn Hardware, Maschinen oder technische Anlagen Teil des Systems sind.

Kommen Ihnen diese Warnsignale bekannt vor?

Wenn Sie 3 oder mehr Warnsignale erkennen, ist Modernisierung überfällig.
Je länger Sie warten, desto teurer und riskanter wird es.

Legacy-Angst

"Jede Änderung ist riskant – niemand traut sich ran"

Deployment-Angst

"Deployments sind stressig, dauern Stunden, passieren selten (1x/Quartal)"

Keine Observability

"Wenn etwas schiefgeht, ist Debugging ein Ratespiel"

Technologie-Schulden

"Frameworks sind End-of-Life, Security-Patches nicht mehr verfügbar"

Performance-Probleme

"System wird immer langsamer, aber niemand weiß warum"

Hohe Kosten

"Wartung kostet mehr als Neuentwicklung"

Recruiting-Problem

"Niemand will an Legacy arbeiten – Team-Fluktuation steigt"

Architektur-Drift

"Keiner versteht mehr die Gesamtarchitektur – Dokumentation fehlt"

4 bewährte Ansätze

Strangler Pattern (Schrittweise Ersetzen)

Konzept: Neue Funktionalität in neuem System bauen, altes System parallel weiterlaufen lassen, Traffic schrittweise umleiten, altes System nach und nach abschalten.

Wann sinnvoll: System ist zu groß für Rewrite, Business-Logik ist komplex & undokumentiert, Risiko-Minimierung ist kritisch.

Beispiel:

Alt: Monolith (Java 8, JSF, PostgreSQL)

Neu: Neuer Service (Java 21, Spring Boot, REST)

→ Strangler-Proxy leitet Traffic um (Feature Flag) → Alte Funktionalität nach und nach migriert

Modular Monolith (Erst modularisieren, dann trennen)

Konzept: Monolith intern modularisieren (Bounded Contexts), klare Modul-Grenzen ziehen, API-Contracts zwischen Modulen definieren, später Module als Services auslagern (wenn nötig).

Wann sinnvoll: Microservices wären Overkill, Team ist zu klein für verteilte Systeme, Domänengrenzen sind unklar.

Beispiel:

Alt: 1 großer Monolith (alles in einer App)

Neu: Modular Monolith (Payroll, Reporting, IAM als separate Module)

→ Jedes Modul hat eigene API → Später: Reporting als separater Service (wenn Last steigt)

Read Models (Reporting entkoppeln)

Konzept: Reporting oft Performance-Bottleneck. Read Model = separate Datenbank nur für Reporting. Event-driven: Hauptsystem sendet Events, Read Model baut optimierte Views. CQRS (Command Query Responsibility Segregation).

Wann sinnvoll: Reporting blockiert Hauptsystem, komplexe SQL-Queries sind langsam, Monatsabschluss dauert Stunden.

Beispiel:

Alt: Payroll-System + Reporting in einer DB (langsam)

Neu: Payroll sendet Events → Read Model (PostgreSQL mit optimierten Views) → Reporting greift auf Read Model zu (schnell, entkoppelt)

Observability-First (Erst sichtbar machen, dann ändern)

Konzept: Legacy-Systeme haben oft keine Observability. Ohne Logs/Metrics/Traces ist jede Änderung ein Blindflug. Zuerst: Observability einbauen (Logs, Metrics, Traces, Alerts). Dann: Modernisierung starten (mit klaren SLOs).

Wann sinnvoll: System hat keine Logs/Metrics, Performance-Probleme sind unklar, Fehlersuche ist Ratespiel.

Beispiel:

Alt: Keine Logs, keine Metrics, keine Traces

Neu: Logs (ELK Stack), Metrics (Prometheus), Traces (Jaeger), Alerts (PagerDuty)

→ SLOs definiert (z.B. "99,9% Uptime", "< 500ms Latency") → Jetzt kann modernisiert werden (mit klaren Zielen)

Mein Vorgehen: 4 Phasen

Phase 1

Audit (2–4 Wochen)

Ziel: Ist-Zustand transparent machen

  • Architektur-Audit (C4, Risk Register, ADRs)
  • Tech Stack analysieren (End-of-Life? Security-Lücken?)
  • Performance-Baseline messen
Phase 2

Zielarchitektur & Roadmap (4–8 Wochen)

Ziel: Soll-Zustand definieren & Weg dorthin

  • Zielarchitektur entwickeln (C4 Target State)
  • Strategie wählen (Strangler, Modular Monolith, Read Models)
  • Roadmap erstellen (Inkremente, Abhängigkeiten, Risiken)
Phase 3

Inkremente (3–12 Monate, iterativ)

Ziel: Schrittweise Modernisierung

  • Inkrement 1: Observability (Logs, Metrics, Traces)
  • Inkrement 2: Erste Entkopplung (z.B. Reporting)
  • Inkrement 3+: Strangler-Service, Migration, ...
Phase 4

Governance (optional, Retainer)

Ziel: Kontinuierliche Qualitätssicherung

  • Reviews (Code, Architektur, Security)
  • Milestone-Steuerung (sind wir auf Kurs?)
  • ADR-Updates, KPI-Tracking

Woran messen wir Erfolg?

Deployment-Frequenz

Alt: 1x/Quartal

Neu: 1x/Woche oder häufiger

Fehlerrate

Alt: Sporadische Fehler

Neu: -80% Fehlerrate

MTTR

Alt: Stunden/Tage

Neu: < 30 Minuten

Performance

Alt: Monatsabschluss 8+ Stunden

Neu: < 1 Stunde

Team-Ownership

Alt: Niemand traut sich ran

Neu: Team entwickelt eigenständig

Kosten

Alt: Wartung frisst Budget

Neu: Budget für Innovation

Häufige Fragen

Nein! Big-Bang-Rewrites sind riskant und teuer. Ich empfehle: Strangler Pattern (schrittweise ersetzen), Modular Monolith (erst modularisieren, dann trennen), nur kritische Teile modernisieren (80/20-Prinzip).

Abhängig von Systemgröße. Typisch: 3–12 Monate, iterativ. Wichtig: Nach jedem Inkrement (z.B. 4–8 Wochen) gibt es messbaren Fortschritt.

Ja! Das ist der Vorteil von Inkremente statt Big-Bang. Sie können neue Features parallel entwickeln, alte Features weiterwarten, schrittweise migrieren (kein Freeze).

Dann empfehle ich: Modular Monolith statt Microservices (weniger Komplexität), Hands-on Unterstützung (ich baue kritische Pfade selbst), Fokus auf Quick Wins (z.B. Observability zuerst).

Durch: Observability-first (erst sichtbar machen), SLOs (messbare Qualität), Feature Flags (Traffic schrittweise umleiten, Rollback möglich), Inkremente (kleine Schritte, testbar), Rollback-Strategie.

Bereit, Ihre Legacy zu modernisieren?

Lassen Sie uns in einem ersten Gespräch klären, ob Legacy-Modernisierung
für Sie sinnvoll ist. Unverbindlich, 30 Minuten, kostenfrei.

Erstberatung vereinbaren (30 Min., kostenfrei)