Eine PHP-Version erreicht irgendwann ihr End of Life (EOL) -- ab diesem Tag erscheinen keine Sicherheitsfixes mehr, auch nicht für kritische, aktiv ausgenutzte Lücken. Genau das ist Ende 2025 PHP 8.1 passiert (endoflife.date). Trotzdem laufen 35,5 Prozent aller PHP-Websites noch auf der EOL-Reihe PHP 7.x (W3Techs, 2026), und allein PHP verarbeitet die serverseitige Logik von 72,4 Prozent aller Websites mit bekannter Programmiersprache (W3Techs, 2026). Wer den Wechsel verschleppt, betreibt seinen Shop mit Software, die niemand mehr patcht. Dieser Leitfaden zeigt, wie sich PHP-Upgrades planbar und kontrolliert umsetzen lassen -- mit Code-Audit, [Staging-Tests und Rollback-Absicherung1 statt riskantem Versionssprung auf gut Glück.
Was End of Life bei PHP konkret bedeutet
Jede PHP-Hauptversion durchläuft einen festen Lebenszyklus mit drei Phasen. In der Phase des aktiven Supports (rund zwei Jahre) erhaelt eine Version sowohl Bugfixes als auch Sicherheitspatches. Danach folgt ein Jahr Security-Only: Es fliessen ausschließlich noch Sicherheitskorrekturen, normale Fehler bleiben offen. Am Ende steht das End of Life -- ab diesem Stichtag veröffentlicht das PHP-Projekt keinerlei Patches mehr, auch nicht für schwerwiegende Schwachstellen (php.net).
Die Konsequenz ist eindeutig: Eine EOL-Version sammelt mit jeder neu entdeckten Lücke ungepatchte Angriffsflaeche an. PHP 7.4 etwa erhaelt seit Ende 2022 keine Sicherheitsfixes mehr (endoflife.date) und ist damit gegenüber mehreren öffentlich dokumentierten CVEs dauerhaft verwundbar. Cybersecurity-Researcher fanden zeitweise mehr als 80.000 im Netz erreichbare, verwundbare PHP-Server (Cybernews, 2025). Eine veraltete PHP-Version ist deshalb kein theoretisches Restrisiko, sondern ein konkretes, das Angreifer aktiv abscannen.
PHP 8.1 ist seit dem 31.12.2025 EOL
Der PHP-Support-Fahrplan 2026 auf einen Blick
Um Upgrades sinnvoll zu planen, braucht es einen klaren Blick auf die offiziellen Support-Fenster. Stand 2026 werden nur noch vier PHP-Reihen gepflegt: 8.2, 8.3, 8.4 und 8.5 (php.net). Alles ab PHP 8.1 abwaerts ist End of Life. Die folgende Übersicht zeigt, welche Version wie lange Sicherheitsfixes erhaelt -- daraus ergibt sich automatisch das Zeitfenster, in dem ein Upgrade abgeschlossen sein sollte.
| PHP-Version | Status (2026) | Sicherheitssupport bis | Empfehlung |
|---|---|---|---|
| PHP 7.4 | End of Life | beendet (2022) | Dringend wechseln |
| PHP 8.0 | End of Life | beendet | Dringend wechseln |
| PHP 8.1 | End of Life | beendet (31.12.2025) | Wechsel einplanen |
| PHP 8.2 | Security-Only | 31.12.2026 | Upgrade vorbereiten |
| PHP 8.3 | Security-Only | 31.12.2027 | Solides Ziel |
| PHP 8.4 | Aktiver Support | 31.12.2028 | Zukunftssicheres Ziel |
Die Datumsangaben stammen aus den offiziellen Quellen php.net und endoflife.date (2026). Daraus folgt eine einfache Planungsregel: Wer heute migriert, sollte mindestens PHP 8.3 anpeilen -- diese Reihe erhaelt noch bis Ende 2027 Sicherheitsfixes und verschafft damit Puffer für den nächsten Zyklus. PHP 8.4 als aktiv unterstützte Version ist das zukunftssicherere Ziel, sofern alle [installierten Erweiterungen1 sie bereits unterstützen.
Warum aufgeschobene Upgrades teurer werden
Es gibt einen verbreiteten Trugschluss: Solange der Shop läuft, scheint ein PHP-Upgrade unnötig. Tatsächlich waechst das Risiko mit jedem Monat, den eine EOL-Version weiterläuft. Der aktuelle Verizon Data Breach Investigations Report verzeichnet einen Anstieg der Schwachstellen-Ausnutzung als Erstzugang um 34 Prozent und beziffert deren Anteil an allen Breaches auf rund 20 Prozent (Verizon DBIR, 2025). Ungepatchte Software ist damit eines der häufigsten Einfallstore überhaupt.
Hinzu kommt die Zeitkomponente: Bei neuen, kritischen Schwachstellen an exponierten Systemen lag die mittlere Zeit von der Veröffentlichung bis zur Massen-Ausnutzung zuletzt bei null Tagen -- Angriffe begannen also am Tag der Bekanntgabe (Verizon DBIR, 2025). Gleichzeitig brauchten Organisationen im Median 32 Tage, um solche Lücken zu schließen (Verizon DBIR, 2025). Bei einer EOL-Version verschaerft sich das Bild noch, weil überhaupt kein offizieller Patch erscheint, der eingespielt werden könnte.
Auch technisch wird das Aufschieben teurer. Je größer der Versionsrueckstand, desto mehr Deprecations und Breaking Changes haben sich angesammelt, desto wahrscheinlicher sind inkompatible Erweiterungen -- und desto eher wird aus einem einfachen Upgrade ein aufwendiges [Migrationsprojekt1. Regelmäßige, kleinere Schritte sind planbarer und guenstiger als der erzwungene Großsprung, wenn der Hoster eine veraltete PHP-Version irgendwann abschaltet.
Die Faustregel für planbare Upgrades
Code-Audit: Kompatibilität vor dem Upgrade prüfen
Ein PHP-Upgrade beginnt nicht mit dem Versionswechsel, sondern mit einer Bestandsaufnahme des Codes. Zwischen den Hauptversionen entfernt PHP regelmäßig veraltete Funktionen, verschaerft die Typprüfung und aktiviert zuvor angekuendigte Deprecations. Code, der auf PHP 7.4 ohne Beanstandung lief, kann auf 8.3 Warnungen oder fatale Fehler werfen. Das Audit identifiziert diese Stellen, bevor sie im Live-Betrieb auffallen. Ein konkretes Beispiel ist die kritische PHP-CGI-Lücke CVE-2024-4577 mit einem CVSS-Wert von 9,8 (NVD), die unmittelbar nach Bekanntwerden ausgenutzt wurde (Akamai, 2024) -- ein klarer Beleg, wie schnell aus einer veralteten Konfiguration ein reales Problem wird.
Praktisch laesst sich dieser Schritt automatisieren. Statische Analysewerkzeuge durchsuchen den gesamten Quellcode -- inklusive eigener Plugins, Theme-Anpassungen und Integrationen -- nach Konstrukten, die in der Zielversion nicht mehr funktionieren. Das Ergebnis ist eine priorisierte Liste der notwendigen Anpassungen. Besonders bei Shopware-Shops mit individuellen Erweiterungen liefert dieser Bericht die Grundlage für eine realistische Aufwandsschaetzung.
Statische Code-Analyse
Werkzeuge prüfen den gesamten Quellcode gegen die Zielversion und melden entfernte Funktionen, Deprecations und Typkonflikte vor dem Upgrade.
Erweiterungs-Matrix
Für jede installierte Erweiterung wird die Kompatibilität mit der Ziel-PHP-Version dokumentiert: kompatibel, Update nötig oder Ersatz erforderlich.
Deprecation-Report
Angekuendigte Abkuendigungen werden früh sichtbar, damit Anpassungen geplant statt unter Zeitdruck im Störfall erfolgen.
Versions-Strategie
Statt eines Sprungs von 7.4 auf 8.4 wird ein etappenweiser Pfad über Zwischenversionen definiert, jede einzeln verifiziert.
Abhängigkeiten prüfen
Composer-Pakete und Bibliotheken werden auf Kompatibilität mit der neuen PHP-Reihe abgeglichen und bei Bedarf aktualisiert.
Aufwandsschaetzung
Aus Audit und Matrix entsteht eine belastbare Planung mit Zeitfenster, Reihenfolge und definierten Abbruchkriterien.
Staging: Das Upgrade testen, bevor Kunden es merken
Kein Code-Audit ersetzt einen echten Testlauf. Die [Staging-Umgebung1 ist ein möglichst exakter Klon der Produktivumgebung: gleiche Datenbasis, gleiche Erweiterungen, gleiche Serverkonfiguration. Hier wird die neue PHP-Version zuerst installiert und der komplette Shop unter realistischen Bedingungen geprüft -- ohne dass ein einziger echter Kunde betroffen ist.
Auf Staging läuft das Upgrade zunächst in der Umgebung durch: PHP-Version wechseln, Abhängigkeiten neu auflösen, Cache leeren, Datenbankmigrationen ausführen. Anschließend folgt der eigentliche Test der geschäftskritischen Funktionen. Erst wenn Checkout, Suche, Warenkorb, Kundenkonto und alle Schnittstellen ohne Beanstandung arbeiten, ist die Zielversion freigegeben. Tritt ein Fehler auf, wird er auf Staging behoben -- nicht in der Produktion. Dieser Gate-Ansatz verhindert, dass ein unbemerktes Kompatibilitätsproblem überhaupt erst in den Live-Shop gelangt.
Wichtig ist die Datenaktualität: Ein Staging mit Daten von vor sechs Monaten hat wenig Aussagekraft. Personenbezogene Daten müssen beim Klonen anonymisiert werden, um die DSGVO einzuhalten und versehentliche Test-Mails an echte Kunden zu verhindern. Die [Datenbank-Synchronisation und -Pflege1 ist deshalb eng mit der Upgrade-Planung verzahnt.
# PHP-Version auf Staging prüfen und Upgrade verifizieren
php -v # aktuelle Version anzeigen
composer update --dry-run # Abhängigkeiten gegen Ziel-PHP testen
bin/console cache:clear # Cache nach Versionswechsel leeren
bin/console dal:validate # Datenmodell-Integrität prüfen
# Funktionstests: Checkout, Suche, Warenkorb, API
# Erst nach gruenem Durchlauf -> Go-Live planenErweiterungen und individueller Code als Stolperstein
Erweiterungen sind die häufigste Ursache für fehlgeschlagene PHP-Upgrades. Jedes Plugin, jede Theme-Anpassung und jede Integration enthält eigenen PHP-Code, der mit der Zielversion harmonieren muss. Eine einzige Erweiterung, die eine in der neuen Version entfernte Funktion aufruft, kann den gesamten Shop lahmlegen. Deshalb gehört jede Erweiterung in die Kompatibilitätsmatrix.
Bei Erweiterungen aus der Shopware-Community wird die PHP-Kompatibilität üblicherweise vom Hersteller dokumentiert und gepflegt. Schwieriger sind individuelle Entwicklungen: Eigene Plugins, Template-Overrides und massgeschneiderte Schnittstellen liegen in der Verantwortung des Betreibers und müssen aktiv gegen die neue PHP-Reihe geprüft und gegebenenfalls angepasst werden. Genau hier zahlt sich [professionelle Wartung1 aus, weil die Wechselwirkungen technisches Detailwissen erfordern.
- Jede installierte Erweiterung gegen die Ziel-PHP-Version prüfen und Status dokumentieren
- Erweiterungen mit verfügbarem Update vor dem PHP-Wechsel aktualisieren
- Individuelle Plugins und Template-Overrides im Quellcode auditieren
- Composer-Abhängigkeiten und Bibliotheken auf Kompatibilität abgleichen
- Inkompatible Erweiterungen ersetzen oder mit Alternativlösung deaktivieren
- Alle Anpassungen zuerst auf Staging verifizieren, nie direkt in Produktion
Go-Live mit Rollback-Absicherung
Ist die Zielversion auf Staging freigegeben, folgt der kontrollierte Go-Live. Auch ein sorgfaeltig getestetes Upgrade kann in der Produktion Edge Cases zeigen, die im Test nicht auftraten -- eine bestimmte Warenkorbkonstellation, ein spezifischer Zahlungsweg, eine selten genutzte Schnittstelle. Deshalb ist ein getesteter Rollback-Plan Pflichtbestandteil, kein Extra.
Unmittelbar vor dem Versionswechsel werden ein vollständiger Datenbank-Snapshot und ein Dateisystem-Backup erstellt -- nicht das naechtliche Standard-Backup, sondern ein frischer Stand. Das Rollback-Script, das beides wiederherstellt, wurde zuvor auf Staging getestet. Wer seinen Rollback nie geprobt hat, hat im Ernstfall keinen verlaesslichen Rollback. Das eigentliche Wartungsfenster für den Versionswechsel ist meist kurz, sollte aber bewusst ausserhalb der umsatzstarken Zeiten liegen.
Nach dem Go-Live gilt erhöhte Aufmerksamkeit: Das [Monitoring1 beobachtet Fehlerraten, Antwortzeiten und Conversion in Echtzeit. Klar definierte Schwellenwerte entscheiden über einen Rollback, damit im Ernstfall keine Zeit mit Diskussionen verloren geht. Ein Vorteil überwiegt am Ende den Aufwand: Neuere PHP-Versionen sind deutlich schneller -- ein WordPress-Setup läuft auf PHP 8.3 rund 20 bis 40 Prozent schneller als auf 7.4, ganz ohne Code-Änderung (Kinsta, 2026).
Ein Upgrade ohne getesteten Rollback ist eine Wette. Mit Snapshot, geprobtem Wiederherstellungsweg und Echtzeit-Monitoring wird aus dem Versionswechsel ein Routinevorgang.
PHP-EOL als laufenden Prozess etablieren
Ein einmaliges Upgrade löst das Problem nur vorübergehend, denn der nächste EOL-Termin steht bereits fest. Das deutsche Bundesamt für Sicherheit in der Informationstechnik empfiehlt in seinem IT-Grundschutz, Patches und Aktualisierungen zeitnah nach Veröffentlichung zu bewerten, zu priorisieren und einzuspielen sowie Entscheidungen dazu nachvollziehbar zu dokumentieren (BSI IT-Grundschutz OPS.1.1.3). Für PHP bedeutet das: den Lebenszyklus aktiv verfolgen, statt auf die Hoster-Abschaltung zu warten.
Praktisch laesst sich das in den regulaeren Wartungsrhythmus integrieren. Die installierte PHP-Version wird dokumentiert, kommende EOL-Termine werden im Kalender hinterlegt, und der nächste Upgrade-Schritt wird geplant, sobald die aktuelle Reihe in die Security-Only-Phase eintritt. So bleibt der Shop dauerhaft auf einer unterstützten Version, und jeder Schritt bleibt klein. Ein strukturierter [Wartungsvertrag1 macht aus dem EOL-Management eine wiederkehrende Routine statt einer Feuerwehraktion.
EOL-Termine früh im Kalender vormerken
Quellen und Studien