PHP-Version aktualisieren: Anleitung ohne Ausfall

Um die PHP-Version zu aktualisieren, ohne dass Websites ausfallen, prüfen Sie zuerst Code, Composer-Pakete und Erweiterungen gegen die Zielversion, installieren die neue Version parallel zur alten und schalten dann jede Website einzeln um. Läuft etwas schief, zeigt die Website wieder auf die alte Version, ohne dass Sie ein Backup zurückspielen müssen. Kleine Patch-Releases innerhalb derselben Version spielen Sie dagegen zügig ein, denn sie enthalten vor allem Sicherheitskorrekturen.

Dieser Beitrag führt Sie durch die Bestandsaufnahme, die Kompatibilitätsprüfung, den eigentlichen Umstieg und die Stellen, die beim Aktualisieren am häufigsten vergessen werden.

Patch-Release oder Versionssprung: Was bedeutet PHP-Version aktualisieren eigentlich?

Hinter dem Wunsch, PHP zu aktualisieren, stecken zwei sehr unterschiedliche Vorgänge. Ein Patch-Release hebt etwa 8.3.35 auf 8.3.36. Es ändert keine Sprachfunktionen, sondern behebt Fehler und Sicherheitslücken. Hier ist das Risiko gering und das Abwarten das größere Problem.

Ein Versionssprung wie von 8.2 auf 8.4 ist dagegen ein kleines Migrationsprojekt. Funktionen werden als veraltet markiert oder entfernt, Verhalten ändert sich im Detail, und nicht jede Bibliothek unterstützt die neue Version sofort.

Ein aktuelles Beispiel zeigt, warum Patch-Releases nicht liegen bleiben sollten: Die kritischen Lücken CVE-2026-109618 und CVE-2026-109619 sind erst in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 behoben. Ob Ihre Domains und Subdomains betroffen sind, können Sie mit dem kostenlosen PHP-Sicherheitscheck je Host prüfen. Wann eine ganze Version keine Sicherheitsupdates mehr bekommt und Sie den Sprung einplanen müssen, behandelt der Beitrag zur Lifecycle-Planung für Server und EOL-Termine.

Welche PHP-Version läuft gerade wirklich?

Auf vielen Servern laufen mehrere PHP-Versionen gleichzeitig, oft ohne dass jemand das bewusst entschieden hat. Die Version auf der Kommandozeile sagt nichts darüber, mit welcher Version der Webserver eine bestimmte Website ausführt.

Eine schnelle Bestandsaufnahme auf einem Debian- oder Ubuntu-System mit PHP-FPM:

# Version auf der Kommandozeile
php -v

# Laufende FPM-Instanzen und ihre Sockets
ls /run/php/
systemctl list-units 'php*-fpm*'

# Welche Website nutzt welchen Socket?
grep -Rn "fastcgi_pass\|SetHandler" /etc/nginx /etc/apache2 2>/dev/null

# Cronjobs, die PHP aufrufen
grep -Rn "php" /etc/cron* /var/spool/cron 2>/dev/null

Notieren Sie für jede Website die genutzte Version, die Anwendung (etwa WordPress, Laravel, eine Eigenentwicklung) und wer für den Code verantwortlich ist. Diese Liste ist später Ihre Reihenfolge für den Umstieg. Unter Plesk sehen Sie die Version je Domain direkt in der Oberfläche, weil dort PHP je Domain einstellbar ist.

Ist der Code kompatibel? Prüfen vor dem Umstieg

Die meisten Probleme beim Versionssprung entstehen nicht im eigenen Code, sondern in Abhängigkeiten. Prüfen Sie deshalb in drei Ebenen.

Composer-Pakete

Composer kann direkt sagen, welche Pakete eine bestimmte PHP-Version verhindern:

# Welche Pakete blockieren PHP 8.4?
composer why-not php 8.4

# Passen die installierten Pakete zur aktuellen Plattform?
composer check-platform-reqs

Liefert why-not Treffer, brauchen diese Pakete zuerst ein Update. Manchmal bedeutet das einen Major-Sprung des Frameworks, der deutlich mehr Aufwand verursacht als PHP selbst. Das sollten Sie früh wissen.

Eigener Code

Eine statische Prüfung findet entfernte Funktionen und geänderte Syntax, ohne dass der Code laufen muss. Verbreitet ist PHP_CodeSniffer mit dem Regelwerk PHPCompatibility:

composer require --dev squizlabs/php_codesniffer phpcompatibility/php-compatibility
vendor/bin/phpcs -p --standard=PHPCompatibility \
  --runtime-set testVersion 8.4 \
  --extensions=php --ignore=vendor/ .

Achten Sie darauf, dass die eingesetzte Version des Regelwerks die Zielversion bereits kennt, sonst meldet die Prüfung fälschlich keine Funde. Werkzeuge wie Rector können viele Anpassungen zusätzlich automatisch vorschlagen; lassen Sie sie zuerst mit --dry-run laufen und prüfen Sie die Änderungen im Review.

Deprecations im laufenden Betrieb

Statische Prüfungen sehen nicht alles, besonders bei dynamischem Code. Ergänzen Sie sie durch Logs: Aktivieren Sie in der Testumgebung auf der aktuellen Version alle Meldungen.

; php.ini der Testumgebung
error_reporting = E_ALL
log_errors = On
display_errors = Off
error_log = /var/log/php/staging-error.log

Was heute als Deprecated im Log steht, ist in einer der nächsten Versionen häufig ein Fehler. Wer diese Meldungen regelmäßig abarbeitet, macht jeden späteren Versionssprung kleiner.

PHP-Version aktualisieren in acht Schritten

Der folgende Ablauf geht von einem Linux-Server mit PHP-FPM aus. Unter Plesk oder bei verwaltetem Hosting entfallen einzelne Befehle, die Reihenfolge bleibt gleich.

Bestandsaufnahme abschließen: Liste aller Websites, ihrer aktuellen Version, Anwendung und Verantwortlichen. Websites ohne bekannten Verantwortlichen kommen zuletzt an die Reihe.
Kompatibilität prüfen: Composer-Abhängigkeiten, statische Codeprüfung, Deprecation-Logs. Blockierende Pakete zuerst aktualisieren und separat ausrollen.
Neue Version parallel installieren: Die alte Version bleibt bestehen. Die Standardquellen von Debian liefern meist nur eine PHP-Version, für mehrere Versionen nebeneinander ist eine zusätzliche Paketquelle nötig.
Erweiterungen und Einstellungen angleichen: Vergleichen Sie die geladenen Module und die php.ini der alten und neuen Version, übernehmen Sie Pool-Konfigurationen bewusst statt blind zu kopieren.
In der Testumgebung umstellen: Kernfunktionen durchklicken, Formulare, Login, Checkout, Exporte, Cronjobs auslösen. Das Fehlerlog muss danach sauber sein.
Sicherung vor dem Umschalten: Auch wenn der Rückweg ein Konfigurationswechsel ist, kann eine Anwendung beim ersten Lauf Daten migrieren. Dafür brauchen Sie einen aktuellen Stand der Datenbank.
Website für Website umschalten: Außerhalb der Stoßzeiten, jeweils mit einer Beobachtungsphase im Log, bevor die nächste folgt.
Kommandozeile, Cronjobs und Worker nachziehen, alte Version entfernen: Erst wenn alles stabil läuft und keine Website mehr den alten Socket nutzt.

Für Schritt 4 helfen zwei einfache Vergleiche:

# Geladene Erweiterungen vergleichen
diff <(php8.3 -m) <(php8.4 -m)

# Einstellungen der FPM-Konfiguration vergleichen
diff /etc/php/8.3/fpm/php.ini /etc/php/8.4/fpm/php.ini
ls /etc/php/8.3/fpm/pool.d/ /etc/php/8.4/fpm/pool.d/

Typische Lücken sind fehlende Module wie intl, gd oder redis und angepasste Werte wie memory_limit oder upload_max_filesize, die in der neuen php.ini wieder auf dem Standard stehen.

Umschalten je Website: Wie sieht das konkret aus?

Mit PHP-FPM ist das Umschalten eine Zeile in der Konfiguration des Webservers. Bei nginx ändern Sie den Socket im betroffenen Serverblock:

location ~ \.php$ {
    include snippets/fastcgi-php.conf;
    fastcgi_pass unix:/run/php/php8.4-fpm.sock;
}

Bei Apache mit FPM entsprechend:

<FilesMatch \.php$>
    SetHandler "proxy:unix:/run/php/php8.4-fpm.sock|fcgi://localhost"
</FilesMatch>

Danach Konfiguration testen und neu laden, nicht neu starten: nginx -t && systemctl reload nginx oder apachectl configtest && systemctl reload apache2. Laufende Anfragen werden so nicht abgebrochen.

Installieren Sie die neue PHP-Version parallel zur alten und schalten Sie jede Website einzeln um: Dann ist der Rückweg ein Konfigurationswechsel von Sekunden statt einer Wiederherstellung aus dem Backup. Genau dieser Punkt fehlt in vielen Upgrade-Plänen, die die alte Version im selben Zug deinstallieren.

Die vergessenen Stellen: Kommandozeile, Cronjobs und Worker

Nach dem Umschalten der Websites läuft im Hintergrund oft noch die alte Version weiter. Das fällt erst auf, wenn die alte Version entfernt wird und nachts ein Export ausbleibt.

Kommandozeile: /usr/bin/php zeigt auf eine bestimmte Version. Prüfen Sie mit update-alternatives --display php und stellen Sie bewusst um.
Cronjobs: Einträge mit festem Pfad wie /usr/bin/php8.2 laufen unverändert weiter, Einträge mit php wechseln still mit. Beides sollte eine bewusste Entscheidung sein.
Queue-Worker und Daemons: Prozesse unter systemd oder Supervisor müssen neu gestartet werden, sonst laufen sie bis zum nächsten Neustart mit der alten Version.
Composer und Deployments: Deploy-Skripte und CI-Pipelines sollten dieselbe Version nutzen wie die Produktion, sonst installiert Composer Pakete, die zur Laufzeit nicht passen. Mit composer config platform.php 8.4.0 legen Sie die Zielplattform im Projekt fest.

Bei WordPress lohnt vor dem Umstieg ein Blick auf Plugins und Themes, die lange kein Update mehr bekommen haben: wp plugin list --fields=name,status,version,update liefert die Übersicht. Verwaiste Plugins sind die häufigste Ursache für Fehler nach einem Versionssprung. Eine Testumgebung, wie sie etwa beim WordPress-Hosting mit Staging vorgesehen ist, nimmt dabei das Risiko aus dem Live-Betrieb.

Wann brauchen Sie den Rückweg und wie lange behalten Sie die alte Version?

Schalten Sie zurück, wenn nach dem Umstieg neue Fehler im Log auftauchen, die nicht sofort behebbar sind, oder wenn Kernfunktionen wie Login oder Bestellung betroffen sind. Der Rückweg ist derselbe Konfigurationswechsel in umgekehrter Richtung.

Behalten Sie die alte Version, bis alle Websites und Hintergrundprozesse umgestellt sind und mindestens ein vollständiger Geschäftszyklus durchgelaufen ist. Bei Anwendungen mit Monatsabschluss oder wöchentlichen Exporten heißt das: einmal durch diesen Termin hindurch.

Danach entfernen Sie die alte Version tatsächlich. Eine liegengebliebene Version ohne Sicherheitsupdates, die ein vergessener Cronjob noch nutzt, ist genau die Art von Altlast, die bei der nächsten Sicherheitslücke auffällt.

Wenn Sie den Betrieb nicht selbst übernehmen wollen

Der Ablauf ist technisch überschaubar, kostet aber Zeit für Bestandsaufnahme, Tests und Beobachtung, und er wiederholt sich mit jeder neuen Version. Manche Unternehmen behalten ihn bewusst intern, andere geben ihn an ihren Hosting- oder Entwicklungspartner ab.

NETARO bietet die Hosting-Produkte jeweils als Standard oder Managed an. Beim Managed Hosting gehören Updates, Härtung, Monitoring und Backups mit geprüfter Rücksicherung zum Betrieb. Wichtig ist unabhängig vom Anbieter: Klären Sie schriftlich, wer Versionssprünge plant, wer den Anwendungscode anpasst und wer die Tests abnimmt. Der Hoster kann PHP bereitstellen, die Kompatibilität Ihrer Eigenentwicklung kennt aber nur, wer den Code verantwortet.

FAQ

Kann ich mehrere PHP-Versionen auf einem Server gleichzeitig betreiben?

Ja. Mit PHP-FPM läuft jede Version als eigener Dienst mit eigenem Socket, und jede Website wird im Webserver einem dieser Sockets zugeordnet. Das ist die Grundlage für einen Umstieg ohne Ausfall, verlangt aber, dass Sie für jede installierte Version auch die Sicherheitsupdates einspielen.

Muss ich beim Versionssprung jede Zwischenversion einzeln installieren?

Nein, PHP selbst lässt sich direkt auf die Zielversion heben. Prüfen Sie den Code aber gegen alle Änderungen dazwischen, also bei einem Sprung von 8.2 auf 8.4 auch die Änderungen von 8.3. Bei großem Abstand kann ein Zwischenschritt die Fehlersuche erleichtern, weil weniger Änderungen gleichzeitig wirken.

Wie erkenne ich, ob meine Website nach dem Update Fehler hat?

Über das PHP-Fehlerlog und das Fehlerlog des Webservers, nicht allein über einen Blick auf die Startseite. Rufen Sie gezielt Login, Formulare, Suche und Bestellprozesse auf und lösen Sie Cronjobs manuell aus. Eine Überwachung, die auf HTTP-Statuscodes 500 reagiert, macht Fehler zusätzlich sichtbar.

Wie schnell sollte ich ein PHP-Patch-Release einspielen?

Zeitnah, besonders wenn es Sicherheitslücken behebt. Patch-Releases ändern keine Sprachfunktionen, das Risiko ist daher gering. Ein kurzer Test in der Testumgebung und ein Neustart der FPM-Dienste im Wartungsfenster reichen in den meisten Fällen aus.

PHP-Version aktualisieren: Kompatibilität prüfen, parallel installieren und ohne Ausfall umschalten