Pillar Page

Legacy-System-Modernisierung

Inkrementelles Monolith-zu-Microservices-Refactoring, Migration von veralteten Technologien zu modernen Stacks, Cloud-Migration — ohne Business-Downtime, mit Rollback-Plan und vollständigem Audit-Trail.

Legacy-System-Audit Alle Leistungen

Jedes Unternehmen hat irgendein Legacy-System. Manche haben mehrere. Eine Buchhaltungsanwendung aus dem Jahr 2008, die irgendwie noch läuft. Ein CRM, das von Beratern geschrieben wurde, an die sich niemand mehr erinnert. Ein Lager, das in Access läuft. Jedes davon wird irgendwann ersetzt werden müssen — die Frage ist nicht ob, sondern wann und wie.

Legacy-System-Modernisierung ist eine der schwierigsten Arten von IT-Projekten. Sie erfordert das Ausbalancieren dreier Kräfte: Business-Kontinuität (das System muss die ganze Zeit weiterlaufen), Einführung moderner Technologien (Microservices, Cloud, KI) und Risikokontrolle (jedes Refactoring kann etwas kaputtmachen, das jahrelang funktioniert hat).

Warum nicht einfach „von Grund auf neu schreiben"?

Aus unserer Erfahrung sind 9 von 10 erfolgreichen Modernisierungen inkrementelles Refactoring, kein Rewrite. Rewrites sind konzeptionell verlockend („wir starten mit einem weißen Blatt"), haben in der Praxis aber drei fundamentale Probleme:

  • Unsichtbare Geschäftslogik. Das alte System enthält jahrelang gewachsene Geschäftsregeln — Sonderkonditionen für die größten Kunden, Steuerbefreiungen für bestimmte Branchen, Workarounds für Regulierungen aus 2015. Das meiste ist nicht dokumentiert. Ein Rewrite muss all das aus den Erinnerungen von Personen oder aus Code-Analyse rekonstruieren.
  • Doppelte Arbeit. Während das neue System geschrieben wird, fordert das Business weiterhin Änderungen am alten (Regulierungen, neue Kunden, kleine Bugs). Das Team verdoppelt entweder die Arbeit (Änderungen an zwei Stellen) oder friert das alte System ein (Geschäftsrisiko).
  • Big-Bang-Deployment. Nach einem Jahr Arbeit ist das neue System „fast fertig". Das Umschalten aller Nutzer in einer Nacht erzeugt monumentale Risiken. Jedes unerwartete Problem bedeutet den Rückweg zum alten System, Verlust an Teammoral und erodierendes Vertrauen des Business.

Inkrementelles Refactoring (meist nach dem Strangler-Fig-Muster) löst alle drei: Geschäftslogik wird schrittweise entdeckt, eine Source of Truth pro Entität, Deployment in Etappen mit Feature Flags.

Sechs Modernisierungsmuster

Jedes adressiert ein konkretes Risiko. In den meisten Projekten kombinieren wir mehrere und wählen das Muster pro Modul.

Strangler Fig

Schrittweises „Umranken" des alten Systems mit neuen Komponenten. Der alte Code läuft weiter, aber jedes neue Feature geht in einen neuen Microservice, und bestehende Module werden eines nach dem anderen ersetzt. Nach 12-24 Monaten wird der alte Monolith abgeschaltet.

Anti-corruption layer

Ein Adapter, der neuen Code vor den Eigenheiten des alten Systems schützt (unleserliche Feldnamen, seltsame Datumsformate, inkonsistente Typen). Die gesamte „hässliche" Logik wird an einer Stelle isoliert — neuer Code operiert auf einem sauberen Domain-Modell.

Database refactoring

Muster aus Refactoring Databases (Ambler/Sadalage): Expand-and-Contract für Schemamigrationen, Datenvalidierung vor dem Löschen alter Spalten, paralleler Betrieb beider Schemata während der Anwendungsmigration.

Branch by abstraction

Einführung einer Abstraktionsschicht um die alte Komponente, parallele Implementierung der neuen Komponente, schrittweises Umschalten des Traffics von 0% auf 100% (Feature Flag). Ohne „Big-Bang"-Deployment.

Shadow mode

Der neue Code läuft parallel zum alten — beide verarbeiten dieselben Anfragen, aber nur die Ergebnisse des alten Systems erreichen den Nutzer. Die Ergebnisse werden offline verglichen. Nach Bestätigung der Übereinstimmung (typischerweise 2-4 Wochen) schalten wir den Traffic auf den neuen Code.

Event sourcing für Migration

Wir zeichnen den Strom der Geschäftsereignisse aus dem alten System auf und spielen ihn im neuen ab. Das erlaubt eine vorgelagerte Validierung der neuen Architektur ohne Produktivrisiko sowie die Rückkehr zu beliebigen historischen Zuständen.

Typischer Modernisierungsfahrplan

Für ein mittelgroßes System (Monolith mit ~200 Tsd. Codezeilen, 5-10 Geschäftsmodulen):

  1. Monat 1: Discovery und Dokumentation. Reverse Engineering der Architektur, Abhängigkeitsmapping, Identifikation von Datenflüssen, Dokumentation der Geschäftsprozesse mit Unterstützung der Business-Stakeholder.
  2. Monat 2: Zielarchitektur und Pilot. Design der neuen Architektur, Technologieauswahl, Pilot am einfachsten Modul (Proof of Concept). Erste Validierung des Ansatzes.
  3. Monate 3-4: Herauslösen des ersten Produktivmoduls. Strangler-Fig-Muster, Shadow Mode für 2-3 Wochen, Traffic-Cutover, Hypercare. Erster realer Geschäftswert.
  4. Monate 5-12: Iteratives Herauslösen weiterer Module. Jedes in einem 4-6-Wochen-Zyklus: Refactor → Tests → Shadow → Produktion → Hypercare. Kontinuierliche Prozessverbesserung, Verkürzung der Zeit pro Modul.
  5. Monate 12-18: Datenmigration und Stilllegung des Monolithen. Sobald alle kritischen Module herausgelöst sind, finalisieren wir die historische Datenmigration, schalten das alte System ab und archivieren es. Feiern.

Legacy-System vs. modernisiert

AspektLegacy-System (typisch)Nach Modernisierung
Zeit für ein neues Feature4-8 Wochen (hohes Regressionsrisiko)3-7 Tage (automatisierte Tests minimieren das Risiko)
Testabdeckung5-15% (oder gar keine)>80%, in der CI/CD-Pipeline
Verfügbarkeit von EntwicklernNiedrig (veraltete Technologie)Hoch (populäre, moderne Stacks)
SicherheitAlte Bibliotheken mit ungepatchten CVEsOWASP-Scanning, gitleaks, automatisierte Updates
SkalierungVertikal (mehr Ressourcen für den Monolithen)Horizontal (Skalierung einzelner Microservices)
ObservabilityLogs in Dateien, keine MetrikenPrometheus + Grafana + Sentry + SIEM
Compliance (DSGVO, EU AI Act, ISO 27001)Aufwendig, teuer nachzuweisenIn die Architektur eingebaut, audit-ready

Sechs typische Risiken — und wie wir sie adressieren

Risiko: Keine Tests im Legacy-System

Mitigation: Zuerst bauen wir Characterization-Tests (Capture-Tests) — wir zeichnen das aktuelle Systemverhalten auf Basis von Produktivlogs und Traffic-Aufzeichnungen auf. Erst dann beginnen wir mit dem Refactoring, mit Tests als Sicherheitsnetz.

Risiko: Wissen konzentriert in einer Person („Truck Factor 1")

Mitigation: Der Wissenstransfer beginnt in der ersten Projektwoche. Alle Meetings mit der Person, die das System kennt, werden aufgezeichnet und transkribiert, Schlüsselprozesse dokumentiert, Architekturentscheidungen begründet. Nach dem Projekt versteht das gesamte Team das System.

Risiko: Temporäre Teamverlangsamung

Mitigation: In den ersten 2-3 Monaten wartet das Team das alte System + baut das neue. Eine natürliche Verlangsamung der Änderungsgeschwindigkeit. Wir mildern sie ab durch: Priorisierung von Änderungen, die nur in das neue System gehen, Freeze für niedrigpriore Änderungen am Altcode.

Risiko: Datenmigration

Mitigation: Jede Datenmigration hat drei Phasen: Dry-Run (auf einer Produktivkopie), Staging (in der Testumgebung mit echter Datenskala), Produktion (in einem Wartungsfenster oder inkrementell). Rollback-Plan steht vor Start bereit.

Risiko: Organisatorischer Widerstand

Mitigation: Kommunikation mit dem Business ab Tag eins: warum wir modernisieren, was sich für den Nutzer ändert, welcher Zeitplan, wie wir Erfolg messen. Die erste Iteration wird so gewählt, dass sie schnell sichtbaren Mehrwert zeigt (z. B. ein neues UI oder ein schnellerer Bericht).

Risiko: Kostenunterschätzung

Mitigation: Discovery (1-2 Wochen) vor der Projektkalkulation. 2-3-wöchige Iterationen mit konkreten Lieferergebnissen — leichter den Kurs zu korrigieren als in einem langen „Alles auf einmal"-Projekt. Budget mit 20-30% Puffer für Unvorhergesehenes.

Häufig gestellte Fragen

Was ist ein Legacy-System?
Ein Legacy-System ist Software, die in der Organisation noch läuft, aber auf veralteter Technologie basiert, hohe technische Schulden trägt, keine Tests hat, keine Dokumentation oder den Entwickler nicht mehr hat, der sie geschrieben hat. Klassische Beispiele: eine monolithische PHP-5.x- oder .NET-Framework-4.0-Anwendung, eine Datenbank ohne Migrationen, ein jQuery-Frontend, FTP-Deployment. Sie funktioniert, aber jede Änderung ist risikoreich und teuer.
Warum modernisieren, wenn das System läuft?
Drei Hauptgründe. Erstens: Die Wartungskosten wachsen exponentiell mit dem Alter des Systems — immer weniger Entwickler kennen die Technologie, jede Änderung dauert länger, jeder Bug hat eine größere Auswirkung. Zweitens: Sicherheitsrisiko — alte Frameworks haben ungepatchte Schwachstellen, keinen Herstellersupport, Nicht-Konformität mit DSGVO/ISO 27001. Drittens: Wachstumsblockade — neue Anforderungen (Mobile, API, Integrationen, KI) sind schwer oder unmöglich hinzuzufügen.
Ist es nicht einfacher, alles von Grund auf neu zu schreiben?
Das klassische „Rewrite vs. Refactor"-Dilemma. Rewrites sind konzeptionell verlockend, dauern in der Praxis aber 2-3 mal länger als geplant, das Projekt erstickt am Gewicht des Rekonstruierens unsichtbarer Geschäftslogik, und in der Zwischenzeit muss das alte System weiterentwickelt werden (doppelte Arbeit). Aus unserer Erfahrung: 9 von 10 erfolgreichen Modernisierungen sind inkrementelles Refactoring (Strangler-Fig-Muster) — schrittweises Ersetzen von Teilen des alten Systems unter Wahrung der Business-Kontinuität. Ein Rewrite ergibt nur bei sehr kleinen Systemen Sinn.
Erfordert Modernisierung Business-Downtime?
In der überwiegenden Mehrheit der Projekte nein. Wir setzen Muster ein, die ein „Live"-Tausch von Komponenten erlauben: Blue-Green-Deployment, Feature Flags, Dark Launches, paralleler Betrieb von altem und neuem Code mit Ergebnisvergleich (Shadow Mode). Kurze Wartungsfenster können bei Datenbankmigrationen mit erheblichen Schemaänderungen nötig sein, aber wir planen sie im Voraus (typischerweise nachts, am Wochenende) mit vollständigem Rollback-Plan.
Wie lange dauert eine typische Modernisierung?
Das hängt von der Skala ab. Ein einzelnes Monolith-Modul als Microservice herauslösen: 1-2 Monate. Eine größere Modernisierung (5-10 Module, neue Datenbank, neue API): 6-12 Monate in 2-3-wöchigen Iterationen. Eine vollständige Transformation eines Enterprise-Monolithen: 18-36 Monate, aber Geschäftswert entsteht bereits nach der ersten Iteration — jedes herausgelöste Modul liefert sofort Nutzen (schnellere Änderungen, geringeres Risiko, bessere Observability).
Von welchen Technologien migrieren wir am häufigsten?
Häufigste Pfade: PHP 5/7 → PHP 8 oder Python (FastAPI) oder Node.js (Express/Fastify). .NET Framework 4.x → .NET 8 oder Java/Spring Boot. Java EE (JBoss/WebSphere) → Spring Boot oder Quarkus. jQuery + monolithische Templates → React/Vue/Astro. Oracle DB → PostgreSQL (erhebliche Lizenzersparnis). On-Premise → Cloud (AWS, Azure, GCP, lokale Private Cloud).
Was passiert mit bestehenden Integrationen zu anderen Systemen?
Jede bestehende Integration wird in der Discovery-Phase erfasst. Der Migrationsplan umfasst: Erhalt bestehender Verträge (interne und externe Clients bemerken keine Änderung), Einführung von Versionierung (v1 alter Vertrag, v2 neu), schrittweise Migration der Konsumenten auf v2, erst dann Außerbetriebnahme von v1. Vollständige Rückwärtskompatibilität während der Migration.
Wie reduzieren Sie das Geschäftsrisiko?
Fünf Schichten: 1) Inkrementalität — wir ersetzen ein Modul nach dem anderen, nicht alles auf einmal; 2) Characterization-Tests — vor dem Refactoring zeichnen wir das aktuelle Systemverhalten auf (Capture-Tests), die später verifizieren, dass nichts kaputtgegangen ist; 3) Feature Flags — neue Funktionalität wird schrittweise ausgerollt (1% der Nutzer → 10% → 50% → 100%); 4) Rollback-Plan für jedes Deployment (<5 Min.); 5) Hypercare nach Rollout (intensives Monitoring 2-4 Wochen).
Was tun mit Systemdokumentation, die nicht existiert?
Ein häufiges Legacy-Problem. Erste Projektphase: Reverse Engineering der Dokumentation. KI-Agenten analysieren den Code, das Datenbankschema, Produktivlogs und generieren: Architekturdiagramm, Endpoint-Liste, Abhängigkeitskarte, Beschreibungen der Geschäftsprozesse. Diese Dokumentation wird dann mit Business-Personen verifiziert (sieht der Prozess so aus, wie wir ihn aus dem Code verstanden haben). Ergebnis: vollständige Dokumentation vor Beginn des Refactorings, nützlich nicht nur für das Modernisierungsprojekt, sondern auch für das Produktteam.
Wie stehen die Modernisierungskosten im Vergleich zur Wartung des alten Systems?
Kurzfristig ist Modernisierung teurer als Wartung (Investition in Refactoring + paralleler Betrieb des alten Systems). Der Break-Even-Punkt (an dem das neue System günstiger im Unterhalt wird als das alte) tritt typischerweise nach 12-18 Monaten ein. Danach kostet das neue System: weniger im Unterhalt (weniger Entwickler, mehr Automatisierung), erlaubt schnellere Änderungen (kürzere Time-to-Market), reduziert Risiken (bessere Observability, mehr Tests, Fehlerisolation).

Beginnen wir mit einem Audit

Einwöchiges technisches Audit: Abbildung des aktuellen Stands, Identifikation der dringendsten Modernisierungsbereiche, phasenweiser Plan mit konkreten geschäftlichen Ergebnissen in der ersten Iteration.

Systemaudit vereinbaren Softwareentwicklung