Jetzt upgraden oder für Extended Support zahlen? Optionen, wenn Ihre PHP-Version ausläuft

Wenn eine PHP-Version, auf die Sie sich verlassen, ihr Enddatum erreicht, haben Sie drei echte Möglichkeiten, nicht nur eine. Sie können die Anwendung auf eine unterstützte Version upgraden, einem Anbieter für PHP Extended Support auf der alten Version bezahlen, oder das System isolieren und begrenzen, was damit interagiert, während Sie den nächsten Schritt planen. Jede Option hat andere Kosten, ein anderes Risiko und einen anderen Zeitplan, und welche richtig ist, hängt von Ihrem konkreten System ab, nicht davon, welche Option in der Theorie am besten klingt.

Die meisten Unternehmen behandeln eine End-of-Life-Frist wie einen einzigen Schalter: upgraden oder nicht. In der Praxis gibt es einen echten Mittelweg, und diesen in beide Richtungen zu überspringen kostet meist mehr, als ihn ehrlich abzuwägen.

Was tatsächlich passiert, wenn die Uhr abläuft

Der PHP-Support folgt einem festen Zeitplan. Eine Version erhält rund zwei Jahre aktive Entwicklung, in denen sowohl Bugs als auch Sicherheitslücken behoben werden, dann etwa zwei weitere Jahre nur noch Sicherheitsfixes, dann nichts mehr. Sobald eine Version über dieses zweite Fenster hinaus ist, kommt kein neuer Patch mehr, egal wie schwerwiegend sich eine Schwachstelle später herausstellt. Ihr Hosting-Anbieter kann das nicht für Sie beheben. Niemand kann das, weil es den Fix schlicht nicht gibt.

Das heißt nicht, dass die Anwendung an dem Tag aufhört zu funktionieren, an dem die Frist verstreicht. Der Server läuft weiter. Die Seite lädt weiter. Was sich ändert, ist die Richtung des Risikos. Je länger ein System auf einer unsupporteten Version läuft, desto mehr bekannte, veröffentlichte Schwachstellen häufen sich dagegen an, und desto leichter findet ein automatisierter Scan eine davon. Eine Versicherung, ein Prüfer oder ein Enterprise-Kunde, der fragt, welche PHP-Version Sie einsetzen, und eine Antwort wie "8.1, unsupportet seit Ende 2025" bekommt, behandelt diese Antwort eher als Warnsignal denn als Formsache.

Option eins: die Anwendung jetzt upgraden

Upgraden bedeutet, die Anwendung auf eine aktuell unterstützte PHP-Version zu bringen, was meist Framework- und Bibliotheks-Updates mit sich zieht, da alte Abhängigkeitsversionen auf neuem PHP oft gar nicht laufen. Das ist die einzige Option, die das eigentliche Problem beseitigt, statt es nur zu verwalten.

Die Kosten bestehen hier größtenteils aus Entwicklerzeit statt aus Lizenzgebühren, und sie skalieren mit der Menge an veralteten Code, die sich angesammelt hat. Eine saubere, gut getestete Symfony- oder Laravel-Anwendung, die in den letzten Jahren entstanden ist, kann zwei Major-Versionen in wenigen Wochen überspringen. Eine Anwendung mit einem Jahrzehnt unberührtem Code, ohne Testabdeckung und mit kundenspezifischen Erweiterungen, an die sich niemand mehr erinnert, kann Monate dauern, und die Schätzung wächst meist, sobald die Arbeit beginnt, denn genau dann tauchen die undokumentierten Teile auf.

Werkzeuge wie Rector können einen erheblichen Teil der mechanischen Änderungen automatisieren, etwa umbenannte Funktionen und geänderte Signaturen, was Zeitplan und Risiko bei größeren Codebasen senkt. Das ersetzt nicht das Testen und die Einschätzung, die ein Mensch weiterhin anwenden muss, besonders bei allem, was Geld, Authentifizierung oder gespeicherte Daten betrifft.

Upgraden ist die richtige Standardwahl, wenn die Anwendung noch eine Zukunft hat: wenn sie aktiv genutzt wird, das Unternehmen weiter in sie investieren will und die Codebasis nicht so verworren ist, dass ein Neuanfang tatsächlich schneller wäre.

Option zwei: für PHP Extended Support zahlen

Mehrere Anbieter, darunter einige, die eng mit dem PHP-Projekt selbst verbunden sind, verkaufen Extended-Support-Verträge, die weiterhin Sicherheitspatches für Versionen nach ihrem offiziellen Enddatum liefern. Das verschafft Zeit, ohne die Anwendung überhaupt anzufassen.

Der Reiz liegt auf der Hand. Es gibt keine Entwicklungsarbeit, kein Risiko, mitten im Upgrade etwas zu zerstören, und planbare jährliche Kosten statt eines offenen Projekts. Der Nachteil ist, dass Sie jedes Jahr für eine Version zahlen, die keine der Performance-Verbesserungen oder Sprachfeatures einer aktuellen Version bietet, und die Zahlungen bauen auf nichts auf. Extended Support schließt außerdem typischerweise das Framework und den Rest des Stacks aus. Zu zahlen, um PHP selbst gepatcht zu halten, nützt einem unsupporteten Symfony-LTS-Branch oder einer verlassenen Bibliothek eine Ebene darüber gar nichts.

Extended-Support-Verträge ergeben am meisten Sinn als Brücke, nicht als Ziel: eine Möglichkeit, sechs Monate oder ein Jahr Sicherheit zu kaufen, während ein echtes Upgrade geplant und budgetiert wird, nicht als unbegrenzter Ersatz dafür, das Upgrade überhaupt zu machen. Als dauerhafte Lösung behandelt, verzögert es nur dieselbe Entscheidung, während sich die Lücke zwischen Ihrer Version und der aktuellen immer weiter vergrößert.

Option drei: das System isolieren und warten

Über die dritte Option wird seltener gesprochen, aber sie ist häufig die richtige Wahl für ein System, das ohnehin auf dem Weg aus dem Betrieb ist. Wenn die Anwendung zum Ersatz vorgesehen ist, von immer weniger Nutzern verwendet wird oder hauptsächlich aus Trägheit am Leben gehalten wird, kann die klügste Entscheidung sein, sie zu isolieren. Nehmen Sie sie, wo möglich, vom öffentlichen Internet, sperren Sie den Netzwerkzugriff auf das Nötigste, entfernen Sie nicht essenzielle Integrationen und bauen Sie komplett keine neuen Funktionen mehr. Ein unsupportetes System, das niemand erreichen kann, ist ein deutlich kleineres Risiko als dasselbe System auf einem öffentlichen Endpunkt.

Das funktioniert nur als festgelegter, bewusster Plan mit Zeitplan, nicht als Standardergebnis dessen, dass niemand etwas entschieden hat. "Wir haben das isoliert und planen die Abschaltung innerhalb des Jahres" ist eine vertretbare Antwort gegenüber einem Prüfer oder einer Versicherung. "Wir sind nie dazu gekommen, es zu beheben" ist es nicht, selbst wenn der technische Zustand von außen identisch aussieht. Der Unterschied ist, ob jemand die Entscheidung getroffen und festgehalten hat, oder ob die Frist einfach stillschweigend verstrichen ist, während niemand etwas entschieden hat.

Wie Sie tatsächlich entscheiden

Die drei Optionen schließen sich nicht gegenseitig aus, und die richtige Kombination hängt von drei Fragen ab: Wie lange muss dieses System noch existieren, wie teuer ist es, es anzufassen, und was passiert, wenn es kompromittiert wird, während Sie das klären?

Ein System, das zentral für den Umsatz ist, mit aktiver Weiterentwicklung vor sich und einer Codebasis, die keine Katastrophe ist, spricht meist für ein sofortiges Upgrade und dafür, jede Support-Lücke als kurze Brücke statt als Plan zu behandeln. Ein System, das gut funktioniert, einen geringen Schadensradius hat, falls etwas schiefgeht, und nirgendwo hingeht, kann oft einen Extended-Support-Vertrag rechtfertigen, während das Upgrade nach einem realistischen statt überhasteten Zeitplan geplant wird. Ein System auf dem Weg zur Abschaltung, mit wenigen Nutzern und wenig neuer Entwicklung, ist meist besser mit Isolation bedient als mit einer der beiden anderen Optionen, da laufende Support-Gebühren oder Upgrade-Aufwand in etwas zu stecken, das Sie ohnehin abschalten wollen, sich selten rechnet.

Was selten Sinn ergibt, ist, nichts zu tun und zu hoffen, dass die Frist verrutscht. PHP-End-of-Life-Daten verschieben sich nicht, und das unsupportete Fenster wird nur breiter, je länger es unangetastet bleibt.

Wenn Sie nicht sicher sind, in welche Kategorie Ihr System fällt, ist diese Einschätzung meist das Erste, wofür sich externe Hilfe lohnt. Ein kurzes Legacy-Code-Audit kann vor jeder Festlegung auf einen Zeitplan oder Support-Vertrag zeigen, wie viel echte Arbeit ein Upgrade bedeutet, und ein breiterer Tech-Stack-Strategie-Review kann klären, ob sich das System überhaupt für ein Upgrade lohnt oder eher für die Abschaltung geplant werden sollte.

Wolf-Tech begleitet Kunden regelmäßig durch genau diese Art von Entscheidung, einschließlich des Audit-Schritts, der zeigt, welcher dieser drei Wege tatsächlich zu Ihrer Situation passt. Wenn Sie eine zweite Meinung zu einer PHP-Version möchten, der die Zeit ausgeht, melden Sie sich unter hello@wolf-tech.io oder besuchen Sie wolf-tech.io.