Legacy Software modernisieren und warten: Strategien für Altsysteme

Legacy Software ist kein Makel, sondern der Beweis, dass eine Anwendung über Jahre hinweg geschäftskritischen Nutzen gestiftet hat. Doch irgendwann erreicht jedes System einen Punkt, an dem Sicherheitsrisiken steigen, Fachkräfte knapp werden und die Wartungskosten den Nutzen übersteigen. Dieser Leitfaden zeigt, wann sich Modernisierung lohnt, wann laufende Wartung die bessere Strategie ist und wie Unternehmen den Übergang strukturiert angehen.

Ein Notebook liegt auf einem Müllhaufen aus Hardware. Im Hintergrund taucht die aufgehende Sonne das Szenario in hoffnungsvolles Licht. Ein Symbolbild dafür, Legacy Software modernisieren zu lassen.

1. Was macht Software zu Legacy Software?
2. Die drei Optionen: Warten, Modernisieren, Neubauen
3. Entscheidungshilfe: Warten oder Modernisieren?
4. End-of-Life-Management
5. Wartungsstrategie für Legacy-Systeme
6. Weiterführende Informationen

Was macht Software zu Legacy Software?

Der Begriff Legacy Software beschreibt keine technische Eigenschaft, sondern eine Situation: Eine Anwendung erfüllt ihren Zweck, lässt sich aber nur noch mit wachsendem Aufwand warten, erweitern oder absichern. Typische Merkmale:

Veraltete Technologiebasis: Programmiersprachen, Frameworks oder Laufzeitumgebungen, die vom Hersteller nicht mehr unterstützt werden (z. B. PHP 5.x, .NET Framework 4.5, Python 2, Windows Server 2012). Einen Leitfaden zur Modernisierung von PHP-Anwendungen bietet unser Artikel Legacy-PHP modernisieren.
Fehlende oder lückenhafte Dokumentation: Wissen über Architektur, Konfiguration und Abhängigkeiten existiert nur in den Köpfen weniger Personen
Technische Schulden: Über Jahre gewachsene Workarounds, veraltete Abhängigkeiten und fehlende Testabdeckung
Personalengpässe: Entwickler mit Expertise in der eingesetzten Technologie sind schwer zu finden oder teuer
Integrationsprobleme: Die Software lässt sich nur mit hohem Aufwand an moderne Systeme, APIs oder Cloud-Infrastruktur anbinden

Legacy bedeutet nicht automatisch schlecht. Viele Altsysteme laufen stabil und erfüllen ihren Zweck. Das Problem entsteht erst, wenn sich Anforderungen ändern (neue Sicherheitsstandards, regulatorische Pflichten wie NIS-2 oder das Barrierefreiheitsstärkungsgesetz, veränderte Geschäftsprozesse) und das System nicht mehr mithalten kann.

Einen Überblick zum Thema Weiterentwicklung von Unternehmenssoftware bietet unser Leitfaden Application Management. Für Mobile Anwendungen gelten dieselben Prinzipien mit eigenen Besonderheiten. Store-Compliance, Framework-Ökosysteme und Nutzererwartungen kommen dort als zusätzliche Treiber hinzu. Der Cluster zur App Modernisierung beleuchtet diese Seite im Detail.

Die drei Optionen: Warten, Modernisieren, Neubauen

Jedes Unternehmen mit einem Legacy-System steht vor derselben Grundsatzentscheidung. Die richtige Antwort hängt von einer ehrlichen Bewertung der aktuellen Situation ab.

Option 1: Weiterbetrieb mit professioneller Wartung

Wann sinnvoll: Das System läuft stabil, erfüllt die Geschäftsanforderungen und die Sicherheitslage ist beherrschbar. Die Technologiebasis wird zwar nicht mehr weiterentwickelt, aber es gibt noch Fachkräfte, die Fehler beheben und Anpassungen vornehmen können.

Vorteile:

Niedrigste kurzfristige Kosten
Kein Migrationsrisiko
Geschäftsbetrieb bleibt ungestört

Risiken:

Wachsende Wartungskosten, wenn Fachkräfte knapper werden
Sicherheitslücken ohne Herstellerpatches
Zunehmende Inkompatibilität mit modernen Systemen

Voraussetzung: Ein professioneller Wartungsvertrag mit einem Dienstleister, der die eingesetzte Technologie beherrscht und proaktives Monitoring, Sicherheitsupdates und eine Notfallstrategie bietet. Eine begleitende CI/CD-Checkliste für Unternehmen macht den Reifegrad dieser Wartungs-Pipeline objektiv messbar und erleichtert spätere Modernisierungs-Entscheidungen.

Option 2: Schrittweise Modernisierung

Wann sinnvoll: Das System hat Substanz, aber einzelne Komponenten sind veraltet, unsicher oder schlecht wartbar. Eine vollständige Neuentwicklung wäre unverhältnismäßig, weil große Teile der Geschäftslogik noch funktionieren.

Modernisierungsstrategien, die sich in der Praxis bewährt haben:

Strangler Fig Pattern: Neue Funktionalität wird in modernen Technologien gebaut und schrittweise neben das Altsystem gestellt. Über Zeit wird immer mehr Funktionalität in die neue Architektur verlagert, bis das Legacy-System abgelöst ist, ohne Big-Bang-Migration.

Replatforming: Die Anwendung wird auf eine moderne Infrastruktur gehoben (z. B. von On-Premise in die Cloud, von einem veralteten Applikationsserver auf Container), ohne die Geschäftslogik grundlegend umzuschreiben. Behörden stützen den Cloud-Bezug dabei auf den EVB-IT-Cloud-Vertrag.

Refactoring: Gezieltes Überarbeiten kritischer Codebereiche, also Abhängigkeiten aktualisieren, Testabdeckung aufbauen, Architektur bereinigen. Das System bleibt im Kern erhalten, wird aber schrittweise wartbarer.

API-Layer: Ein moderner API-Layer wird vor das Legacy-System gesetzt. Neue Anwendungen und Integrationen kommunizieren über die API, das Altsystem wird dahinter isoliert. Das reduziert die Abhängigkeit vom Legacy-Code, ohne ihn sofort ablösen zu müssen.

Option 3: Neuentwicklung

Wann sinnvoll: Die technische Schuld ist so hoch, dass jede Änderung unverhältnismäßig teuer und riskant ist. Die Geschäftsanforderungen haben sich fundamental verändert. Es gibt keine Fachkräfte mehr für die eingesetzte Technologie.

Vorteile:

Moderne Architektur ohne Altlasten
Aktuelle Sicherheitsstandards von Beginn an
Bessere Wartbarkeit und Erweiterbarkeit

Risiken:

Hohe Vorabinvestition
Migrationsrisiko (Daten, Prozesse, Schnittstellen)
Längerer Zeitraum bis zum produktiven Einsatz

Entscheidungshilfe: Warten oder Modernisieren?

Diese Fragen helfen bei der Bewertung:

Sicherheit: Gibt es bekannte Schwachstellen in eingesetzten Komponenten, für die keine Patches mehr verfügbar sind? Wenn ja: Modernisierung oder Isolation hat Vorrang.

Compliance: Erfüllt das System aktuelle regulatorische Anforderungen (DSGVO, NIS-2, Barrierefreiheit)? Wenn nicht: Abwägen, ob Nachrüstung möglich ist oder eine Ablösung effizienter wäre.

Kosten: Wie hoch sind die jährlichen Wartungskosten im Verhältnis zum Geschäftswert? Wenn die Wartung mehr als 50 % der ursprünglichen Entwicklungskosten pro Jahr verschlingt, lohnt sich die Wirtschaftlichkeitsbetrachtung einer Ablösung.

Personal: Gibt es intern oder am Markt noch Fachkräfte für die eingesetzte Technologie? Wenn die letzte Person mit Systemwissen das Unternehmen verlässt, steht der Betrieb auf dem Spiel.

Geschäftswert: Wird das System noch aktiv für Kernprozesse genutzt, oder ist es eine Randanwendung mit wenigen Nutzern? Randanwendungen rechtfertigen selten eine teure Modernisierung.

End-of-Life-Management

Jede Software hat einen Lebenszyklus. End of Life (EOL) bezeichnet den Zeitpunkt, ab dem ein Hersteller keine Updates, Patches oder Support mehr liefert. Für Unternehmen bedeutet EOL nicht, dass die Software sofort abgeschaltet werden muss, aber es erfordert eine bewusste Entscheidung.

Was passiert nach End of Life?

Keine Sicherheitspatches: Bekannt gewordene Schwachstellen bleiben offen. Das Risiko für Angriffe steigt mit jeder neuen Veröffentlichung im CVE-Verzeichnis.
Keine Kompatibilitäts-Updates: Neue Betriebssystemversionen, Browser oder APIs werden nicht mehr unterstützt.
Kein Hersteller-Support: Bei Problemen gibt es keine offizielle Anlaufstelle mehr.

EOL-Strategie entwickeln

Eine strukturierte EOL-Strategie umfasst:

Inventur: Welche Komponenten stehen wann vor dem End of Life? (Betriebssystem, Laufzeitumgebung, Frameworks, Bibliotheken)
Risikobewertung: Wie kritisch ist die Komponente? Welche Angriffsfläche entsteht ohne Patches?
Zeitplan: Wann muss spätestens migriert oder abgelöst werden? Rückwärtsplanung ab EOL-Datum.
Budget: Modernisierung ist planbar. Ungeplante Notfallmigrationen nach einem Sicherheitsvorfall sind es nicht.
Übergangswartung: Für die Zeit zwischen EOL und Ablösung braucht es einen Dienstleister, der kompensatorische Maßnahmen umsetzen kann, etwa Netzwerkisolation, zusätzliches Monitoring oder Application-Level-Firewalling.

Wartungsstrategie für Legacy-Systeme

Wenn die Entscheidung für den Weiterbetrieb fällt, braucht es eine Wartungsstrategie, die den besonderen Herausforderungen von Altsystemen gerecht wird:

Proaktives Monitoring: Legacy-Systeme zeigen Probleme oft schleichend (steigende Antwortzeiten, wachsende Logdateien, zunehmende Fehlerquoten). Professionelles Software-Monitoring erkennt diese Muster, bevor sie zum Ausfall führen.

Wissensmanagement: Die größte Gefahr bei Legacy-Systemen ist der Wissensverlust. Jede Wartungsmaßnahme sollte dokumentiert werden, nicht nur was getan wurde, sondern warum. Architekturentscheidungen, bekannte Eigenheiten und Workarounds müssen festgehalten werden.

Isolationsstrategie: Systeme, die nicht mehr gepatcht werden können, sollten so weit wie möglich vom Netzwerk isoliert werden. Ein vorgeschalteter API-Gateway, restriktive Firewall-Regeln und eingeschränkte Zugriffsrechte begrenzen die Angriffsfläche.

Testinfrastruktur: Gerade bei Altsystemen ist eine Testumgebung unverzichtbar. Jede Änderung, auch ein scheinbar harmloses Library-Update, kann unerwartete Seiteneffekte haben. Ohne Testmöglichkeit wird jede Wartungsmaßnahme zum Risiko.

Weiterführende Informationen

FAQs

Wann ist es besser, Legacy Software zu modernisieren statt zu warten?

Modernisierung ist sinnvoll, wenn: (1) die jährlichen Wartungskosten in die Größenordnung von 40 bis 50 Prozent der ursprünglichen Entwicklungskosten rücken, (2) keine Fachkräfte für die alte Technologie verfügbar sind, (3) neue Anforderungen (DSGVO, NIS-2, Barrierefreiheit) sich technisch nicht nachrüsten lassen, (4) das System laufend neue Fehler verursacht. Der Weiterbetrieb ist sinnvoll, wenn das System stabil läuft, die Technologie noch am Markt unterstützt wird und keine neuen Funktionen geplant sind.

Wie viel kostet eine Software-Modernisierung?

Die Kosten hängen stark vom Umfang und vom gewählten Weg ab. Eine schrittweise Modernisierung (Strangler Fig Pattern) verteilt den Aufwand über Jahre und liegt erfahrungsgemäß deutlich unter dem einer Neuentwicklung. Ein vollständiger Neubau ist der teuerste Weg, dafür in der Regel schneller abgeschlossen. Am günstigsten ist meist das Replatforming, bei dem die Anwendung ohne Umbau der Geschäftslogik auf eine moderne Infrastruktur gehoben wird. Wenn die Wartungskosten bereits hoch sind, kann Modernisierung günstiger sein als fortlaufende Fehlerbehebung. Eine belastbare Zahl ergibt sich erst aus einer Analyse des konkreten Systems.

Was ist das größte Risiko bei der Weiterlaufzeit von Legacy-Systemen?

Das größte Risiko ist der Wissensverlust. Wenn der einzige Mensch, der das alte System kennt, das Unternehmen verlässt, kann der Support zusammenbrechen. Zweites Risiko: Sicherheit. Legacy-Systeme ohne Herstellersupport erhalten keine Sicherheitspatches, Schwachstellen bleiben offen und können gezielt ausgenutzt werden. Drittes Risiko: Neue Anforderungen aus Compliance und Datenschutz lassen sich technisch oft nicht mehr umsetzen. Deshalb sind Dokumentation und Wissensmanagement bei Legacy-Systemen entscheidend.