Software End of Life (EOL)
Was bedeutet End of Life bei Software?
End of Life (EOL) bezeichnet den Zeitpunkt, ab dem ein Softwareprodukt nicht mehr aktiv vom Hersteller unterstützt wird. Das betrifft Betriebssysteme, Frameworks, Programmiersprachen, Libraries und fertige Anwendungen gleichermaßen. Nach dem EOL-Datum gibt es in der Regel:
- keine Sicherheitsupdates mehr
- keine Fehlerbehebungen
- keinen technischen Support
- keine Garantie für Kompatibilität mit neuer Hardware oder Software
Für Standardsoftware wie Windows oder Office ist das EOL-Datum meist Jahre im Voraus bekannt. Bei Open-Source-Frameworks und Libraries — also der Grundlage der meisten Individualsoftware — sind die Zyklen kürzer und die Kommunikation weniger prominent.
EOL vs. EOS: Wo liegt der Unterschied?
Die Begriffe End of Life und End of Support (EOS) werden häufig verwechselt, meinen aber Verschiedenes.
End of Support (EOS) tritt ein, wenn der Hersteller den aktiven Support einstellt — keine Hotline, keine Ticketbearbeitung, keine neuen Features. Sicherheitsupdates werden häufig noch für eine Übergangszeit weiter geliefert.
End of Life (EOL) geht einen Schritt weiter: Auch Sicherheitsupdates werden eingestellt. Die Software wird vom Hersteller nicht mehr gepflegt. Ab diesem Punkt ist der Betreiber vollständig auf sich gestellt — oder auf einen spezialisierten Dienstleister angewiesen.
Ein Beispiel: PHP 8.1 erreichte im November 2024 das End of Active Support (EOS). Sicherheitspatches werden noch bis Dezember 2025 geliefert. Danach ist End of Life erreicht — jede Sicherheitslücke bleibt offen, sofern kein externer Maintainer einspringt.
Welche Risiken entstehen durch EOL-Software?
Sicherheitslücken ohne Patches
Das gravierendste Risiko: Bekannte Schwachstellen werden nicht mehr geschlossen. Angreifer wissen, dass EOL-Software ungepatcht bleibt, und nutzen das gezielt aus. Die WannaCry-Attacke von 2017 traf vor allem Systeme mit veraltetem Windows XP — einem Betriebssystem, das zu diesem Zeitpunkt seit drei Jahren EOL war.
Compliance-Verstöße
Die DSGVO verpflichtet Unternehmen, „geeignete technische und organisatorische Maßnahmen” zum Schutz personenbezogener Daten zu treffen. Der Betrieb von EOL-Software, für die keine Sicherheitsupdates mehr verfügbar sind, ist mit dieser Pflicht kaum vereinbar. Ähnlich sieht es bei branchenspezifischen Regularien aus: NIS-2, BSI-Grundschutz oder PCI-DSS setzen aktuelle, gepflegte Systeme voraus.
Kompatibilitätsprobleme
EOL-Software wird nicht an neue Betriebssysteme, Browser, Datenbanken oder Schnittstellen angepasst. Mit der Zeit entstehen Inkompatibilitäten, die den Betrieb beeinträchtigen oder unmöglich machen. Eine Web-Applikation auf einem veralteten Framework rendert möglicherweise in aktuellen Browsern nicht mehr korrekt. Eine API-Schnittstelle funktioniert nicht mehr mit der neuesten Version des Gegenübers.
Steigende Wartungskosten
Paradoxerweise wird EOL-Software nicht billiger, sondern teurer. Entwickler mit Know-how für veraltete Technologien werden seltener und teurer. Workarounds für fehlende Patches kosten Zeit. Und wenn schließlich doch migriert werden muss, ist der Aufwand umso höher, je länger gewartet wurde.
EOL bei Frameworks und Libraries: Das unterschätzte Risiko
Bei Standardsoftware wie Windows oder SAP sind EOL-Daten prominent kommuniziert. Bei den Bausteinen von Individualsoftware — Frameworks, Libraries, Laufzeitumgebungen — ist das Bewusstsein geringer, die Konsequenzen aber genauso ernst.
Laravel: Neue Hauptversionen erscheinen jährlich. Jede Version erhält zwei Jahre Bugfixes und drei Jahre Sicherheitsupdates. Laravel 9 (veröffentlicht 2022) hat im Februar 2024 den Sicherheitssupport verloren. Wer noch auf Laravel 9 läuft, betreibt EOL-Software.
Node.js: Gerade Versionen erhalten 30 Monate Support. Node 18 LTS wird bis April 2025 unterstützt, danach nur noch als End-of-Life geführt.
Python: Python 3.8 hat im Oktober 2024 das EOL erreicht. Wer Anwendungen auf Python 3.8 betreibt, erhält keine Sicherheitspatches mehr.
Diese Zyklen sind kürzer, als viele Unternehmen erwarten. Ein professioneller Wartungsvertrag enthält deshalb ein Abhängigkeitsmanagement, das EOL-Daten überwacht und Migrationen rechtzeitig plant.
Was tun, wenn Software das EOL erreicht?
Option 1: Migrieren
Die naheliegendste Lösung: Die Software auf eine aktuelle, unterstützte Version der zugrunde liegenden Technologie migrieren. Bei einem Framework-Update (z. B. Laravel 9 → 11) bedeutet das in der Regel die Anpassung von Konfigurationen, die Aktualisierung veralteter API-Aufrufe und die Migration von Abhängigkeiten. Der Aufwand hängt davon ab, wie eng die Anwendung an spezifische Framework-Features gebunden ist.
Option 2: Modernisieren
Wenn die Migration nicht ausreicht — etwa weil die gesamte Architektur veraltet ist —, kommt eine umfassendere Software-Modernisierung in Betracht. Das kann ein Refactoring der Codebasis sein, eine Umstellung von Monolith auf Microservices oder eine teilweise Neuentwicklung kritischer Komponenten.
Option 3: Extended Maintenance
In manchen Fällen ist eine sofortige Migration nicht möglich — sei es aus Budgetgründen, wegen laufender Geschäftsprozesse oder wegen regulatorischer Abhängigkeiten. Dann kann ein spezialisierter Dienstleister die Wartung der EOL-Software übernehmen: Sicherheitspatches manuell erstellen, Workarounds für Kompatibilitätsprobleme entwickeln und die Software so lange am Leben halten, bis die Migration durchgeführt werden kann. Das ist teurer als die Wartung aktueller Software, aber günstiger als ein ungeplanter Ausfall.
