EOL-Management: Struktur statt Überraschungen beim Software- und Hardware-Ende
Der Anruf kommt immer ungelegen. Der Hoster stellt die alte PHP-Version ab. Der Hersteller beendet den Support für den Server. Die Datenbank bekommt keine Updates mehr. Und plötzlich muss eine Entscheidung her, die eigentlich zwei Jahre Vorlauf gebraucht hätte.
Genau davor schützt EOL-Management. EOL steht für End of Life, also das offizielle Support-Ende einer Software oder Hardware. EOL-Management bedeutet: Sie wissen für jedes System, wann dieser Tag kommt. Bevor er kommt. Nicht danach.
Dieser Artikel zeigt, wie Sie ein solches System aufbauen. Ohne teure Tools, ohne eigene IT-Abteilung. Mit vier Bausteinen, die zusammen funktionieren.
Warum Support-Enden Unternehmen kalt erwischen
Kein Hersteller ruft Sie an, wenn Ihr System sein Lebensende erreicht. Die Termine stehen in Release-Kalendern, Ankündigungen und Newslettern. Wer sie nicht aktiv verfolgt, verpasst sie.
Dazu kommt ein zweites Problem. Support-Enden betreffen selten nur ein System. Eine typische Webanwendung hat viele Ebenen: Programmiersprache, Framework, Datenbank, Betriebssystem, Server-Hardware. Jede Ebene hat eigene Fristen. Niemand fühlt sich für das Gesamtbild zuständig.
Das Ergebnis kennen wir aus vielen Erstgesprächen. Systeme laufen jahrelang ohne Updates weiter. Nicht aus Leichtsinn, sondern weil niemand wusste, dass Handlungsbedarf besteht. Was sich dabei an Risiko ansammelt, haben wir im Artikel über den EOL-Prozess im Unternehmen beschrieben.
Was passiert ohne EOL-Management?
Die Konsequenzen kommen schleichend, aber zuverlässig.
Sicherheitslücken bleiben offen
Nach dem Support-Ende gibt es keine Sicherheits-Updates mehr. Neu entdeckte Lücken bleiben offen. Angreifer scannen das Internet automatisiert nach genau solchen Systemen. Ein System nach dem End of Life ist ein dokumentiertes Ziel.
Entscheidungen unter Zeitdruck werden teuer
Wer erst beim Support-Ende reagiert, hat keine Wahl mehr. Migration unter Zeitdruck kostet mehr als geplante Migration. Dienstleister sind kurzfristig teurer. Fehler passieren häufiger. Aus einem planbaren Projekt wird ein Notfall.
Das Budget kennt die Kosten nicht
Ein Server-Austausch oder ein PHP-Upgrade kostet Geld. Steht der Posten nicht im Jahresbudget, fehlt er im entscheidenden Moment. Dann wird verschoben. Und das Risiko wächst weiter.
Die vier Bausteine eines praktischen EOL-Managements
Der Ansatz ist kein Software-Produkt. Er ist ein einfaches System aus vier Bausteinen.
Baustein 1: Das Inventar mit EOL-Daten
Der erste Schritt ist eine Liste. Welche Systeme betreiben Sie? Für jedes System notieren Sie: Name, Version, Zweck, Verantwortlicher und das EOL-Datum.
Eine Tabelle reicht dafür völlig aus. Wichtig ist die Vollständigkeit. Erfassen Sie alle Ebenen: Anwendungen, Programmiersprachen, Frameworks, Datenbanken, Betriebssysteme und Hardware.
Bei Hardware kommt eine Besonderheit dazu. Neben dem Support-Ende gibt es das Ende der Ersatzteilversorgung. Ein Server kann noch laufen, obwohl es keine Ersatzteile mehr gibt. Fällt dann ein Bauteil aus, steht das System still. Notieren Sie deshalb bei Hardware beide Termine.
Die EOL-Termine finden Sie beim Hersteller oder auf Seiten wie endoflife.date. Achten Sie auf die Unterschiede zwischen den Begriffen. End of Life, End of Support und End of Maintenance bedeuten nicht dasselbe. Die Details erklärt unser Artikel zu EOL, End of Support und End of Maintenance.
Baustein 2: Schwellenwerte und Erinnerungen
Eine Liste, die niemand anschaut, hilft nicht. Deshalb braucht jedes EOL-Datum Vorwarnstufen.
Bewährt haben sich drei Schwellenwerte. 24 Monate vorher: Thema auf die Agenda nehmen und Optionen prüfen. 12 Monate vorher: Entscheidung treffen und Budget einplanen. 6 Monate vorher: Projekt starten.
Technisch genügen Kalendereinträge oder Erinnerungen im Aufgaben-Tool. Entscheidend ist, dass die Erinnerung eine Person erreicht, die handeln kann.
Baustein 3: Budget-Integration
EOL-Termine gehören in die Jahresplanung. Wenn die Datenbank in 18 Monaten ihr Support-Ende erreicht, gehört die Migration ins nächste Budget. So verliert das Thema seinen Schrecken. Es wird ein normaler Posten, kein Notfall.
Wie Sie solche Posten realistisch ansetzen, zeigt unser Leitfaden zum Software-Wartungsbudget. Die Faustregel: Geplante Ablösung kostet einen Bruchteil einer erzwungenen.
Baustein 4: Klare Verantwortlichkeiten
Die häufigste Schwachstelle ist nicht die Technik, sondern die Zuständigkeit. Jedes System braucht einen Namen dahinter. Eine Person, die die Erinnerungen erhält und die Entscheidung vorbereitet.
In kleinen Unternehmen ist das oft die Geschäftsführung selbst. Das ist in Ordnung. Auch ein externer Dienstleister kann diese Rolle übernehmen. Wichtig ist nur: Die Rolle existiert und ist besetzt.
Ein Beispiel aus der Praxis
Wie das konkret aussieht, zeigt ein typischer Fall aus unserem Alltag. Ein Handelsunternehmen betreibt einen Webshop auf PHP 7.4, eine Warenwirtschaft auf einem Windows-Server von 2016 und eine MySQL-Datenbank in Version 5.7. Alle drei Komponenten haben ihr Support-Ende bereits hinter sich. Aufgefallen ist das erst, als der Hoster eine Abschaltung ankündigte.
Mit einem Inventar wäre das anders gelaufen. Die drei EOL-Termine hätten Jahre vorher auf der Liste gestanden. Die Migration wäre als geplantes Projekt ins Budget gewandert. Statt drei Baustellen gleichzeitig hätte es drei geordnete Projekte nacheinander gegeben.
Der Unterschied liegt nicht in der Technik. Er liegt in der Vorlaufzeit.
So starten Sie: die ersten 30 Tage
Sie brauchen kein Großprojekt. Ein realistischer Einstieg sieht so aus.
Woche 1: Liste anlegen. Alle Systeme sammeln, auch die vergessenen. Fragen Sie Kollegen, prüfen Sie Rechnungen von Hostern und Dienstleistern.
Woche 2: EOL-Daten recherchieren. Für jedes System das Support-Ende eintragen. Unbekannte Versionen markieren und klären.
Woche 3: Erinnerungen einrichten. Für jedes Datum die drei Vorwarnstufen in den Kalender eintragen.
Woche 4: Verantwortliche benennen und die kritischsten drei Systeme besprechen. Was zuerst? Was kann warten?
Danach kostet die Pflege wenige Stunden pro Quartal. Das System wächst mit. Wie sich daraus ein vollständiges Lifecycle-Management entwickelt, beschreibt unser Artikel zum systematischen IT-Lifecycle-Management.
Was tun mit Systemen, die schon über dem EOL sind?
Beim ersten Inventar taucht fast immer mindestens ein System auf, dessen Support längst beendet ist. Das ist kein Grund zur Panik, aber ein Grund zu handeln.
Bewerten Sie zuerst das Risiko. Ist das System aus dem Internet erreichbar? Verarbeitet es Kundendaten? Dann hat es Priorität. Ein internes Werkzeug ohne Netzzugang kann dagegen oft geordnet abgelöst werden.
Für die Zwischenzeit gibt es Schutzmaßnahmen: Härtung, Monitoring, eingeschränkte Zugriffe. Das ersetzt kein Upgrade. Es verschafft Zeit für einen geordneten Weg. Genau diese Absicherung übernehmen wir im Rahmen der laufenden Software-Wartung.
Fazit: Struktur schlägt Reaktion
EOL-Management ist keine Raketenwissenschaft. Es ist eine Liste, ein Kalender, ein Budget-Posten und eine zuständige Person. Dieser überschaubare Aufwand verhindert genau die Situationen, die richtig teuer werden: Notfall-Migrationen, offene Sicherheitslücken, Entscheidungen unter Druck.
Sie müssen das nicht alleine aufbauen. Wir erstellen mit Ihnen das Inventar, bewerten die Risiken und erstellen einen Plan mit klaren Prioritäten. Sprechen Sie uns an. Das Erstgespräch ist kostenlos.
