PHP-Version aktualisieren: Ablauf, Aufwand und Stolpersteine

Bis wann welche PHP-Version unterstützt wird und wie lange Schweizer Hoster alte Versionen anbieten, steht im Artikel PHP End of Life, die Fristen von PHP, Frameworks und CMS bis 2029 im End-of-Life-Kalender. Hier geht es um den nächsten Schritt: wie das Upgrade abläuft und wie gross es für deine Anwendung wird.

Wovon hängt der Aufwand eines PHP-Upgrades ab?

Fünf Punkte bestimmen, ob dein Upgrade ein paar Tage oder ein paar Monate dauert:

1. Ausgangsversion. Innerhalb von PHP 8 ändern sich vor allem Details. Der Sprung von PHP 7 auf 8 bricht dagegen bestehenden Code.
2. Framework oder CMS. Läuft deine Version von Laravel, Symfony, TYPO3 oder Shopware nicht auf der neuen PHP-Version, muss sie zuerst aktualisiert werden. Das ist meist der grössere Teil der Arbeit.
3. Pakete und Erweiterungen. Jede Bibliothek und jede Extension muss die neue Version ebenfalls unterstützen. Verwaiste Pakete, die niemand mehr pflegt, müssen ersetzt werden.
4. Tests. Gibt es automatische Tests, zeigen sie nach jeder Änderung, ob noch alles läuft. Fehlen sie, braucht es zuerst Tests für die wichtigsten Abläufe, etwa Login, Bestellung oder Rechnung.
5. Kenntnis der Anwendung. Wer die Anwendung kennt, weiss, wo die Sonderfälle stecken. Ist der ursprüngliche Entwickler weg, kommt eine Bestandsaufnahme dazu.

Wie gross ist der Schritt von meiner Version auf PHP 8.4?

Die Tabelle ordnet den Sprung auf eine aktuell unterstützte Version (PHP 8.4 oder 8.5) nach Ausgangsversion ein. Sie ersetzt keine Prüfung deines Codes, zeigt dir aber, womit du rechnen musst.

Ausgangsversion	Was sich im Code ändert	Muss das Framework mit?	Grössenordnung
PHP 8.3	Wenige veraltete Konstrukte, etwa implizit nullbare Parametertypen	Selten	Klein
PHP 8.1 und 8.2	Dazu: dynamische Eigenschaften und ${} in Strings veraltet (8.2), null an internen Funktionen veraltet (8.1)	Oft, wenn die Framework-Version älter ist	Klein bis mittel
PHP 7.4 und 8.0	Ab 8.0: entfernte Funktionen wie each() und create_function(), strengere Typprüfung, viele Hinweise werden zu Fehlern, Vergleiche zwischen Zahlen und Strings verhalten sich anders	Fast immer, viele Versionen aus der PHP-7-Zeit laufen nicht auf PHP 8	Mittel bis gross
PHP 7.0 bis 7.3	Zusätzlich alles, was zwischen 7.0 und 7.4 veraltet ist	In der Regel über mehrere Hauptversionen	Gross
PHP 5.6 und älter	Zusätzlich: die alten mysql_*-Funktionen und ereg sind seit PHP 7.0 entfernt, Datenbankzugriffe müssen umgebaut werden	Meist mehrere Hauptversionen oder Ablösung	Gross

Veraltete Funktionen («deprecated») laufen zunächst weiter und erzeugen nur Warnungen. Entfernt werden sie erst in einer späteren Hauptversion. Behebst du sie beim Upgrade gleich, hast du es beim nächsten leichter. Ist der Schritt gross und die Ablösung deiner Anwendung ohnehin geplant, hilft der Artikel Altsystem bis zur Ablösung bei der Wahl zwischen investieren, einfrieren und umstellen.

Welche PHP-Version unterstützt mein Framework oder CMS?

Muss deine Anwendung auf PHP 8.4, entscheidet meist das Framework oder CMS über den Aufwand. Die Tabelle zeigt, ab welcher Version PHP 8.4 laut Hersteller unterstützt wird und wo ältere Versionen enden. Massgebend sind die Systemanforderungen der Hersteller, die composer.json der jeweiligen Version und, wo keine Obergrenze genannt ist, die automatischen Tests des Herstellers. Stand: 27. Oktober 2026.

System	PHP 8.4 ab	Ältere Versionen enden bei	Was das für das Upgrade heisst
Laravel	Laravel 11	10: PHP 8.3 · 8: PHP 8.1 · 5.8: PHP 7.4	Mehrere Hauptversionen, Ziel Laravel 13. Laravel 11 bekommt seit 12. März 2026 keine Sicherheitsupdates mehr, Laravel 12 nur bis 24. Februar 2027.
Symfony	5.4 LTS (letzte Patches), 6.4 LTS, 7.4 LTS, 8	4.4: PHP 8.2 · 3.4: PHP 7.4	Naheliegendes Ziel ist 7.4 LTS. 5.4 bekommt nur noch Sicherheitsupdates.
CakePHP	5.1	4.x: PHP 8.3 · 2.x und 3.x: PHP 7.4	Von 2.x oder 3.x ein Umbau über 3 und 4 auf 5. CakePHP 4 bekommt seit 10. September 2026 keine Sicherheitsupdates mehr.
CodeIgniter	4.6	4.5: PHP 8.3 · 3.x: PHP 8.1	CodeIgniter 3 heisst: Umbau auf 4 oder eigene Anpassungen auf eigenes Risiko.
Yii	Yii 2 ab 2.0.50	2.0.49 und älter: PHP 8.3	Yii 2 bis 2.0.49 verliert am 23. November 2026 den Support. Yii 1.1 ist bis PHP 8.4 getestet, bekommt ab 2027 aber keine Updates mehr.
Zend Framework & Laminas	Laminas MVC 3.8, Mezzio	Zend Framework 1 bis 3: höchstens PHP 7 getestet	Umstieg auf Laminas oder Mezzio. Laminas MVC bekommt kein PHP 8.5 mehr und endet am 31. Dezember 2028.
Neos & Flow	Neos/Flow 8.0	7: PHP 8.1 · 3 bis 5: PHP 7.x	Neos 9.2 setzt PHP 8.4 voraus, PHP-Upgrade und Migration auf Neos 9 gehören zusammen.
TYPO3	12.4 (nur noch kostenpflichtiges ELTS), 13.4, 14	11.5: PHP 8.3 · 8.7 bis 10.4: PHP 7.4	Upgrade über die LTS-Stufen, sinnvollerweise gleich auf 13.4 oder 14.
Drupal	10.4	9: PHP 8.1 · 8: PHP 7.4 · 7: PHP 8.3	Von Drupal 7 bis 9 eine Migration. Drupal 10.6 läuft im Dezember 2026 aus, Ziel ist meist Drupal 11.
Joomla	5.x, 6.x	4.4: PHP 8.3 · 3.10: PHP 8.0	Über 4.4 auf 5 oder 6.
Contao	5.3 LTS, 5.7 LTS, 6.0	4.13: PHP 8.3 · 4.9: PHP 8.1 · 4.4: PHP 7.3	Von Contao 4 auf 5.3 oder 5.7 LTS.
Craft CMS	Craft 4 und 5	3: PHP 8.1	Craft 4 hat seit 30. April 2026 keinen Support mehr, Ziel ist Craft 5. Plugins mittesten.
Silverstripe	6	5: PHP 8.3 · 4: PHP 8.1 · 3: PHP 7.4	Von 4 oder 5 auf 6, von 3 zuerst der grosse Sprung auf 4.
Statamic	5 und 6	4: PHP 8.3 · 3.4: PHP 8.1	Statamic 5 fällt Ende 2026 aus dem Support, meist lohnt sich gleich Statamic 6.
Shopware	6.6.10	6.5: PHP 8.3 · 6.4: PHP 8.1 · 5.7: PHP 8.2	Von Shopware 5 eine Migration auf 6, von 6.4 und 6.5 ein Update auf 6.6.10 oder 6.7 samt allen Plugins.
Magento	2.4.8	2.4.7: PHP 8.3 · 2.3: PHP 7.4	2.4.9 verlangt bereits PHP 8.5. Magento 1 läuft auf aktuellem PHP nur als Community-Fork OpenMage LTS.

Bei einer Anwendung ohne Framework gibt es keine solche Grenze. Dort entscheidet allein dein Code, und die Prüfung mit den Werkzeugen aus dem nächsten Abschnitt wird umso wichtiger.

Wie läuft ein PHP-Upgrade ab?

1. Bestandsaufnahme. Welche PHP-Version läuft, welche Framework- und Paketversionen, welche Erweiterungen des Servers werden genutzt? Die composer.json und das Hosting-Panel geben die erste Antwort.
2. Kopie aufsetzen. Code und Datenbank in eine Testumgebung mit der neuen PHP-Version holen. Live wird erst umgestellt, wenn die Kopie läuft.
3. Automatisch prüfen. Werkzeuge wie PHPCompatibility und PHPStan finden entfernte Funktionen und Typfehler, Rector behebt viele davon automatisch.
4. Abhängigkeiten aktualisieren. Framework und Pakete auf Versionen bringen, die die neue PHP-Version unterstützen. Bei grossen Sprüngen Hauptversion für Hauptversion, jeweils nach dem offiziellen Upgrade-Guide.
5. Die wichtigsten Abläufe testen. Was deinen Kunden oder im Betrieb sofort auffallen würde: Anmeldung, Bestellung, Formulare, Exporte, Schnittstellen und geplante Aufgaben (Cronjobs).
6. Live umstellen, mit Weg zurück. Backup ziehen, PHP-Version umstellen, neuen Code ausrollen. Klemmt etwas, muss der alte Stand innert Minuten zurück sein.
7. Beobachten. In den ersten Tagen die Fehlerlogs eng verfolgen, weil manche Probleme nur in seltenen Abläufen auftreten, etwa beim Monatsabschluss.

Typische Stolpersteine

• Die weisse Seite. Ein schwerer Fehler beim Laden, und nichts wird mehr angezeigt. Häufigster Grund: eine entfernte Funktion oder ein inkompatibles Paket. Die Ursache steht im PHP-Fehlerlog, nicht im Browser. Was du tun kannst, wenn deine Website schon so dasteht, zeigt der Artikel Webapplikation wieder zum Laufen bringen.
• Pakete ohne Nachfolger. Ein Modul, eine Extension oder eine Bibliothek wird nicht mehr gepflegt und läuft auf der neuen Version nicht. Dann braucht es Ersatz oder einen Fork.
• Stille Verhaltensänderungen. Seit PHP 8.0 sind etwa Vergleiche wie 0 == "abc" falsch statt wahr. Das erzeugt keinen Fehler, aber falsche Ergebnisse, und fällt nur mit Tests auf.
• Unterschiede zwischen Test und Live. Andere Server-Erweiterungen, andere Einstellungen, andere Cronjobs. Die Testumgebung sollte dem Live-Server so ähnlich wie möglich sein.
• Kommandozeile vergessen. Bei manchen Hostern gilt die Umstellung im Panel nur für die Website, Cronjobs und Skripte laufen weiter mit der alten Version. Beides gehört zusammen umgestellt.

Was, wenn niemand deine Anwendung mehr kennt?

Dann braucht sie zuerst wieder jemanden, der sie kennt, und vor dem Upgrade steht eine Bestandsaufnahme: Welche Teile hängen an der alten Version, welche Pakete bremsen, wie gross ist der Schritt wirklich? Genau das zeigt das Übernahme-Assessment, mit einem Fixpreis für die Umsetzung. Danach hält die laufende Wartung PHP, Framework und Pakete im festen Rhythmus aktuell, damit das nächste Upgrade wieder klein bleibt. Steht deine Anwendung nach einer Umstellung des Hosters schon still, hilft der Notfall-Eingriff. Wie eine Übernahme insgesamt abläuft, zeigt die Seite Webapplikation übernehmen.