Legacy-Anwendungen modernisieren: Ein pragmatischer 4-Phasen-Ansatz

Jedes Unternehmen hat sie: Anwendungen, die zehn, fünfzehn oder zwanzig Jahre alt sind, auf Frameworks laufen, die niemand mehr pflegt, und deren Wissen bei einer Handvoll erfahrener Entwickler liegt, die sich dem Ruhestand nähern. Diese Systeme funktionieren — bis sie es nicht mehr tun. Und wenn sie ausfallen, wird es teuer.

Die Versuchung ist gross, von Grund auf neu zu schreiben. Tun Sie das nicht. Die Geschichte ist gepflastert mit gescheiterten Big-Bang-Rewrites. Stattdessen empfehlen wir einen pragmatischen, phasenbasierten Ansatz, der inkrementell Wert liefert und gleichzeitig Risiken beherrscht.

Dies ist das Framework, das wir bei CC Conceptualise einsetzen, verfeinert über Dutzende Modernisierungsprojekte bei Mittelstands- und Enterprise-Kunden.

Phase 1: Assessment — Verstehen, bevor man handelt

Die häufigste Ursache gescheiterter Modernisierungen: Handeln ohne ausreichendes Verständnis. Phase 1 dauert 2-4 Wochen und liefert die Entscheidungsgrundlage für alles Weitere.

Technische Bestandsaufnahme

Abhängigkeitskartierung: Jeden Integrationspunkt dokumentieren — Datenbanken, Message Queues, Dateifreigaben, externe APIs, Batch-Jobs und manuelle Prozesse. Tools wie Application Insights oder Dynatrace für die Laufzeit-Dependency-Discovery einsetzen. Statische Analyse übersieht Laufzeitabhängigkeiten.
Technologie-Inventar: Jedes Framework, jede Bibliothek und jede Laufzeitversion auflisten. Alles markieren, was End-of-Life oder kurz vor End-of-Support steht.
Code-Qualitätsscan: Statische Analyse durchführen (SonarQube, NDepend für .NET). Fokus auf zyklomatische Komplexität, Testabdeckung und den Anteil an totem Code. Toter Code ist ein Signal der Angst — niemand traut sich, ihn zu löschen, weil niemand ihn versteht.
Datenarchitektur: Datenbankschema kartieren, Datenvolumen identifizieren und Datenqualitätsprobleme dokumentieren. Legacy-Systeme haben oft implizite Geschäftsregeln in Stored Procedures kodiert.

Geschäftswert-Bewertung

Nicht jede Legacy-Anwendung verdient Modernisierungsinvestitionen. Klassifizieren Sie Anwendungen mit einer einfachen 2x2-Matrix:

	Hoher Geschäftswert	Niedriger Geschäftswert
Hohes technisches Risiko	Modernisieren (Priorität 1)	Ablösen oder ersetzen (SaaS)
Niedriges technisches Risiko	Kapseln (API-Wrapper)	Belassen wie ist

Entscheidende Frage: Was kostet es, nichts zu tun? Wenn die Anwendung stabil läuft und die Geschäftsanforderungen statisch sind, kann es die richtige Antwort sein, sie hinter einer API zu kapseln und weiterzuziehen.

Ergebnis

Ein Modernisierungs-Entscheidungsdokument mit:

Anwendungslandschaftskarte mit Abhängigkeitsgraph
Risikobewertung pro Anwendung (technisch, Wissen, Compliance)
Empfohlene Modernisierungsstrategie pro Anwendung
Grössenordnung für Aufwand und Zeitplan
Risiken und Mitigationsstrategien

Unbequeme Wahrheit: Etwa 30 % der Legacy-Anwendungen, die wir bewerten, rechtfertigen keine Modernisierung. Zu wissen, wann man etwas in Ruhe lässt, ist ebenso wertvoll wie zu wissen, wann man handelt.

Phase 2: Strangler Fig — Funktionalität schrittweise ersetzen

Das Strangler-Fig-Muster ist die sicherste Modernisierungsstrategie. Benannt nach der Würgefeige, die ihren Wirtsbaum nach und nach umschliesst, ersetzt es Legacy-Funktionalität Stück für Stück, während das alte System weiterläuft.

So funktioniert es

Einen Bounded Context identifizieren am Rand des Legacy-Systems — idealerweise einen mit klaren Ein- und Ausgaben.
Die neue Implementierung bauen als unabhängigen Service oder Modul.
Traffic über eine Fassade routen (API-Gateway oder Reverse Proxy), die Anfragen an das alte oder neue System lenkt.
Traffic schrittweise verlagern von Legacy zu Neu. Mit 1 % starten, validieren, dann erhöhen.
Die Legacy-Komponente stilllegen, sobald 100 % des Traffics vom neuen System bedient wird.

Praktische Überlegungen

Mit der Komponente höchsten Werts und niedrigsten Risikos starten. Ein früher Erfolg schafft Vertrauen und sichert Budget für nachfolgende Phasen.
Die Fassade ist entscheidend. Sie muss Routing-Regeln, Traffic-Splitting und Rollback unterstützen. YARP auf .NET oder Azure Front Door eignen sich hier gut.
Alt und Neu mindestens 2 Wochen parallel betreiben nach vollständiger Umstellung. Das ist Ihr Sicherheitsnetz.
Datensynchronisation zwischen Alt und Neu ist das schwierigste Problem. Wenn beide Systeme in dieselben Daten schreiben, brauchen Sie eine Synchronisationsstrategie (Event-basiert, CDC oder Dual-Write mit Konfliktauflösung).

Anti-Patterns vermeiden

Gemeinsame Datenbank zwischen Alt und Neu. Das erzeugt versteckte Kopplung. Das neue System muss seine Daten besitzen.
Den gesamten Monolithen auf einmal strangulieren wollen. Einen Bounded Context auswählen, abschliessen, daraus lernen, dann den nächsten angehen.
Die Fassade überspringen. Ohne Routing-Schicht gibt es keinen schrittweisen Cutover und kein Rollback.

Phase 3: Containerisierung — Portabel und reproduzierbar

Sobald Funktionalität in neue Services migriert ist, sorgt Containerisierung für Deployment-Konsistenz und Infrastruktur-Portabilität.

Containerisierungsstrategie

Nicht alles braucht Kubernetes. Wir nutzen einen abgestuften Ansatz:

Stufe 1 — Azure Container Apps: Für die meisten zustandslosen Services. Gemanagt, serverlose Skalierung, minimaler Betriebsaufwand. Das ist unser Standard.
Stufe 2 — Azure Kubernetes Service (AKS): Für Workloads, die benutzerdefiniertes Networking, persistenten Speicher oder granulare Ressourcensteuerung benötigen.
Stufe 3 — Azure App Service: Für Legacy-.NET-Framework-Anwendungen, die noch nicht auf .NET 9 laufen können. Windows-Container-Support überbrückt die Lücke.

Containerisierungs-Checkliste

Gesamte Konfiguration externalisieren. Keine hartkodierten Connection Strings, keine Config-Dateien im Image. Umgebungsvariablen oder Azure App Configuration verwenden.
Health-Check-Endpoints. Liveness-, Readiness- und Startup-Probes für Kubernetes-basierte Deployments.
Strukturiertes Logging. JSON-Ausgabe auf stdout. Die Plattform (Container Apps, AKS) übernimmt die Log-Aggregation.
Graceful Shutdown. SIGTERM-Signale behandeln. Laufende Requests abarbeiten, bevor der Prozess endet.
Non-Root-User. Container als Non-Root ausführen für Security-Compliance.
Image-Scanning. Trivy oder Microsoft Defender for Containers in die CI-Pipeline integrieren.

Testen in Containern

Integrationstests laufen in Containern. Docker Compose oder Testcontainers verwenden, um Abhängigkeiten (Datenbanken, Message Broker) neben dem Service hochzufahren.
Performance-Baseline vorher und nachher. Containerisierung darf die Performance nicht verschlechtern. Falls doch, untersuchen — die Ursache sind meist falsch konfigurierte Resource Limits.

Phase 4: Datenmigration — Der schwierigste Teil

Datenmigration ist der Punkt, an dem Modernisierungsprojekte ins Stocken geraten oder scheitern. Legacy-Datenbanken tragen Jahrzehnte impliziter Geschäftsregeln, inkonsistenter Schemas und undokumentierter Beziehungen.

Optionen der Migrationsstrategie

1. Lift-and-Shift der Datenbank (temporär)

Datenbank in einen Managed Service verschieben (z. B. Azure SQL Managed Instance) ohne Schemaänderungen.
Verschafft Zeit, während der Anwendungscode modernisiert wird.
Kein Endzustand — ein Zwischenschritt.

2. Schema-Evolution (inkrementell)

Schema inkrementell mittels Datenbank-Migrationen ändern (EF Core Migrations, Flyway, Liquibase).
Änderungen hinter Feature Flags anwenden, damit alter und neuer Code koexistieren können.
Geeignet für Datenbanken, die unordentlich, aber grundsätzlich solide sind.

3. Vollständige Datentransformation (neues Schema)

Neues Schema basierend auf dem Domänenmodell entwerfen, nicht auf der Legacy-Struktur.
ETL-Pipelines zur Transformation und Validierung der Daten schreiben.
Dual-Write während der Transition: Neues System schreibt in beide Datenbanken.
Geeignet für Datenbanken, deren Legacy-Schema fundamental nicht zu den Geschäftsanforderungen passt.

Sicherheitsmassnahmen bei der Datenmigration

Zeilenzahl-Validierung: Sicherstellen, dass jede Quellzeile im Ziel vorhanden ist. Automatisieren.
Prüfsummen-Validierung: Für Finanzdaten Prüfsummen auf Quelle und Ziel berechnen. Jede Abweichung ist ein Showstopper.
Rollback-Plan: Die Möglichkeit bewahren, mindestens 30 Tage nach der Migration auf die Legacy-Datenbank zurückzuschalten.
Performance-Tests: Realistische Queries gegen das neue Schema mit Produktionsdaten-Volumen ausführen. Überraschungen in dieser Phase sind häufig.

Erfahrungswert: Planen Sie 40 % des gesamten Modernisierungsaufwands für die Datenmigration ein. Es ist immer komplexer als erwartet.

Risikomanagement über alle Phasen

Modernisierung ist inhärent risikobehaftet. Risiken explizit managen:

Feature Flags: Jede neue Fähigkeit hinter einem Feature Flag ausliefern. Das ermöglicht sofortiges Rollback ohne Deployment.
Canary Deployments: Einen kleinen Prozentsatz des Traffics auf das neue System routen und Fehlerraten beobachten, bevor der volle Rollout erfolgt.
Automatisierte Regressionstests: Vor Beginn der Modernisierung massiv in Integration- und End-to-End-Tests investieren. Das ist Ihr Sicherheitsnetz.
Kommunikationsplan: Stakeholder über Fortschritt, Risiken und Zeitplanänderungen informiert halten. Überraschungen untergraben Vertrauen und Budget.
Abbruchkriterien: Vorab definieren, wie Scheitern aussieht. Wenn Fehlerraten X % oder Latenz Y ms nach dem Cutover überschreiten, automatisch zurückrollen.

Der Weg nach vorn

Legacy-Modernisierung ist kein Technologieprojekt — es ist eine Geschäftstransformation, die zufällig Technologie beinhaltet. Der Phasenansatz beherrscht Risiken, liefert inkrementellen Wert und baut organisatorisches Vertrauen auf.

Bei CC Conceptualise begleiten wir Enterprise-Teams durch jede Phase der Legacy-Modernisierung — vom Assessment bis zum Produktions-Cutover. Wenn Ihre Legacy-Landschaft Ihr Geschäft bremst, sprechen Sie mit uns.