End of Life Software: Eine jährliche Checkliste für Ihren Tech-Stack

Die meisten Unternehmen erfahren auf dieselbe Weise, dass ein Teil ihres Tech-Stacks das End of Life erreicht hat, wie sie erfahren, dass ihre Kfz-Versicherung abgelaufen ist: nachdem etwas schiefgegangen ist. Eine End-of-Life-Software-Checkliste, die einmal im Jahr an einem Termin durchgeführt wird, den Sie sich auch tatsächlich merken, macht daraus ein Nicht-Ereignis. Sie erfahren Monate im Voraus, dass eine Version aus dem Support herausfällt, während noch Zeit bleibt, das Upgrade nach Ihrem eigenen Zeitplan zu planen und nicht nach dem eines anderen.

Dieser Beitrag richtet sich an Inhaber oder Geschäftsführer, die nicht selbst Code schreiben, aber dafür verantwortlich sind, dass das System sicher und online bleibt. Die folgende Prüfung erfordert kein Lesen von Code. Sie erfordert eine kurze Liste, sechs oder sieben Versionsnummern und einen Abgleich mit öffentlichen Support-Daten. Die meisten Unternehmen schaffen das Ganze in unter einer Stunde, sobald sie wissen, wo sie nachsehen müssen.

Warum das eine jährliche Gewohnheit sein muss, keine einmalige Korrektur

Jeder Teil der Software in einer modernen Webanwendung, die Programmiersprache, das darauf aufbauende Framework, die Datenbank, das Server-Betriebssystem, die Runtime für Hintergrundjobs und die Drittanbieter-APIs, mit denen sie kommuniziert, hat ihre eigene Support-Uhr. Jede läuft nach einem anderen Zeitplan, festgelegt von einer anderen Organisation, und keine davon schickt Ihnen eine persönliche Erinnerung, wenn die Uhr abläuft.

Ein System, das 2023 gebaut wurde, lief damals vollständig auf supportetem Software. Bis 2026 können, ohne dass eine einzige Zeile Code geändert wurde, mehrere dieser Komponenten still und leise in den nicht unterstützten Bereich gerutscht sein. An dem Tag, an dem der Support endet, bricht nichts zusammen. Die Anwendung läuft genau wie zuvor weiter. Was sich ändert: Jede ab diesem Datum entdeckte Sicherheitslücke in dieser Version wird von niemandem mehr gepatcht, solange Sie diese Version weiter betreiben. Diese Lücke wächst mit jedem Monat, in dem Sie nicht hinschauen, und genau deshalb reicht eine einmalige Prüfung beim Launch nicht aus. Sie müssen jedes Jahr erneut hinsehen.

Was Ihre End-of-Life-Software-Checkliste abdecken sollte

Gehen Sie diese Punkte für Ihr Hauptproduktivsystem durch. Für jeden Punkt brauchen Sie eine aktuelle Versionsnummer und das Datum, an dem diese Version keine Sicherheitsfixes mehr erhält.

Komponente	Wo Sie nachsehen	Was oft übersehen wird
Programmiersprache (PHP, Node.js, Python, Ruby usw.)	Ihr Entwickler, Ihr Hosting-Panel oder Ihr Serveradministrator kann das in Minuten mitteilen	Security-only-Support-Fenster, die Jahre vor dem enden, was die meisten erwarten
Web-Framework (Symfony, Laravel, Django, Rails, Next.js usw.)	Die eigene Release- und Support-Seite des Frameworks	Der Framework-Support endet oft früher als die Sprache, auf der es läuft
Datenbank (MySQL, PostgreSQL, MongoDB usw.)	Datenbank-Dashboard des Hosting-Anbieters oder ein von Ihrem Entwickler ausgeführtes SELECT version()	Managed Hosting aktualisiert Minor-Versionen manchmal automatisch, Major-Versionen aber nicht
Server-Betriebssystem	Hosting-Anbieter oder Server-Admin-Panel	Ubuntu LTS, Windows Server und Ähnliches haben alle feste, veröffentlichte Enddaten
Runtime für Hintergrundjobs (Node.js-Worker, Python-Worker, Cron-basierte Jobs)	Derselbe Ort wie Ihre Hauptsprache, aber separat prüfen, da Worker manchmal eine ältere, fest eingestellte Version nutzen	Eine Runtime, die still auf einer alten, fest eingestellten Version verbleibt, während die Hauptanwendung aktualisiert wurde
Drittanbieter-APIs, von denen Sie abhängen (Zahlungsdienstleister, Versand, Auth-Anbieter)	Die Entwicklerdokumentation oder der Changelog des Anbieters	API-Versions-Sunset-Daten, die mit deutlich weniger Vorlauf eintreffen als End of Life bei Sprache oder Framework

Sechs Kategorien, sechs Nachschläge. Keine davon erfordert, Ihre tatsächliche Codebasis anzufassen. Wenn Sie einen Entwickler oder eine Agentur unter Vertrag haben, ist diese Liste auch ein fairer, konkreter Fragenkatalog, den Sie ihnen schicken können: "Auf welcher Version sind wir bei jedem dieser Punkte, und wann endet der Support dieser Version?"

Wo Sie die tatsächlichen Daten finden

Framework- und Sprach-Maintainer veröffentlichen ihre Support-Zeitpläne direkt, und diese Seiten sind die einzige Quelle, der man mehr vertrauen sollte als einer Vermutung oder einer Zusammenfassung aus zweiter Hand. endoflife.date verfolgt die Support-Fenster der meisten großen Sprachen, Frameworks, Datenbanken und Betriebssysteme an einem Ort und ist eine schnelle Möglichkeit, mehrere Komponenten gleichzeitig zu prüfen, bevor man sie gegen die Originalseite des Anbieters bestätigt. Wir haben eine konkrete, oft übersehene Frist ausführlich behandelt, das Ende des PHP-8.2-Supports, und einen weiteren Beitrag zu einem Framework-Support-Fenster, das weiter verlängert wurde, als die meisten Anleitungen noch berichten, was ein gutes Beispiel dafür ist, warum die jährliche Prüfung der Primärquelle statt der Verlass auf die Notizen vom letzten Jahr tatsächlich wichtig ist.

Sunset-Daten von Drittanbieter-APIs sind anders. Sie erscheinen meist in einem Entwickler-Changelog oder einer E-Mail an registrierte API-Nutzer, nicht in einem zentralen Tracker, daher braucht dieser Punkt eine eigene, kurze Prüfung bei jedem Anbieter, von dem Sie abhängen, zumindest bei allem, was Zahlungen verarbeitet, Authentifizierung übernimmt oder Kundendaten anfasst.

Die Version auf einer Seite erstellen

Sobald die sechs Nachschläge erledigt sind, bringen Sie sie auf eine einzige Seite: Komponente, aktuelle Version, End-of-Life-Datum und verbleibende Tage. Sortieren Sie nach verbleibenden Tagen, der nächste zuerst. Diese Sortierung ist der eigentliche Zweck. Sie macht aus sechs verstreuten Fakten eine eindeutige Antwort auf die Frage "Was müssen wir als Erstes angehen?"

Behalten Sie diese Seite von einem Jahr zum nächsten, statt jedes Mal neu anzufangen. Die Versionsnummern ändern sich, das Format muss es nicht, und ein System, das seine eigene Historie verfolgt, macht sichtbar, welche Komponenten sich immer weiter der Frist nähern, ohne je angegangen zu werden.

Was Sie mit Ihren Ergebnissen tun

Eine Komponente mit mehr als einem Jahr verbleibendem Support braucht nichts weiter als eine Notiz, im nächsten Jahr erneut zu prüfen. Etwas innerhalb von zwölf Monaten braucht einen Punkt auf der Planung des nächsten Quartals, auch wenn die eigentliche Upgrade-Arbeit erst später stattfindet. Alles, was sein End-of-Life-Datum bereits überschritten hat oder innerhalb der nächsten Monate liegt, braucht jetzt eine Entscheidung: das Upgrade einplanen oder bezahlten Extended Support als Brücke prüfen, während das Upgrade sauber geplant wird.

Diese letzte Option existiert aus gutem Grund. Manchmal ist der ehrliche Zeitplan für ein Upgrade länger als die verbleibende Zeit im Support-Fenster, und eine temporäre, bezahlte Brücke vom Anbieter oder einem spezialisierten Dienstleister ist eine vernünftige Möglichkeit, kein ungepatchtes System zu betreiben, während die eigentliche Lösung gebaut wird. Es ist aber eine Brücke, kein Ziel. Behandeln Sie es als Fristverlängerung, nicht als Lösung.

Wo das ins große Bild passt

Eine End-of-Life-Software-Checkliste ist eine Pflegegewohnheit, kein Strategiepapier, aber sie bringt tendenziell immer wieder dieselbe zugrunde liegende Frage ans Licht: Ist der Technologie-Stack dieses Systems eine vernünftige Wahl für die Richtung, in die sich das Unternehmen bewegt, oder häuft sich still und leise Versionsschulden an, die irgendwann eine größere, weniger kontrollierte Entscheidung erzwingen werden? Wenn Ihre jährliche Prüfung wiederholt mehrere Komponenten nahe oder über ihrem Support-Fenster findet, ist dieses Muster selbst ein Gespräch wert mit demjenigen, der Ihre Tech-Stack-Strategie verantwortet, unabhängig von den einzelnen Upgrades.

Für die Upgrades selbst kann, sobald Sie wissen, was angegangen werden muss, ein Legacy-System-Review bestätigen, wie ein sicherer Upgrade-Pfad für Ihre spezifische Anwendung tatsächlich aussieht, bevor Sie sich auf einen Zeitplan festlegen.

Legen Sie jetzt ein Datum fest, tragen Sie es in den Kalender ein und gehen Sie einmal im Jahr die sechs oben genannten Punkte durch. Wenn Sie möchten, dass jemand anderes diese Prüfung durchführt und Ihnen klar sagt, was angegangen werden muss und bis wann, melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io. Die Unternehmen, die nie von einer End-of-Life-Frist überrascht werden, sind praktisch ausnahmslos diejenigen, die hingeschaut haben, bevor sie mussten.