Was tun mit einer Website, die eine veraltete PHP-Version oder altes Node.js nutzt?

Die kurze Antwort lautet so: Eine Website, die eine veraltete PHP-Version oder altes Node.js nutzt, hat drei Wege: den Code an ein unterstütztes Release anzupassen, die Website neu aufzubauen oder sie vorübergehend auf einer Plattform zu halten, die für die alte Laufzeitumgebung weiterhin Sicherheitsupdates als Backport einbaut, und währenddessen den Wechsel in Ruhe zu planen. Einen vierten Weg – alles so zu lassen, weil die Website ja läuft – gibt es in Wahrheit nicht, denn die PHP-Zweige 8.1 und älter erhalten vom PHP-Projekt keine Sicherheitsupdates mehr, die Release-Zweige 18 und 20 von Node.js ebenfalls nicht, und der Oktober 2026 hat an beiden gezeigt, was das in der Praxis bedeutet.

Eine Website, auf der eine veraltete PHP-Version läuft, ist gewöhnlich weder die Ausnahme noch eine besondere Nachlässigkeit. Sie wurde vor fünf oder acht Jahren entwickelt, die Person, die sie gebaut hat, arbeitet längst woanders, und die Website hat all die Jahre ohne große Probleme ihren Dienst getan: Sie hat Anfragen entgegengenommen, Preise angezeigt und Rechnungen verschickt. Nach den Daten von W3Techs liefen im Oktober 2026 26,8 % der Websites, die PHP einsetzen, auf PHP 7 und weitere 7,7 % auf PHP 5, also mehr als ein Drittel von ihnen auf PHP, dessen Unterstützung vor mehreren Jahren zu Ende gegangen ist. Die Frage entsteht gewöhnlich erst dann, wenn der Hosting-Anbieter eine Warnung schickt oder eine Sicherheitslücke in die Nachrichten kommt.

Wann eine PHP- oder Node.js-Version alt wird

„Alt“ ist hier keine Geschmacksfrage, denn sowohl PHP als auch Node.js veröffentlichen einen Zeitplan, der angibt, bis zu welchem Datum jeder PHP-Zweig oder Release-Zweig Sicherheitsupdates erhält. PHP gibt jedem PHP-Zweig zwei Jahre aktive Unterstützung und weitere zwei Jahre, in denen nur Sicherheitsfixes für kritische Sicherheitsfehler erscheinen, und danach wird der PHP-Zweig in keiner Weise mehr unterstützt. Bei den Release-Zweigen von Node.js mit Long-Term-Support (Langzeitunterstützung) folgt am Ende die Phase Maintenance LTS, und wenn sie endet, erhält der Release-Zweig kein einziges Release mehr, auch dann nicht, wenn eine neue Sicherheitslücke genau ihn betrifft.

In der Tabelle stehen die PHP-Zweige und Release-Zweige, mit denen man heute am häufigsten zu tun hat, und ihr Stand im Oktober 2026. Die Daten stammen aus der Liste der PHP-End-of-Life-Daten und aus dem Release-Zeitplan von Node.js, und beide Quellen sind auch künftig zu prüfen, weil dort jedes Jahr neue Zeilen erscheinen.

Es lohnt sich, zwei Zeilen in dieser Tabelle noch einmal zu lesen. PHP 8.2 verliert die Unterstützung am 31. Dezember 2026, sodass eine Website, die im Herbst 2026 modern aussieht, im Januar 2027 in derselben Lage ist wie eine Website mit PHP 7.4, und den Wechsel lohnt es sich, jetzt zu planen, solange er sich ohne Zeitdruck machen lässt. Der Release-Zweig Node.js 20 war im Herbst 2024 noch im Active LTS, der aktiven Phase des Long-Term-Support, und auf ihm wurden viele neue Projekte begonnen, am 30. April 2026 hat er die Unterstützung aber verloren. Das Veralten geschieht nicht allmählich: An einem bestimmten Tag wechselt die Laufzeitumgebung von „erhält noch Korrekturen“ zu „erhält nichts“, und auf der Website ändert sich in diesem Moment nichts, was sich bemerken ließe.

Warum eine Website, die läuft, trotzdem gefährdet ist

Eine Version ohne Unterstützung wird nicht an dem Tag gefährlich, an dem die Unterstützung endet, sondern an dem Tag, an dem eine Sicherheitslücke veröffentlicht wird, die auch sie betrifft. Das Sicherheitsupdate für die unterstützten PHP-Zweige erscheint zusammen mit einer Beschreibung, und sobald es öffentlich ist, können Angreifer den korrigierten Code mit dem unkorrigierten vergleichen und erkennen, wo das Loch ist. Auf seiner Seite zum End of Life sagt Node.js das direkt: Wenn eine Sicherheitslücke auch einen Release-Zweig ohne Unterstützung betrifft, erscheint für ihn kein neues Release, und wer auf einem solchen Release-Zweig bleibt, ist sofort ungeschützt gegen Angriffe, die die veröffentlichte Sicherheitslücke ausnutzen.

Im Oktober 2026 ist genau das beiden Plattformen fast gleichzeitig geschehen. Am 21. Oktober hat PHP Notfall-Sicherheitsupdates für zwei kritische Sicherheitslücken veröffentlicht, die unter dem Namen PHP2Shell bekannt sind, und offizielle Releases erhielten nur die PHP-Zweige von 8.2 bis 8.5, während das Sicherheitsteam für die PHP-Zweige 7.4, 8.0 und 8.1 ausnahmsweise nur minimale Sicherheitsupdates im Quelltext vorbereitet hat, für alle, die PHP selbst bauen. Am selben Tag hat Node.js Sicherheitsupdates für zehn Sicherheitslücken veröffentlicht, und die Release-Zweige 18 und 20 haben vom Projekt selbst überhaupt keine erhalten. Beide Fälle haben wir gesondert beschrieben: im Artikel über PHP2Shell und im Artikel über das Node.js-Sicherheitsupdate.

Das zweite Risiko ist weniger sichtbar, langfristig aber größer. Eine alte Laufzeitumgebung lässt nichts von dem aktualisieren, was über ihr liegt: WordPress-Plugins, Composer- und npm-Pakete und das Framework selbst stellen in ihren neuen Releases die Unterstützung für altes PHP und altes Node.js nach und nach ein, deshalb kann die Website auch deren Sicherheitsupdates nicht erhalten. WordPress selbst empfiehlt PHP 8.3 oder höher und schreibt über ältere Versionen, dass sie offiziell das Ende ihres Lebenszyklus erreicht haben und die Website Sicherheitsrisiken aussetzen können. So ist die alte Laufzeitumgebung nicht mehr ein einzelnes Problem, sondern eine Schicht, die verhindert, alle übrigen zu lösen.

Wenn etwas geschieht, liegen die Kosten deutlich höher als bei einer geplanten Aktualisierung. Eine gehackte Website bedeutet Bereinigung, Wiederherstellung aus dem Backup, den Austausch von Passwörtern und Schlüsseln und, wenn personenbezogene Daten von Kunden betroffen waren, auch die Prüfung, ob der Aufsichtsbehörde eine Verletzung des Schutzes personenbezogener Daten zu melden ist, und all das geschieht unter Zeitdruck, während die Website nicht läuft oder den Besuchern fremde Inhalte zeigt. Der Wechsel ist in dieser Lage trotzdem zu machen, nur jetzt, nachdem die Website gehackt wurde, und nicht davor, und ohne die Möglichkeit, alles in Ruhe in einer Testumgebung zu prüfen.

Warum sich eine veraltete PHP-Version im Hosting-Panel nicht einfach umschalten lässt

Im Hosting-Panel dauert der Wechsel auf eine neuere PHP-Version einen Klick, und genau deshalb ist er tückisch: Ist der Code nicht darauf vorbereitet, funktioniert die Website in der nächsten Sekunde nicht mehr, oft mit einer leeren Seite oder einer Fehlermeldung. Beim Wechsel auf die nächste Hauptversion (Major-Version) nimmt PHP bewusst Funktionen heraus, die jahrelang als veraltet galten. PHP 7.0 hat die alte mysql-Erweiterung entfernt, auf der viele ältere Websites aufbauten, und PHP 8.0 hat in seiner Liste der inkompatiblen Änderungen unter anderem die Funktionen each() und create_function() entfernt, die in älterem Code noch immer vorkommen.

In der Node.js-Welt ist das klassische Beispiel der Release-Zweig 17, in dem die Laufzeitumgebung auf OpenSSL 3.0 gewechselt ist. In der Release-Meldung hat Node.js gewarnt, dass eine Anwendung, die selbst oder deren Module einen Algorithmus oder eine Schlüssellänge verwenden, die OpenSSL 3.0 standardmäßig nicht mehr erlaubt, den Fehler ERR_OSSL_EVP_UNSUPPORTED erhält, und als vorübergehende Abhilfe den Startparameter --openssl-legacy-provider angeboten. Den Fehler hat oft nicht der eigene Code des Projekts ausgelöst, sondern eine seiner Abhängigkeiten, und deshalb musste Code repariert werden, den das Projektteam selbst gar nicht geschrieben hatte.

Deshalb ist der Wechsel Entwicklungsarbeit und keine Einstellung. Der Code ist gegen die neue Laufzeitumgebung zu prüfen, die veralteten Funktionen sind zu ersetzen, die Abhängigkeiten sind auf Releases zu aktualisieren, die sie unterstützen, und alles ist in einer Testumgebung auszuprobieren, bevor es Kunden sehen. Für eine kleine Website auf einer unterstützten Plattform kann das einige Stunden Arbeit sein, für ein System, dessen Framework die Unterstützung vor mehreren Jahren verloren hat, bedeutet der Wechsel oft auch den Austausch des Frameworks, und dann ist es ein Projekt mit eigenem Budget und eigenem Zeitplan, keine Aufgabe, die sich zwischen anderen Arbeiten erledigen lässt.

Drei Wege: aktualisieren, neu aufbauen oder geschützt halten

Den Weg bestimmen zwei Dinge: wie weit der Code hinter einer unterstützten Version zurückliegt und wie lange die Website noch im Einsatz bleiben soll. Wenn die Website in einem Jahr ohnehin durch eine neue ersetzt werden soll, lohnt ein großer Wechsel im alten Code nicht, wenn sie aber das Werkzeug ist, mit dem das Unternehmen im Alltag arbeitet, und noch mindestens fünf Jahre genutzt wird, schiebt eine Übergangslösung das Unvermeidliche nur auf und macht es teurer. In der Tabelle stehen die drei Wege, die tatsächlich zur Verfügung stehen, und was jeder von ihnen löst und was nicht.

Die Aktualisierung ist die richtige Wahl, wenn die Website auf einer unterstützten Plattform steht, zum Beispiel WordPress oder Laravel, und sie von einem unterstützten PHP-Zweig ein oder zwei große Schritte trennen. Dann ist die Arbeit absehbar: Framework und Plugins sind zu aktualisieren, zu reparieren ist, was die Prüfwerkzeuge finden, und PHP ist umzuschalten. Der Neuaufbau ist der ehrlichste Weg, wenn das Framework selbst ohne Unterstützung ist, wenn die Website auf PHP 5.x ohne jedes Framework geschrieben ist oder wenn den Code niemand mehr versteht, denn dann nähern sich die Kosten der Aktualisierung schnell den Kosten einer neuen Website, das Ergebnis bleibt aber alter Code.

Der dritte Weg wird seltener besprochen. Eine alte Website lässt sich auf einer Plattform halten, die für ihre Laufzeitumgebung weiterhin Sicherheitsupdates als Backport einbaut, sie von anderen Websites isoliert und bekannte Angriffsmuster noch vor dem Sicherheitsupdate blockiert. Das ersetzt den Wechsel nicht, und Node.js selbst nennt eine solche Unterstützung eine Übergangslösung, es ist aber ein ehrlicher Weg, Zeit zu gewinnen: Der Wechsel lässt sich im geplanten Tempo machen und nicht in der Woche nach der nächsten Sicherheitsmeldung. Das wichtigste Wort ist hier „Frist“, denn ohne sie wird aus der Übergangslösung eine Dauerlösung.

Was ein Backport ist und warum die Versionsnummer dazu nichts sagt

Ein Backport bedeutet, dass ein Sicherheitsupdate, das für ein neueres Release entwickelt wurde, jemand anpasst und in ein älteres Release einbaut, das der Nutzer bereits verwendet. Red Hat, das die Pakete seiner Linux-Distributionen auf diese Weise pflegt, schreibt, dass der Kunde allein anhand der Versionsnummer nicht beurteilen kann, ob sein System verwundbar ist, weil der Backport das Paket verändert, die Versionsnummer aber nicht. Genau deshalb melden Scanner für Sicherheitslücken, die nur auf die Nummer schauen, auf solchen Systemen oft Probleme, die bereits behoben sind.

Bei PHP und Node.js tun das mehrere Anbieter. Linux-Distributionen bauen Backports für die gesamte Unterstützungsdauer der Distribution in ihre PHP- und Node.js-Pakete ein. CloudLinux baut Backports auch in seine alt-php-Pakete ein, die Hosting-Server mit CloudLinux verwenden, und zwar auch für PHP-Zweige, deren PHP-Unterstützung längst zu Ende ist: Im Fall PHP2Shell hat seine Statusseite am 21. Oktober angekündigt, dass korrigierte Pakete für alle alt-php-Zweige von 5.2 bis 8.5 vorbereitet werden, und im Lauf der folgenden Nacht waren sie verfügbar. Diese Pakete gehören jetzt zum erweiterten Support von TuxCare, in dessen Bedingungen als Ziel für Sicherheitslücken hoher und kritischer Schwere ein Sicherheitsupdate binnen 14 Tagen nach der Veröffentlichung genannt ist.

Für Node.js-Release-Zweige ohne Unterstützung bieten denselben Dienst kommerzielle Partner an, die Node.js selbst auf seiner Seite zum End of Life nennt: HeroDevs, NodeSource und TuxCare. Node.js fügt sofort hinzu, dass eine solche Unterstützung als Übergangslösung zu betrachten ist und das Ziel immer der Wechsel auf eine unterstützte Version sein muss. Beim Node.js-Release im Oktober 2026 hat CloudLinux Backports auch in seine Pakete der Release-Zweige 16, 18 und 20 eingebaut, die Hosting-Kunden im cPanel-Bereich Setup Node.js App auswählen.

Anhand der Versionsnummer lässt es sich nicht prüfen. Der Befehl php -v oder node -v zeigt nach einem Backport genau dasselbe wie davor, und CloudLinux schreibt das in seiner Node.js-Meldung offen: Bei Release-Zweigen ohne Unterstützung ändert sich die Nummer nach der Aktualisierung nicht. Es ändert sich die release number des Pakets, die nur der Administrator des Servers sieht, deshalb kann im Webhosting die Antwort nur der Hosting-Anbieter geben.

Genauso klar ist die Grenze zu benennen. Ein Backport schützt PHP oder Node.js selbst, nicht aber ein WordPress-Plugin, dessen Autor die Aktualisierung eingestellt hat, selbst geschriebenen Code mit einer SQL-Injection oder ein npm-Paket, dessen neueste Releases altes Node.js nicht mehr unterstützen. Außerdem bauen die Anbieter die Backports für jeden Release-Zweig getrennt ein, deshalb ist bei jedem einzelnen zu prüfen, ob er überhaupt auf der Liste steht, und TuxCare behält sich in seinen Bedingungen vor, anstelle eines Sicherheitsupdates eine risikomindernde Maßnahme anzubieten.

Wenn nicht die Laufzeitumgebung alt ist, sondern die Plattform selbst

Manchmal liegt das Problem nicht in der Laufzeitumgebung, sondern in der Plattform selbst, auf der die Website gebaut ist, und dann helfen PHP-Backports nur zum Teil. Das beste Beispiel ist Drupal 7: Seine Sicherheitsunterstützung endete am 5. Januar 2025, und seither veröffentlicht das Drupal-Projekt selbst dafür weder Sicherheitsupdates noch Kompatibilitätsupdates. Eine Website auf Drupal 7 kann auf einem vollständig korrigierten PHP laufen, ihr Kern, ihre Module und ihr Theme behalten aber alle Sicherheitslücken, die darin noch gefunden werden, weil sie niemand mehr unentgeltlich behebt.

Auch hier gibt es eine kostenpflichtige Übergangslösung: Die Drupal Association hat ein Programm für erweiterte Sicherheitsunterstützung eingerichtet, in dem geprüfte Anbieter kostenpflichtige Unterstützung anbieten, zum Beispiel HeroDevs und Tag1 Consulting. Das ist dasselbe Prinzip wie bei PHP-Backports, nur eine Schicht höher, und es hat dieselben Grenzen: Es schiebt den Wechsel auf, löst ihn aber nicht, und jedes Jahr auf der alten Plattform macht den Wechsel teurer, weil der Abstand zum aktuellen Release wächst und die Zahl der Entwickler schrumpft, die sich mit der alten Plattform noch auskennen.

Deshalb lohnt es sich, vor jeder Entscheidung alle Schichten zu prüfen und nicht nur PHP: die Laufzeitumgebung, die Plattform oder das Framework, die Plugins oder Module und den selbst geschriebenen Code. Wenn nur PHP veraltet ist, WordPress, Laravel oder eine andere Plattform aber unterstützt wird, ist der Wechsel gewöhnlich planbare Arbeit. Wenn die Plattform selbst alt ist, geht es nicht mehr um den PHP-Zweig, sondern darum, ob die Website auf das neue Release der Plattform umzieht oder neu gebaut wird, und genau hier haben Backports die Aufgabe, Zeit zu geben, diese Entscheidung ohne Zeitdruck zu treffen.

Wie wir altes PHP und altes Node.js auf unserem Server halten

Unser Managed Hosting ist ein Platz auf unserem eigenen Server, der auf CloudLinux läuft, und die PHP-Version wird für jede Website einzeln im Hosting-Panel gewählt. Derzeit ist dort PHP von 5.4 bis 8.4 verfügbar, für Node.js-Anwendungen sowohl die unterstützten Release-Zweige 22 und 24 als auch die alten Release-Zweige 16, 18 und 20. Das heißt, eine alte Website lässt sich mit demselben PHP oder Node.js zu uns umziehen, mit dem sie jetzt läuft, und zuerst stabilisieren, statt am Tag des Umzugs zugleich den Code zu ändern, und das ist der sicherste Weg, beim Umzug nichts zu beschädigen.

Wie das in der Praxis funktioniert, konnten wir im Oktober 2026 selbst messen. Die PHP2Shell-Sicherheitsupdates erschienen am Nachmittag des 21. Oktober, und auf unserem Server laufen alle alten PHP-Zweige von 5.4 bis 8.1 jetzt mit Paketen, die CloudLinux in der Nacht desselben Tages neu gebaut hat, weniger als 24 Stunden nach dem PHP-Release, und in die der Backport eingebaut ist. Die PHP-Zweige von 8.2 bis 8.4 sind auf die offiziellen korrigierten Releases 8.2.35, 8.3.36 und 8.4.27 übergegangen, und die Release-Zweige Node.js 16, 18 und 20 haben am 22. Oktober CloudLinux-Pakete mit Backports erhalten, obwohl das Node.js-Projekt selbst für sie keine Sicherheitsupdates veröffentlicht hat. Bei den alten PHP-Zweigen hat sich die Nummer nicht geändert, deshalb haben wir sie nicht an der Nummer geprüft, sondern daran, wann die ausführbaren Dateien neu gebaut wurden.

Das ist nicht alles, was die Plattform tut. CloudLinux legt jeden Hosting-Account in eine eigene isolierte Umgebung, die CageFS heißt, und darin sehen die Nutzer andere Nutzer des Servers nicht und nicht einmal deren Benutzernamen, was die Ausbreitung eines Hacks von einem Account auf andere erschwert. Die Web Application Firewall (WAF) von Imunify360 hat im Fall PHP2Shell am 21. Oktober begonnen, bekannte Angriffsmuster zu blockieren, mehrere Stunden bevor das korrigierte PHP veröffentlicht wurde. Keine dieser Schichten macht eine alte Website unverwundbar, zusammen engen sie aber die Zeit ein, in der eine bekannte Sicherheitslücke ausnutzbar ist, und begrenzen, wie weit die Folgen eines Hacks reichen können.

Deshalb empfehlen wir, den Umzug einer alten Website zu uns als Übergangslösung mit Frist zu verstehen und nicht als Ziel. Wir ziehen die Website mit derselben Laufzeitumgebung um, prüfen, dass alles so läuft wie zuvor, und vereinbaren danach mit Ihnen, bis zu welchem Datum und in welcher Reihenfolge sie auf eine unterstützte Version wechselt, damit die Übergangslösung nicht zur Dauerlösung wird. Unser Managed Hosting beginnt ab 45 € im Monat, und gepflegte Laufzeitumgebungen, account isolation und die Firewall sind ein Teil dessen, wofür Sie in dieser Summe zahlen. Wenn Sie eine Website mit einer alten PHP- oder Node.js-Version haben, schicken Sie uns ihre Adresse, und wir sagen, welcher der drei Wege zu ihr passt und womit Sie anfangen.

Wie Sie erfahren, welche PHP- oder Node.js-Version Ihre Website hat

Der schnellste Weg ist das Hosting-Panel. Im cPanel-Hosting mit CloudLinux zeigt der Bereich Select PHP Version die Version, die für den ganzen Account gewählt ist, MultiPHP Manager zeigt die Version für jede Domain einzeln, und wenn dort für eine Domain eine eigene Version eingetragen ist, gilt diese. Für Node.js-Anwendungen zeigt dasselbe der Bereich Setup Node.js App, in dem jede Anwendung eine eigene Zeile hat. Es lohnt sich, jede Website anzusehen und nicht nur die Hauptwebsite, denn in einem Account liegen oft mehrere Websites auf verschiedenen PHP-Zweigen, und eine vergessene Testkopie oder eine alte Kampagnenseite ist oft noch aus dem Internet erreichbar.

Auf einer WordPress-Website ist sie auch im Administrationsbereich zu sehen: unter Werkzeuge → Website-Zustand, im Reiter Info, im Bereich Server steht die PHP-Version, auf der die Website läuft. Wenn es kein Panel gibt, lässt sich eine Datei mit der Funktion phpinfo() anlegen und im Browser öffnen, danach ist die Datei aber unbedingt zu löschen, denn sie zeigt jedem Besucher die Konfiguration des Servers. Der Befehl php -v hilft hier weniger, als es scheint, denn er zeigt das PHP der Kommandozeile, Webanfragen bedient aber oft ein anderer PHP-Zweig, der im Hosting-Panel gewählt ist. In einem Node.js-Projekt nennt oft die Datei package.json im Feld engines oder die Datei .nvmrc den gewünschten Release-Zweig, das ist aber nur ein Wunsch, und welches Node.js die Anwendung tatsächlich ausführt, ist dort zu sehen, wo der Prozess gestartet wird.

Wenn es überhaupt keinen Zugang gibt, geht die Frage an den Hosting-Anbieter oder an die Person, die die Website pflegt. Die Formulierung, die den Schriftwechsel spart: „Welche PHP- oder Node.js-Version bedient unsere Website? Wenn sie das End of Life erreicht hat: Erhält sie Sicherheitsupdates als Backport, woher kommen sie, und wann wurde das Paket zuletzt aktualisiert? Bis zu welchem Datum empfehlen Sie den Wechsel?“ Die Antwort auf die letzte Frage sagt auch über den Anbieter selbst viel aus, denn wenn es kein Datum gibt, gibt es gewöhnlich auch keinen Plan.

Der Wechsel auf eine unterstützte Version: wie er ohne Überraschungen gelingt

Der Wechsel beginnt mit einer Bestandsaufnahme und nicht mit dem Umschalten. Festzuhalten ist, welcher PHP-Zweig und welche PHP-Erweiterungen die Website braucht, welche geplanten Aufgaben sie im Hintergrund antreiben, mit welchen externen Systemen sie spricht und welche ihrer Teile für das Geschäft kritisch sind, zum Beispiel das Bestellformular, die Zahlungen oder der Rechnungsversand. Die Zielversion lohnt es sich mit zeitlichem Puffer zu wählen: PHP 8.4 erhält Sicherheitsupdates bis zum 31. Dezember 2028, PHP 8.3 bis Ende 2027, ein Wechsel auf PHP 8.2, dessen Unterstützung schon Ende 2026 endet, würde aber sehr bald einen weiteren Wechsel bedeuten. Bei Node.js ist das Ziel in den meisten Fällen der Release-Zweig 24.

Der zweite Schritt ist die Prüfung des Codes, und bei PHP-Code lässt sie sich zum großen Teil automatisieren. PHPCompatibility ist ein Satz von PHP_CodeSniffer-Regeln, der prüft, ob der Code mit einer bestimmten PHP-Version kompatibel ist, und Rector kann einen Teil der nötigen Änderungen automatisch ausführen. Keines von beiden ersetzt die Prüfung durch einen Menschen, sie zeigen aber schnell, ob der Umfang in Stunden oder in Wochen zu messen ist, und genau das braucht es, um zwischen Aktualisierung und Neuaufbau zu entscheiden. Bei einer WordPress-Website sind zuerst die Plugins und das Theme zu aktualisieren und erst danach PHP umzuschalten.

Der dritte Schritt ist eine Testumgebung, also eine Kopie der Website mit dem neuen PHP oder Node.js, in der alle kritischen Abläufe ausprobiert werden: Formulare, Zahlungen, der Versand von E-Mails, Import und Export. Das Fehlerprotokoll ist in dieser Phase wichtiger als die Sichtprüfung, denn Warnungen über veraltete Funktionen erscheinen dort lange, bevor etwas stehen bleibt. Der vierte Schritt ist das Umschalten zu einer Zeit mit geringer Last und mit der Möglichkeit, zurückzugehen: Im Hosting mit Versionswahl ist der Rückweg genau der eine Klick, mit dem umgeschaltet wurde, deshalb ist das Risiko klein, sofern das Backup frisch ist und jemand in der ersten Woche das Fehlerprotokoll verfolgt.

Bei einer Node.js-Anwendung ist die Logik dieselbe, nur die Werkzeuge sind andere. Den Wechsel zwischen den großen Release-Zweigen lohnt es sich einzeln zu machen und nach jedem die Tests der Anwendung laufen zu lassen, und besondere Aufmerksamkeit brauchen Pakete mit kompiliertem Code, denn sie werden für einen bestimmten Node.js-Release-Zweig gebaut und sind nach dem Wechsel neu zu bauen. Zuerst sind die Abhängigkeiten zu aktualisieren, die den neuen Release-Zweig noch nicht unterstützen, und erst danach ist die Laufzeitumgebung selbst zu wechseln, sonst vermischen sich die Fehler von beiden Seiten und es ist schwer zu erkennen, welcher von ihnen was ausgelöst hat.