Kurz zusammengefasst: Eine Legacy-Anwendung ist nicht deshalb ein Risiko, weil sie alt ist. Kritisch wird sie, wenn Sicherheitsupdates nicht mehr zuverlässig eingespielt werden können, zentrale Komponenten aus dem Support laufen, Abhängigkeiten unbekannt sind oder nur noch einzelne Mitarbeiter wissen, wie das System funktioniert. Dann reicht „Das läuft doch noch“ als Betriebsstrategie nicht mehr aus.
„Das System läuft doch.“
Der Satz fällt erstaunlich häufig, wenn es um ältere Anwendungen geht. Und zunächst ist daran auch nichts falsch. Eine Anwendung erfüllt ihren Zweck, die Nutzer kennen sie und ein Austausch würde Geld, Zeit und Kapazitäten binden. Das eigentliche Problem ist deshalb nicht das Alter einer Anwendung. Kritisch wird es, wenn niemand mehr zuverlässig sagen kann, ob und wie sie sich sicher verändern lässt.
Ein typischer Fall sieht so aus: Eine geschäftskritische Anwendung läuft seit zwölf Jahren. Das Betriebssystem wird noch unterstützt, das verwendete Framework aber nicht mehr. Einige Bibliotheken wurden seit Jahren nicht aktualisiert. Dazu kommen eine ältere Datenbank und mehrere Schnittstellen, die über die Jahre gewachsen sind.
Dann erscheint ein kritischer Security-Patch.
Technisch wäre die Installation möglich. Das Team weiß aber nicht genau, welche Auswirkungen das Update auf die Anwendung und ihre Schnittstellen hätte. Automatisierte Tests gibt es kaum, die Dokumentation ist lückenhaft.
Also wird der Patch verschoben. Die Anwendung läuft weiter.
Und genau an diesem Punkt wird aus technischer Schuld ein handfestes Sicherheits- und Betriebsrisiko.
Legacy ist keine Altersangabe
Eine Anwendung von 2012 ist nicht automatisch problematisch. Und eine Anwendung von 2022 ist nicht automatisch modern.
Für die Bewertung ist deshalb eine andere Definition hilfreicher:
Eine Legacy-Anwendung wird kritisch, wenn ihr sicherer Betrieb oder ihre kontrollierte Veränderung nicht mehr zuverlässig gewährleistet werden kann.
Typische Warnzeichen sind:
- Betriebssysteme, Datenbanken oder Frameworks sind End of Life oder kurz davor
- Sicherheitsupdates können nicht zeitnah installiert werden
- Abhängigkeiten und verwendete Bibliotheken sind nicht vollständig bekannt
- Automatisierte Tests fehlen
- Deployments erfolgen überwiegend manuell
- Schnittstellen sind schlecht oder gar nicht dokumentiert
- Änderungen verursachen regelmäßig unerwartete Nebeneffekte
- Für zentrale Teile der Anwendung gibt es nur einzelne Wissensträger
- Backup und Restore existieren zwar, wurden aber lange nicht getestet
- Niemand kann belastbar sagen, wie lange die Anwendung nach einem Totalausfall ausfallen würde
Keiner dieser Punkte macht aus einer Anwendung automatisch ein Hochrisikosystem. Treffen jedoch mehrere davon auf ein geschäftskritisches System zu, sollte „läuft noch“ nicht die einzige Bewertung bleiben.
Warum Legacy-Systeme ein Sicherheitsrisiko werden können
Bei Cybersecurity dreht sich viel um Zero-Days, neue Angriffsmethoden und spektakuläre Angriffskampagnen.
Das deutlich banalere Problem sind bekannte Schwachstellen, für die längst technische Details oder sogar fertige Exploits verfügbar sind.
Die ENISA führt in ihren „Foresight Cybersecurity Threats for 2030“ sowohl ausgenutzte Legacy-Systeme als auch die Ausnutzung ungepatchter und veralteter Systeme unter den wichtigsten zukünftigen Cyberbedrohungen.
Dafür braucht es keinen hochinnovativen Angriffsweg. Wenn ein erreichbares System eine seit Monaten bekannte Schwachstelle enthält, kann genau diese Schwachstelle bereits ausreichen.
Wie real das Problem ist, zeigte 2025 Ivanti Connect Secure. Das BSI warnte im April vor einer kritischen Schwachstelle, die bereits auf ungepatchten und End-of-Support-Systemen ausgenutzt wurde. Zu diesem Zeitpunkt waren in Deutschland noch mehr als 180 Systeme mit veralteten Software-Versionen erreichbar.
Für IT-Verantwortliche ist deshalb nicht nur die Frage entscheidend:
Welche Schwachstellen haben wir?
Mindestens genauso wichtig ist:
Bei welchen Systemen sind wir überhaupt noch in der Lage, eine Schwachstelle kurzfristig und kontrolliert zu beheben?
Warum Patchmanagement bei Legacy-Anwendungen schwierig wird
Ein ungepatchtes System ist ein Risiko. Ein schlecht vorbereiteter Patch kann aber ebenfalls zum Problem werden. Genau zwischen diesen beiden Polen bewegen sich viele Legacy-Anwendungen. Das Security-Team sagt: Wir müssen patchen.
Der Anwendungsverantwortliche sagt: Wir wissen nicht sicher, ob die Anwendung danach noch funktioniert. Beide Seiten haben einen Punkt. Bei gut wartbaren Anwendungen lässt sich das Änderungsrisiko begrenzen. Automatisierte Tests, Staging-Umgebungen, reproduzierbare Deployments, Rollback-Verfahren, Monitoring und eine nachvollziehbare Infrastruktur schaffen die Grundlage dafür. Bei Legacy-Anwendungen fehlen häufig mehrere dieser Voraussetzungen. Dann wird aus einem normalen Sicherheitsupdate plötzlich eine Risikoabwägung für den laufenden Betrieb. Besonders ungünstig wird es, wenn bekannte Schwachstellen bewusst weiterbetrieben werden, weil die Angst vor einem Ausfall durch den Patch größer ist als die Angst vor der Sicherheitslücke. Kurzfristig kann diese Entscheidung nachvollziehbar sein. Dauerhaft sollte daraus aber kein Betriebsmodell werden.
Das Betriebssystem ist oft gar nicht das größte Problem
Bei Legacy-Diskussionen landet der Blick schnell beim Server oder beim Betriebssystem. Das greift zu kurz.
Zu einer Anwendung gehören häufig:
- Frameworks,
- Libraries und Packages,
- Datenbanken,
- Runtime-Versionen,
- Webserver,
- APIs,
- Authentifizierungskomponenten,
- Drittanbieter-Software,
- Betriebssysteme,
- externe Dienste.
Entscheidend ist die gesamte Abhängigkeitskette, denn ein aktuelles Betriebssystem hilft nur begrenzt, wenn darauf eine Anwendung läuft, die wiederum von einer Bibliothek abhängt, die seit Jahren nicht mehr gepflegt wird.
ENISA hat dieses Thema im März 2026 erneut aufgegriffen. Nicht mehr gepflegte oder aufgegebene Softwarepakete können zum Sicherheitsrisiko werden, weil Schwachstellen ungepatcht bleiben und Abhängigkeiten weiter veralten.
Log4Shell hat außerdem ziemlich eindrucksvoll gezeigt, warum Transparenz über Softwareabhängigkeiten wichtig ist.
Die Schwachstelle steckte nicht in irgendeiner exotischen Spezialsoftware, sondern in der weit verbreiteten Java-Bibliothek Log4j.
Für Unternehmen, die nicht wussten, in welchen Anwendungen Log4j eingesetzt wurde, begann die Arbeit deshalb noch vor dem Patchen: Zunächst musste überhaupt herausgefunden werden, wo die betroffene Bibliothek vorhanden war.
Bei über Jahre gewachsenen Anwendungslandschaften kann schon diese Bestandsaufnahme zur Herausforderung werden.
Eine Firewall modernisiert keine Anwendung
Natürlich lassen sich Legacy-Anwendungen zusätzlich absichern.
Wenn eine kurzfristige Modernisierung nicht möglich oder wirtschaftlich nicht sinnvoll ist, ist das sogar dringend zu empfehlen.
Mögliche Maßnahmen sind beispielsweise:
- Netzwerksegmentierung,
- Einschränkung erreichbarer Ports und Systeme,
- Trennung vom öffentlichen Internet,
- Zugriff über definierte Jump Hosts oder Gateways,
- starke Authentifizierung an vorgelagerten Komponenten,
- Web Application Firewalls,
- Endpoint Detection and Response,
- zentrales Logging und Monitoring,
- regelmäßige Schwachstellenscans,
- getestete Backup- und Recovery-Prozesse.
Damit lässt sich die Angriffsfläche teilweise erheblich reduzieren.
Das technische Grundproblem verschwindet dadurch allerdings nicht.
Eine Bibliothek ohne Sicherheitsupdates bleibt eine Bibliothek ohne Sicherheitsupdates. Eine Anwendung ohne ausreichende Tests bleibt schwer veränderbar. Eine schlecht dokumentierte Schnittstelle wird auch hinter einer Firewall nicht besser dokumentiert.
Deshalb lohnt sich eine klare Trennung:
Mitigation: Das bestehende Risiko wird reduziert.
Modernisierung: Die technische Ursache des Risikos wird beseitigt oder nachhaltig reduziert.
Beides kann zum richtigen Zeitpunkt die richtige Entscheidung sein. Es sind nur zwei unterschiedliche Dinge.
Auch der Weiterbetrieb kostet Geld
Dass Modernisierung Geld kostet, sieht jeder sofort.
Projektaufwand, externe Unterstützung, Infrastruktur, interne Ressourcen: Am Ende steht eine Zahl.
Beim Weiterbetrieb wird diese Rechnung deutlich seltener aufgemacht.
Dabei entstehen auch dort Kosten:
- steigender Wartungsaufwand,
- längere Fehleranalysen,
- manuelle Deployments,
- zusätzlicher Testaufwand,
- alte oder teure Lizenzmodelle,
- schwierige Personalbeschaffung für alte Technologien,
- Abhängigkeit von einzelnen Mitarbeitern,
- Einschränkungen bei neuen Schnittstellen und Funktionen,
- zusätzliche Sicherheitsmaßnahmen,
- längere Recovery-Zeiten.
Hinzu kommt die Frage nach den Folgekosten eines Ausfalls.
Was kostet es das Unternehmen, wenn die Anwendung vier Stunden ausfällt? Einen Tag? Eine Woche?
Bei einem wenig genutzten internen Tool kann die Antwort überschaubar sein. Bei einem Kundenportal, Produktionssystem oder einer zentralen Transaktionsplattform sieht die Rechnung schnell anders aus.
Die wirtschaftliche Betrachtung sollte deshalb nicht lauten:
Modernisierung kostet 250.000 Euro. Weiterbetrieb kostet nichts.
Sondern:
Was kostet uns der sichere Weiterbetrieb in den kommenden drei bis fünf Jahren? Welches Risiko tragen wir dabei? Und was würde eine Alternative kosten?
Erst dann lassen sich die Optionen vernünftig vergleichen.
Cloud-Migration ist noch keine Modernisierung
Ein alter Irrtum hält sich hartnäckig: Sobald eine Anwendung in der Cloud läuft, gilt sie als modernisiert.
Leider nein.
Eine virtuelle Maschine mit einer alten Anwendung bleibt eine virtuelle Maschine mit einer alten Anwendung. Auch dann, wenn sie jetzt in einem anderen Rechenzentrum steht.
Ein Lift & Shift kann trotzdem absolut sinnvoll sein. Etwa um ein eigenes Rechenzentrum abzulösen, Hardwareabhängigkeiten zu reduzieren oder zunächst eine einheitlichere Betriebsplattform zu schaffen.
Technische Schulden verschwinden dadurch aber nicht automatisch.
Wenn die Anwendung auf einem nicht mehr unterstützten Framework basiert, kaum dokumentiert ist und keine automatisierten Tests besitzt, bestehen diese Probleme nach der Migration weiterhin.
Eine Cloud-Migration kann deshalb Teil einer Modernisierung sein.
Sie ist aber nicht automatisch Modernisierung.
Muss jede alte Anwendung neu entwickelt werden?
Nein.
Ein kompletter Rewrite ist in vielen Fällen sogar die riskanteste Variante.
Große Legacy-Anwendungen enthalten Geschäftslogik, die über Jahre oder Jahrzehnte entstanden ist. Ein Teil davon ist dokumentiert. Ein anderer steckt ausschließlich im Code, in Sonderfällen oder im Wissen einzelner Fachbereiche.
Wer all das in einem einzigen Projekt neu bauen möchte, übernimmt entsprechend viel Risiko.
Grundsätzlich gibt es vier mögliche Wege.
1. Absichern
Die Anwendung bleibt zunächst bestehen.
Das kann sinnvoll sein, wenn das aktuelle Risiko durch technische und organisatorische Maßnahmen ausreichend reduziert werden kann und eine Modernisierung kurzfristig weder wirtschaftlich noch realistisch ist.
Aus einem Provisorium sollte allerdings kein Zustand ohne Ablaufdatum werden. Verantwortlichkeiten, Risiken und nächste Prüftermine gehören deshalb dazu.
2. Kapseln
Die Anwendung bleibt bestehen, wird aber stärker von ihrer Umgebung entkoppelt.
Zugriffe können beispielsweise über moderne APIs oder Gateways erfolgen. Einzelne Funktionen lassen sich schrittweise herauslösen. Direkte Abhängigkeiten zu anderen Systemen können reduziert werden.
Damit lässt sich die Lebensdauer eines bestehenden Systems verlängern und gleichzeitig eine spätere Modernisierung vorbereiten.
3. Modernisieren
Die Anwendung wird technisch weiterentwickelt.
Das kann unterschiedliche Dinge bedeuten: ein neues Framework, der Austausch einer Datenbank, Containerisierung, automatisierte Deployments, bessere Testbarkeit oder die schrittweise Ablösung einzelner Anwendungsteile.
Modernisierung muss kein Big Bang sein.
Bei vielen geschäftskritischen Systemen ist ein schrittweises Vorgehen sogar technisch und wirtschaftlich sinnvoller.
4. Abschalten
Diese Option wird erstaunlich selten zuerst geprüft.
Nicht jede Anwendung, die heute betrieben wird, wird tatsächlich noch gebraucht.
Manche Systeme unterstützen Prozesse, die inzwischen anders ablaufen. Funktionen sind mittlerweile in Standardsoftware verfügbar. Andere Anwendungen werden nur noch von wenigen Mitarbeitern verwendet.
Bevor ein Unternehmen viel Geld in die Modernisierung steckt, lohnt sich deshalb eine ziemlich einfache Frage:
Brauchen wir diese Anwendung in drei Jahren überhaupt noch?
Wenn die Antwort Nein lautet, braucht es vielleicht keinen Modernisierungsplan.
Sondern einen Ablöseplan.
Muss jede alte Anwendung neu entwickelt werden?
Nein.
Ein kompletter Rewrite ist in vielen Fällen sogar die riskanteste Variante.
Große Legacy-Anwendungen enthalten Geschäftslogik, die über Jahre oder Jahrzehnte entstanden ist. Ein Teil davon ist dokumentiert. Ein anderer steckt ausschließlich im Code, in Sonderfällen oder im Wissen einzelner Fachbereiche.
Wer all das in einem einzigen Projekt neu bauen möchte, übernimmt entsprechend viel Risiko.
Grundsätzlich gibt es vier mögliche Wege.
1. Absichern
Die Anwendung bleibt zunächst bestehen.
Das kann sinnvoll sein, wenn das aktuelle Risiko durch technische und organisatorische Maßnahmen ausreichend reduziert werden kann und eine Modernisierung kurzfristig weder wirtschaftlich noch realistisch ist.
Aus einem Provisorium sollte allerdings kein Zustand ohne Ablaufdatum werden. Verantwortlichkeiten, Risiken und nächste Prüftermine gehören deshalb dazu.
2. Kapseln
Die Anwendung bleibt bestehen, wird aber stärker von ihrer Umgebung entkoppelt.
Zugriffe können beispielsweise über moderne APIs oder Gateways erfolgen. Einzelne Funktionen lassen sich schrittweise herauslösen. Direkte Abhängigkeiten zu anderen Systemen können reduziert werden.
Damit lässt sich die Lebensdauer eines bestehenden Systems verlängern und gleichzeitig eine spätere Modernisierung vorbereiten.
3. Modernisieren
Die Anwendung wird technisch weiterentwickelt.
Das kann unterschiedliche Dinge bedeuten: ein neues Framework, der Austausch einer Datenbank, Containerisierung, automatisierte Deployments, bessere Testbarkeit oder die schrittweise Ablösung einzelner Anwendungsteile.
Modernisierung muss kein Big Bang sein.
Bei vielen geschäftskritischen Systemen ist ein schrittweises Vorgehen sogar technisch und wirtschaftlich sinnvoller.
4. Abschalten
Diese Option wird erstaunlich selten zuerst geprüft.
Nicht jede Anwendung, die heute betrieben wird, wird tatsächlich noch gebraucht.
Manche Systeme unterstützen Prozesse, die inzwischen anders ablaufen. Funktionen sind mittlerweile in Standardsoftware verfügbar. Andere Anwendungen werden nur noch von wenigen Mitarbeitern verwendet.
Bevor ein Unternehmen viel Geld in die Modernisierung steckt, lohnt sich deshalb eine ziemlich einfache Frage:
Brauchen wir diese Anwendung in drei Jahren überhaupt noch?
Wenn die Antwort Nein lautet, braucht es vielleicht keinen Modernisierungsplan.
Sondern einen Ablöseplan.
Welche Legacy-Anwendungen sollten zuerst modernisiert werden?
Eine Inventarliste allein hilft bei der Priorisierung kaum.
Zwei Faktoren sind wichtiger:
1. Wie kritisch ist die Anwendung für das Geschäft?
2. Wie hoch ist ihr technisches Risiko?
Daraus ergibt sich eine einfache Matrix:
| Technisches Risiko niedrig | Technisches Risiko hoch | |
|---|---|---|
| Geschäftskritikalität hoch | Beobachten & planen: Betrieb absichern, Lifecycle festlegen, Modernisierung vorbereiten | Priorität 1: Risiko kurzfristig reduzieren und Modernisierung konkret planen |
| Geschäftskritikalität niedrig | Weiterbetreiben oder abbauen: Wirtschaftlichkeit regelmäßig prüfen | Ablösung prüfen: Nicht unnötig Geld in ein wenig relevantes Risikosystem investieren |
Technisches Risiko bedeutet dabei nicht einfach „alt“. Relevant sind unter anderem Supportstatus, bekannte Schwachstellen, Patchbarkeit, Abhängigkeiten, Testbarkeit, Dokumentation, Recovery-Fähigkeit und vorhandenes Know-how.
Geschäftskritikalität ergibt sich aus den Folgen eines Ausfalls: betroffene Geschäftsprozesse, Kunden, Umsatz, Produktion, Daten, regulatorische Anforderungen und maximal tolerierbare Ausfallzeit.
Diese Matrix ersetzt kein Assessment.
Sie verhindert aber, dass Modernisierungsbudgets einfach nach dem Alter von Servern verteilt werden.
Der unterschätzte Legacy-Risikofaktor: Wissen
Bei Legacy-Systemen wird Dokumentation irgendwann zum Business-Continuity-Thema.
Wenn nur ein oder zwei Personen wissen,
- wie die Anwendung deployed wird,
- welche Schnittstellen kritisch sind,
- wie sie nach einem Ausfall wiederhergestellt wird,
- welche Konfigurationen besser nicht verändert werden oder
- welche manuellen Schritte für den Betrieb notwendig sind,
hat das Unternehmen eine operative Abhängigkeit.
Und zwar auch dann, wenn sämtliche Softwarekomponenten technisch noch unterstützt werden.
Die bessere Frage lautet deshalb nicht:
„Haben wir eine Dokumentation?“
Sondern:
„Könnte ein anderer qualifizierter Mitarbeiter das System mit dieser Dokumentation tatsächlich betreiben und wiederherstellen?“
Wenn die Antwort Nein lautet, ist das relevante Wissen noch nicht ausreichend dokumentiert.
Legacy-Systeme und Regulierung
Informationssicherheit ist längst kein isoliertes Thema der IT-Abteilung mehr.
Cybersecurity ist Teil des betrieblichen Risikomanagements. Anforderungen wie NIS2 und zusätzliche branchenspezifische Vorgaben erhöhen außerdem den Druck, technische Risiken nachvollziehbar zu erfassen und zu behandeln.
Das bedeutet nicht, dass jede alte Anwendung automatisch ein Compliance-Problem darstellt.
Unternehmen sollten aber erklären können:
- welches Risiko von einem System ausgeht,
- welche Maßnahmen dagegen getroffen wurden,
- wer das Risiko verantwortet,
- wie mit Schwachstellen umgegangen wird,
- wie die Wiederherstellung sichergestellt ist und
- ob beziehungsweise wann eine Modernisierung oder Ablösung geplant ist.
„Wir hatten bisher noch nie Probleme damit“ ersetzt keine Risikobewertung.
Der Legacy-Entscheidungsweg
Für eine erste Bewertung reichen sechs relativ einfache Fragen.
1. Brauchen wir die Anwendung weiterhin?
Nein: Ablösung oder Abschaltung planen.
Ja: Weiter zu Frage 2.
2. Werden Betriebssystem, Frameworks, Datenbank und kritische Abhängigkeiten noch unterstützt?
Nein: Technisches Risiko bewerten und kurzfristige Absicherung prüfen.
Ja: Weiter zu Frage 3.
3. Können kritische Sicherheitsupdates zeitnah und kontrolliert eingespielt werden?
Nein: Ursache klären. Fehlen Tests? Gibt es inkompatible Komponenten? Fehlt Wissen? Existieren schwer kontrollierbare Abhängigkeiten?
Ja: Weiter zu Frage 4.
4. Können wir die Anwendung nach einem Ausfall innerhalb der fachlich erforderlichen Zeit wiederherstellen?
Nein: Backup-, Recovery- und Betriebsprozesse verbessern und testen.
Ja: Weiter zu Frage 5.
5. Können mehrere Personen das System betreiben und verändern?
Nein: Dokumentation und Wissenstransfer priorisieren.
Ja: Kontrollierter Weiterbetrieb ist grundsätzlich möglich.
6. Passt die Anwendung zur IT-Strategie der kommenden drei bis fünf Jahre?
Nein: Modernisierung oder Ablösung planen.
Ja: Weiterbetrieb mit definiertem Lifecycle und regelmäßiger Neubewertung.
Diese Fragen ersetzen kein technisches Assessment.
Sie zeigen aber ziemlich schnell, wo genauer hingesehen werden sollte.
Wo sollte man bei der Legacy-Modernisierung anfangen?
Nicht mit Kubernetes.
Nicht mit der Auswahl eines Cloud-Anbieters.
Und auch nicht mit der Entscheidung für irgendeine neue Technologie.
Der erste Schritt ist eine vernünftige Bestandsaufnahme.
Für die wichtigsten Anwendungen sollten mindestens folgende Informationen vorhanden sein:
Geschäft: Was macht die Anwendung? Wer nutzt sie? Welche Prozesse hängen davon ab? Welche Ausfallzeit ist akzeptabel?
Technologie: Welche Betriebssysteme, Frameworks, Datenbanken und wichtigen Abhängigkeiten werden eingesetzt? Wie ist deren Supportstatus?
Security: Gibt es bekannte Schwachstellen? Wie schnell können kritische Patches eingespielt werden? Wie ist die Anwendung erreichbar und geschützt?
Betrieb: Wie funktionieren Deployment, Monitoring, Backup und Restore? Wann wurde ein Restore zuletzt wirklich getestet?
Wissen: Wer kann die Anwendung administrieren und verändern? Ist dieses Wissen dokumentiert?
Zukunft: Wird die Anwendung in drei bis fünf Jahren noch benötigt? Welche neuen Anforderungen sind bereits absehbar?
Danach lässt sich priorisieren.
Nicht jede alte Anwendung muss modernisiert werden.
Für jede geschäftskritische Anwendung sollte aber eine bewusste Entscheidung existieren:
Weiterbetreiben. Absichern. Kapseln. Modernisieren. Oder abschalten.
„Never change a running system“ ist kein Betriebsmodell
Es gibt gute Gründe, ein bestehendes System nicht sofort anzufassen.
Budgets sind begrenzt. Teams ebenfalls. Andere Projekte haben Abhängigkeiten. Und gerade bei geschäftskritischen Anwendungen bringt auch die Modernisierung selbst ein Risiko mit.
Das Ziel kann deshalb nicht sein, möglichst viele alte Anwendungen möglichst schnell auszutauschen.
Entscheidend ist, zu wissen, wo das Unternehmen ein technisches oder betriebliches Risiko trägt – und warum es dieses Risiko akzeptiert.
Problematisch wird es dort, wo Sicherheitsupdates nicht mehr zuverlässig eingespielt werden können, zentrale Komponenten aus dem Support laufen, das Wissen über die Anwendung verschwindet und trotzdem kein Plan existiert.
Dann ist „Never change a running system“ keine besonders vorsichtige IT-Strategie mehr.
Dann wird Arbeit nur verschoben.
Und irgendwann entscheidet nicht mehr das Unternehmen, wann sich das System verändern muss.
FAQ: Legacy-Anwendungen und Modernisierung
Was ist eine Legacy-Anwendung?
Eine Legacy-Anwendung ist ein bestehendes Softwaresystem, dessen sicherer Betrieb, Wartung oder Weiterentwicklung zunehmend schwierig wird. Entscheidend ist nicht das Alter der Software, sondern beispielsweise fehlender Herstellersupport, veraltete Abhängigkeiten, schlechte Testbarkeit, mangelnde Dokumentation oder fehlendes Know-how.
Wann wird eine Legacy-Anwendung zum Sicherheitsrisiko?
Kritisch wird eine Legacy-Anwendung insbesondere dann, wenn bekannte Schwachstellen nicht mehr zeitnah behoben werden können, verwendete Komponenten keinen Support mehr erhalten oder Abhängigkeiten nicht bekannt sind. Das Risiko steigt zusätzlich, wenn Änderungen wegen fehlender Tests oder Dokumentation kaum kontrollierbar sind.
Müssen Legacy-Systeme immer modernisiert werden?
Nein. Je nach Geschäftskritikalität und technischem Risiko kann ein System weiterbetrieben, zusätzlich abgesichert, gekapselt, schrittweise modernisiert oder vollständig abgelöst werden. Entscheidend ist, dass die Entscheidung bewusst getroffen und regelmäßig überprüft wird.
Ist eine Cloud-Migration bereits eine Legacy-Modernisierung?
Nicht automatisch. Ein Lift & Shift verändert zunächst nur den Betriebsort einer Anwendung. Veraltete Frameworks, technische Schulden, fehlende Tests und schlecht dokumentierte Abhängigkeiten bleiben dabei bestehen. Eine Cloud-Migration kann Teil einer Modernisierungsstrategie sein, ersetzt sie aber nicht.
Welche Legacy-Anwendungen sollten zuerst modernisiert werden?
Priorität sollten Anwendungen haben, die sowohl eine hohe Geschäftskritikalität als auch ein hohes technisches Risiko besitzen. Dazu zählen beispielsweise Systeme, bei denen Ausfälle erhebliche Auswirkungen hätten und gleichzeitig Patches, Recovery oder Änderungen nur schwer kontrollierbar sind.
Was ist der erste Schritt bei einer Legacy-Modernisierung?
Der erste Schritt ist ein strukturiertes Assessment der Anwendung und ihrer Abhängigkeiten. Dabei sollten Geschäftskritikalität, Technologie, Security, Betrieb, Recovery, vorhandenes Know-how und die zukünftige strategische Bedeutung bewertet werden. Erst danach sollte über konkrete Technologien oder Zielplattformen entschieden werden.
Kann man Legacy-Anwendungen sicher weiterbetreiben?
Ja, in vielen Fällen ist ein kontrollierter Weiterbetrieb möglich. Voraussetzung sind unter anderem ein bekannter Supportstatus, funktionierendes Patchmanagement, geeignete Sicherheitsmaßnahmen, getestete Backup- und Recovery-Prozesse, ausreichende Dokumentation und klare Verantwortlichkeiten. Sind diese Voraussetzungen nicht gegeben, sollte das Risiko gezielt reduziert oder eine Modernisierung beziehungsweise Ablösung geplant werden.
Wie hoch ist das Risiko Ihrer Legacy-Landschaft?
Viele Unternehmen wissen ziemlich genau, welche Anwendungen alt sind. Schwieriger ist die Frage, welche davon tatsächlich zuerst angegangen werden sollten. Genau dort setzen wir bei Interlake an. In einem strukturierten Legacy- und Cloud-Readiness-Assessment betrachten wir nicht nur die technische Architektur. Wir bewerten Geschäftskritikalität, Security, Betrieb, Abhängigkeiten, Modernisierbarkeit und die Frage, welche Zielplattform überhaupt sinnvoll ist. Das Ergebnis ist keine pauschale Empfehlung, alles neu zu bauen oder möglichst schnell in die Cloud zu verschieben.
Sondern eine priorisierte Entscheidungsgrundlage:
Was kann bleiben? Was muss kurzfristig abgesichert werden? Was sollte modernisiert werden? Und womit sollte man anfangen?
