Legacy-Modernisierung — Alte Software zukunftsfähig machen 2026

In rund 70 Prozent der von uns auditierten Mittelständler läuft mindestens eine kritische Anwendung auf einer Technologie, die zwischen 15 und 30 Jahre alt ist — VB6, VB.NET, Delphi 7, AS/400 mit RPG, klassisches ASP, alte PHP-Monolithen, Access mit Excel-VBA. Diese Systeme tragen oft den Kern der Wertschöpfung. Genau deshalb blieb sie zwei Jahrzehnte unangetastet. Für Geschäftsführung, CFO und IT-Leitung ist das 2026 aus drei Gründen akut: erstens trocknet der Arbeitsmarkt für die alten Sprachen aus und ein einziger Entwicklerausfall kann zum Stillstand führen, zweitens verlieren Plattformen wie Windows Server 2012/2016 und ältere .NET-Frameworks den Hersteller-Support, drittens verlangen DSGVO, NIS2 und Cyber-Versicherer dokumentierte Patch-Stände, die mit Legacy-Stacks oft nicht erreichbar sind. Dieser Artikel zeigt, wie eine wirtschaftlich tragfähige Modernisierung aussieht — von der Bewertung über die 4R-Strategie und das Strangler-Fig-Pattern bis zum realistischen Phasenplan. Für die Einordnung siehe unseren Softwareentwicklungs-Guide.

Warum 2026 die Legacy-Welle voll trifft

Die Diskussion ist nicht neu — neu ist die Gleichzeitigkeit von drei Druckfaktoren, die sich gegenseitig verstärken. Erstens die Skill-Knappheit: der Arbeitsmarkt für Visual Basic, Delphi, RPG, COBOL und klassisches ASP ist faktisch leer. Wer 2026 einen VB6-Entwickler sucht, findet kurz vor der Rente stehende Spezialisten oder niemanden mehr. Die wenigen Kandidaten verlangen Tagessätze, die mit modernen .NET- oder TypeScript-Entwicklern vergleichbar sind, häufig sogar darüber. Das ändert die Wirtschaftlichkeits-Rechnung für „wir bleiben auf dem Alten" grundlegend.

Zweitens die Hersteller-Roadmaps. Microsoft pflegt Visual Basic 6 seit 2008 nicht mehr aktiv, der erweiterte Support für viele .NET-Framework-Versionen ist beendet, Windows Server 2012 R2 hat im Oktober 2023 den erweiterten Support verloren, Windows Server 2016 läuft auf das gleiche Ende zu. Embarcadero hält Delphi am Leben, aber jede Version verlangt Lizenz-Investitionen, die für isolierte Altsysteme schwer zu rechtfertigen sind. IBM unterstützt AS/400 weiter, doch die Anzahl der Entwickler mit produktiver RPG-Kompetenz sinkt jedes Jahr messbar. Wer auf einer aus dem Support gelaufenen Plattform bleibt, akzeptiert ungepatchte Sicherheits-Lücken und eine wachsende Diskrepanz zur restlichen IT-Landschaft.

Drittens der regulatorische Druck. DSGVO Artikel 32 verlangt „Maßnahmen zur Gewährleistung der Sicherheit der Verarbeitung" — Aufsichtsbehörden interpretieren das zunehmend als Pflicht, Software auf einem patchbaren Stand zu halten. NIS2 hebt die Anforderung an Verfügbarkeit, Vorfall-Erkennung und Lieferanten-Sicherheit auf ein Niveau, das ein typischer VB6-Monolith strukturell nicht erfüllen kann. Cyber-Versicherer fragen in Antrags-Formularen explizit nach Support-Stand von Betriebssystem, Datenbank und Laufzeit-Umgebung. Ein „Nein" bedeutet Prämien-Aufschlag oder Ausschluss bestimmter Schadens-Kategorien — beides teurer als die Modernisierung selbst.

Typische Mittelstands-Legacy in Deutschland

Bei aller Branchen-Vielfalt wiederholt sich das technische Bild im deutschen Mittelstand erstaunlich oft. Die folgende Übersicht fasst die fünf häufigsten Legacy-Muster zusammen — sie deckt etwa 80 Prozent der real angetroffenen Altsysteme ab.

Stack	Typisches Einsatzfeld	Hauptrisiko 2026
VB6 / VB.NET (älteres Framework)	Branchen-Lösungen, ERP-Erweiterungen, Werkstatt-Software	Skill-Knappheit, fehlende Web-Fähigkeit, COM-Abhängigkeiten
Delphi 7 bis XE	Maschinenbau-Steuerung, Praxis- und Anwalts-Software, kaufmännische Tools	Lizenz-Kosten, 32-Bit-Bindung, fehlende Cloud-Anbindung
AS/400 / IBM i mit RPG	Logistik, Großhandel, Produktion, Bank-Backoffice	Stark schrumpfender Entwicklerpool, 5250-Bedienung, Schnittstellen-Lücken
On-Prem-PHP-Monolithen (PHP 5.x / frühe 7.x)	Selbst gebaute Shops, Portale, Branchen-Verwaltungen	Veraltete Bibliotheken, Sicherheits-Lücken, keine API-Schicht
Microsoft Access mit Excel-VBA	Provisions-Berechnung, Reporting, Disposition, „Schatten-IT"	Datenintegrität, Mehrbenutzer-Probleme, fehlende Auditierbarkeit

Eine wiederkehrende Beobachtung: das wirtschaftlich relevanteste Legacy-System ist oft nicht das offensichtliche Branchen-Tool, sondern die Excel-Datei mit 40 Tabellenblättern und VBA-Makros, die in der Buchhaltung über Jahre gewachsen ist. Diese „Schatten-IT" ist meist undokumentiert, hängt an einer Person und enthält Berechnungen, die sich in keinem ERP wiederfinden. Eine seriöse Bewertung beginnt deshalb nicht mit dem größten System, sondern mit dem höchsten Risiko pro Stunde Ausfall.

Bewertung — bevor Sie eine Zeile Code schreiben

Modernisierungs-Projekte scheitern oft nicht an der Umsetzung, sondern an fehlender ehrlicher Bestandsaufnahme. Vor jedem technischen Konzept brauchen Geschäftsführung und IT-Leitung Antworten auf fünf Fragen pro Anwendung. Dieses Raster ist in vier bis acht Wochen durchführbar.

• Code-Qualität und LesbarkeitWie viele Entwickler im Haus oder im erreichbaren Markt verstehen den Code? Existieren Coding-Standards, Versionskontrolle, Build-Automatisierung? Wir messen das mit einer kurzen Code-Tour: drei Senior-Entwickler bekommen einen typischen Fehler-Bericht und sollen die wahrscheinliche Ursache lokalisieren. Brauchen sie länger als zwei Stunden, ist die Lesbarkeit kritisch.
• Test-Coverage und Regressions-SicherheitExistieren automatisierte Tests? Wenn ja, welche Coverage? In den meisten Legacy-Anwendungen liegt die Coverage bei null — das ist die wichtigste Einzel-Erkenntnis, weil sie die Modernisierungs-Strategie stark einschränkt. Ohne Tests gilt: kein Refactoring, sondern zuerst Test-Harness rückwirkend aufbauen.
• Doku-Lage und implizites WissenWie viel des fachlichen Wissens steckt in Köpfen statt in Dokumenten? Wie viele der ursprünglichen Entwickler sind noch im Haus oder erreichbar? Eine Anwendung mit zwei verbliebenen Wissensträgern und keiner Doku ist ein Klumpenrisiko ersten Ranges.
• Domain-Wert und Geschäfts-KritikalitätWelchen Anteil am Umsatz oder an den Kernprozessen trägt diese Anwendung? Was kostet ein Ausfall pro Stunde, pro Tag? Anwendungen mit hohem Domain-Wert verdienen Refactoring oder kontrollierten Rewrite, Anwendungen mit niedrigem Domain-Wert sind Kandidaten für Replace oder Retire.
• Technisches Risiko und Support-StatusIst die Laufzeit-Umgebung noch im Hersteller-Support? Gibt es Sicherheits-Patches? Wie aktuell sind die Bibliotheken? Eine Anwendung auf einer aus dem Support gelaufenen Plattform mit hoher Geschäfts-Kritikalität ist ein Notfall, kein Projekt.

Aus dieser Bewertung entsteht eine Anwendungs-Landkarte — eine Matrix aus Domain-Wert und technischem Risiko. Jede Anwendung landet in einem Quadranten mit einer Standard-Strategie. Diese Landkarte verteilt Modernisierungs-Budget über zwei bis drei Jahre rational.

Die vier Strategien — Rewrite, Refactor, Replace, Retire

Sobald die Bewertung steht, ist die Strategie-Wahl die wichtigste Entscheidung. Das 4R-Modell — Rewrite, Refactor, Replace, Retire — strukturiert sie entlang von Geschäfts-Wert und Aufwand.

Strategie	Wann sinnvoll	Typische Dauer	Risiko-Profil
Refactor	Code lesbar, Team kennt die Sprache, Technologie hat Support, fachliche Anforderungen stabil	3–9 Monate	Niedrig — bestehende Funktionalität bleibt
Rewrite	Technologie ohne Support, kein Team, oder fachliche Neuausrichtung	9–24 Monate	Hoch — Funktions-Lücken und Überziehung sind die Norm
Replace	Standard-Funktionalität, am Markt verfügbares SaaS oder ERP-Modul deckt 80%+ ab	3–12 Monate	Mittel — Anpassungs-Schmerz, Lock-in-Risiko
Retire	Anwendung wird kaum noch genutzt, Funktion lässt sich anderweitig abbilden	1–4 Monate	Niedrig — wenn Datenarchiv sauber gesichert wird

Die häufigste Fehl-Entscheidung in der Praxis ist „Rewrite", weil sie intuitiv attraktiv wirkt — endlich saubere Architektur, moderne Sprache, frischer Code. Tatsächlich übersteigen reine Rewrites das ursprünglich geplante Budget in mehr als der Hälfte der Fälle um über 100 Prozent, und in etwa einem Viertel der Fälle wird das Projekt vor Fertigstellung abgebrochen. Der Grund: in der alten Anwendung steckt zwei Jahrzehnte implizites Domain-Wissen, das nirgends dokumentiert ist und das im Rewrite mühsam neu entdeckt wird. Wir empfehlen Rewrite-Projekten daher fast immer einen Strangler-Fig-Modus — also schrittweise Migration neben dem Altsystem, nicht parallele Neu-Entwicklung mit anschließendem Big-Bang-Wechsel. Vergleichbare Überlegungen finden sich in unserem Cluster zu Monolith vs Microservices und Custom-Software vs Standard-Lösung.

Das Strangler-Fig-Pattern

Das von Martin Fowler 2004 beschriebene Strangler-Fig-Pattern ist heute der De-facto-Standard für risikoarme Modernisierung. Der Name kommt von der Würgefeige, die einen alten Baum umwächst und nach und nach ersetzt. Übertragen auf Software: das Altsystem läuft produktiv weiter, während ein Routing-Layer neue Aufrufe Stück für Stück an neu gebaute Komponenten umlenkt.

Der Ablauf folgt einer wiederkehrenden Schleife. Zuerst wird ein abgrenzbarer fachlicher Bereich identifiziert — etwa „Stammdaten Kunden" oder „Provisions-Berechnung". Für diesen Bereich entsteht im Neusystem eine eigenständige Komponente. Davor wird ein Routing-Layer eingezogen — typischerweise API-Gateway oder Reverse-Proxy — der pro Aufruf entscheidet, ob Alt oder Neu antwortet. Zunächst läuft der Aufruf parallel in beiden Welten, die Ergebnisse werden verglichen. Sobald die Übereinstimmung über mehrere Wochen stabil ist, wird der Routing-Schalter umgelegt. Erst nach ein bis drei Monaten ohne Auffälligkeit wird der alte Codeblock entfernt.

Diese Methodik hat drei Vorteile gegenüber Big-Bang. Erstens bleibt das Geschäft jederzeit produktiv — kein Wochenend-Cutover. Zweitens ist das Risiko klein, weil immer nur ein begrenzter Bereich gleichzeitig umgestellt wird. Drittens erzeugt der Vergleichs-Modus eine empirische Validierung — Abweichungen werden sichtbar, bevor sie produktiv schaden. Der Preis ist Komplexität im Übergang: zwei Systeme parallel, ein Routing-Layer, Dual-Write-Logik.

Anti-Corruption-Layer und Daten-Migration

Eine Heraus­forderung beim Strangler-Fig-Pattern ist der semantische Bruch zwischen alter und neuer Welt. Das Altsystem hat über Jahre Datenmodelle entwickelt, die nicht zur neuen Architektur passen — kryptische Spalten­namen, hartcodierte Mappings, sich überlagernde Begriffe. Würde man diese Strukturen unverändert übernehmen, wäre der Modernisierungs-Nutzen verspielt.

Die Lösung ist ein Anti-Corruption-Layer, eine Übersetzungsschicht zwischen alter und neuer Welt. Sie übersetzt Daten und Aufrufe in die saubere Begrifflichkeit des Neusystems und umgekehrt. Diese Schicht kostet zusätzliche Entwicklungs-Zeit, schützt aber das Neusystem davor, die strukturellen Schwächen der Altwelt zu erben.

Für die Daten-Migration haben sich drei Muster bewährt. Erstens klassische ETL-Strecken — Daten zu einem Stichtag extrahieren, transformieren und laden, geeignet für einmalige Schnitte. Zweitens Dual-Write — gleichzeitiges Schreiben in alte und neue Datenbank während der Übergangs-Zeit. Drittens Change-Data-Capture — ereignis­basierte Synchronisation über Datenbank-Logs mit Werkzeugen wie Debezium, das mächtigste Verfahren für große Datenbestände. Wer die Daten-Migration unterschätzt, scheitert oft genau hier — Inkonsistenzen entdeckt man erst Wochen nach dem Schnitt, wenn Reports nicht mehr stimmen. Mehr zu Cloud-Migrations-Mustern in unserem Cloud-Migrations-Leitfaden.

Test-Harness rückwirkend aufbauen

Die wichtigste technische Vorarbeit jeder größeren Modernisierung ist ein Sicherheits-Netz aus Tests. In den meisten Legacy-Anwendungen liegt die automatisierte Coverage bei null — ohne Test-Netz ist jede Änderung russisches Roulette. Zwei Test-Arten haben sich für rückwirkende Absicherung bewährt.

Approval-Tests — auch Snapshot-Tests — vergleichen die Ausgabe einer Funktion mit einem abgesegneten Referenz-Ergebnis. Sie eignen sich für Reports, Rechnungs-Berechnungen und komplexe Logik, deren Korrektheit niemand mehr im Detail nachvollzieht, deren Ausgabe aber als „richtig" gilt. Man füttert die Funktion mit realen Produktions-Eingaben, speichert die Ausgaben, und ab dem Moment schlägt jede ungeplante Änderung Alarm. Approval-Tests sind in wenigen Tagen aufsetzbar, ohne die Logik vollständig zu verstehen.

Characterization-Tests dokumentieren das tatsächliche Verhalten — inklusive bekannter Eigenheiten und Bugs, die in der Praxis zu Features geworden sind. Sie sind die Basis dafür, dass Refactoring oder Strangler-Migration nichts unbemerkt verändert. Ihre Erstellung ist die wichtigste Aufgabe in den ersten Wochen jedes Modernisierungs-Projekts.

KI-Unterstützung bei Legacy-Modernisierung 2026

Mit den großen Sprachmodellen der Jahrgänge 2024–2026 sind in der Modernisierung drei Einsatzbereiche produktionsreif. Erstens Reverse-Engineering: ein modernes Modell liest einen 1.500 Zeilen langen VB-Codeblock und erzeugt in wenigen Sekunden eine lesbare fachliche Beschreibung, Sequenz­diagramme und eine Liste der externen Abhängigkeiten. Diese Doku ist nie eins zu eins korrekt, aber ein dramatisch besserer Startpunkt als das leere Word-Dokument.

Zweitens Test-Generierung. Modelle schlagen aus Legacy-Code Approval- und Characterization-Tests vor, häufig mit gut gewählten Eingaben und Grenzfällen. Das Ergebnis ist ein Erstentwurf, kein fertiges Test-Set, aber die Geschwindigkeit beim Aufbau eines Test-Netzes steigt um den Faktor drei bis fünf.

Drittens die Code-Übersetzung, etwa von VB.NET nach C# oder von klassischem PHP nach TypeScript. Hier sind Modelle gut, aber nicht fehlerfrei — fachliche Subtilitäten, Datentyp-Konvertierungen, Datums-Logik und Locale-Themen sind die häufigen Fehler-Quellen. Vollautomatische Migration ohne Senior-Review führt nahezu garantiert zu subtilen Fehlern, die erst Wochen später in Reports auftauchen. Realistische Produktivitäts-Steigerung durch KI liegt bei 30 bis 50 Prozent — deutlich besser als Skeptiker behaupten, deutlich schlechter als Hersteller-Folien suggerieren.

Realistischer Phasenplan über 6 bis 18 Monate

Modernisierungen mittlerer Größe folgen einem wiederkehrenden Ablauf. Die Zeitschiene unten beschreibt einen typischen Strangler-Fig-Verlauf für rund 100.000 Zeilen Code, 50 bis 200 Nutzer und mittleren Daten-Bestand.

• Wochen 1–4: Bewertung und StrategieAnwendungs-Landkarte erstellen, Stakeholder-Interviews, Code-Tour, Bewertung der fünf Kriterien aus Abschnitt 3, Strategie-Entscheidung nach 4R-Modell, Auswahl des Ziel-Stacks. Ergebnis: ein zwölf- bis zwanzig­seitiges Strategie-Dokument als Geschäftsführungs-Vorlage.
• Wochen 5–12: Test-Harness und SpikeApproval- und Characterization-Tests für die kritischen 20 Prozent der Funktionalität aufbauen, technischer Spike für einen kleinen, klar abgrenzbaren fachlichen Bereich, Aufbau von Build-Pipeline und Routing-Layer. Ergebnis: ein erstes laufendes Neusystem-Modul mit parallelem Vergleich gegen das Alt­system.
• Monate 4–9: Hauptmigration in WellenSechs bis zwölf fachliche Bereiche werden in aufeinanderfolgenden Wellen migriert. Jede Welle folgt dem gleichen Muster: implementieren, parallel laufen lassen, vergleichen, umschalten, alten Code rückbauen. Daten-Migration läuft parallel über Dual-Write oder Change-Data-Capture.
• Monate 10–14: Konsolidierung und OptimierungDie letzten kleineren fachlichen Bereiche werden migriert, der Anti-Corruption-Layer wird zurückgebaut, Performance-Optimierung, Daten-Bereinigung, Schulungen für Anwender und Betrieb.
• Monate 15–18: Abschluss und RückbauVollständiger Abbau des Alt­systems, finale Daten-Archivierung gemäß Aufbewahrungs-Fristen, Übergabe an den Regel-Betrieb, Retrospektive für die nächste Modernisierungs-Welle.

Die Aufwands-Verteilung überrascht viele Geschäftsführungen. Reine Programmier-Arbeit macht selten mehr als 40 Prozent aus. Bewertung, Test-Harness, Daten-Migration und Schulung sind zusammen der größere Block. Wer Modernisierung als reines Entwicklungs-Projekt plant, unterschätzt das Gesamt-Budget regelmäßig um 50 bis 80 Prozent.

Wie wir bei Reepa Modernisierungen begleiten

Unser Ansatz ist bewusst zurückhaltend: wir beginnen mit einer vierwöchigen Bewertungs-Sitzung, in der wir Anwendungs-Landkarte, 4R-Empfehlung und ein erstes Strategie-Dokument liefern — ohne dass eine Entwicklungs-Entscheidung schon gefallen ist. Diese Bewertung ist klein dimensioniert, weil sie die wichtigste Investition vor jeder größeren Budget-Freigabe ist.

In der Umsetzungs-Phase übernehmen wir je nach Konstellation eine von drei Rollen: vollständige Modernisierung als General-Auftragnehmer, gemischte Teams mit Kunden-Wissensträgern und unseren Senior-Entwicklern, oder reine Begleit-Rolle mit Test-Harness, Architektur-Reviews und KI-Werkzeug-Auswahl, während das Kunden-Team implementiert. Welche Rolle passt, hängt von interner Kapazität und Strategie ab — eine Refactor-Strategie funktioniert intern, ein Strangler-Fig-Rewrite verlangt mehr Senior-Erfahrung, als die meisten Mittelständler bereitstellen können.

Technologisch sind wir breit aufgestellt: aus dem alten Stack heraus modernisieren wir typischerweise nach .NET 8/9, modernem PHP, Java oder TypeScript. Die Auswahl folgt nicht der Mode, sondern der Verfügbarkeit von Entwicklern auf dem deutschen Markt — die wichtigste Kennzahl für Wartbarkeit ist 2026 nicht die Coolness der Sprache, sondern die Zahl der Entwickler, die sie produktiv beherrschen.

Häufige Fragen