Matthias Gläßner – Senior TYPO3 Architekt

PHP 7.x → 8.x · Hosting-Druck · Security · TYPO3-Kompatibilität

TYPO3 & PHP Version Upgrade:
planbar statt „500er nach dem Update“

Ein PHP Upgrade ist selten „nur ein Server-Schalter“ – vor allem in TYPO3-Systemen mit vielen Extensions, Legacy-Code oder individuellen Integrationen. Mit einem sauberen Ablauf wird es beherrschbar: Risiken klären, Tests aufsetzen, Go-Live planen – inklusive Rollback.

Fokus: Upgrade-Sicherheit & Planbarkeit Für Unternehmen, Agenturen & öffentliche Träger
PHP/TYPO3 Upgrade prüfen lassen Leistung: Upgrades & Migration

Antwort i. d. R. binnen 24–48 h (Mo–Fr) · NDA/AVV möglich

Warum ein PHP Upgrade in TYPO3-Projekten oft eskaliert

In vielen Installationen hängt mehr an PHP als gedacht: Core-Kompatibilität, Composer-Abhängigkeiten, Drittanbieter-Libs und insbesondere individuelle oder veraltete Extensions.

Das Risiko steigt, wenn ein System lange nicht modernisiert wurde: dann kommen bei einem Upgrade mehrere Baustellen gleichzeitig zusammen (PHP, TYPO3 Core, Extensions, Datenbank, Deployments).

  • Legacy-Code / alte Extensions reagieren empfindlich auf neue PHP-Versionen.
  • Composer-/Dependency-Konflikte blockieren Updates (auch indirekt durch Libraries).
  • Fehlende Tests: Fehler werden erst im Live-System sichtbar.
  • Kein Rollback: aus „kurz Wartung“ wird „lange Downtime“.

Typische Fehler nach einem PHP Upgrade (und was dahinter steckt)

Wenn nach dem PHP-Update plötzlich „nichts mehr geht“, ist das häufig kein einzelner Bug, sondern ein Kompatibilitätsmix aus Code, Dependencies und Konfiguration.

500 / White Screen / Fatal Error

Meist verursacht durch inkompatible Extension-APIs, Strict Types-Probleme, ungültige Signaturen oder deprecated Funktionen.

  • • Exception in Extension-Klassen / Hooks / Event Listener
  • • PHP-Fatal durch veränderte Parameter-Typen
  • • Fehler im Autoloading / Composer-Classmap

Backend lädt, aber Funktionen sind „kaputt“

Oft ein Mix aus JavaScript-Fehlern, geänderter PHP-Fehlerbehandlung oder inkonsistenten APIs.

  • • FormEngine/Backend-Module brechen
  • • DataHandler / TCA-Felder verhalten sich anders
  • • Scheduler Tasks schlagen fehl

Composer / Abhängigkeiten lassen sich nicht updaten

PHP zwingt neue Versionen von Libraries – und plötzlich kollidieren Constraints (TYPO3 Core, Extensions, Drittanbieter).

  • • locked Packages blockieren (composer.lock)
  • • Extensions pinnen alte Libs
  • • „Minimum PHP Version“ Konflikte

Performance/Timeouts nach Upgrade

Unterschiedliche Defaults (Memory, Opcache), Query-Verhalten oder Cache-Settings machen sich bemerkbar.

  • • Opcache/Realpath Cache falsch dimensioniert
  • • DB-Queries und Indizes nicht im Blick
  • • fehlendes Profiling / fehlende Cache-Strategie

Praxis-Tipp: Wenn du einen „Big Bang“ vermeiden willst, mache PHP & TYPO3 nicht blind live. Erst Staging stabilisieren, Smoke-Tests automatisieren, dann kontrollierter Cutover.

Mehr dazu: Testing in TYPO3-Projekten →

Planbarer Ablauf: PHP Upgrade in 5 Schritten (mit Rollback)

Du musst nicht „mutig“ sein – du brauchst einen Ablauf, der Risiken reduziert und Fortschritt messbar macht. Der folgende Prozess funktioniert in Agentur-Setups ebenso wie in Inhouse-Teams.

01 · Bestandsaufnahme

Kompatibilität & Risiko klären

  • • TYPO3 Version + PHP Zielversion festlegen
  • • Extension-Landschaft + Custom Code prüfen
  • • Composer-Constraints & Abhängigkeiten
  • • „Showstopper“ identifizieren

02 · Staging & Deployment

Reproduzierbar deployen

  • • Staging nah an Live (Config, DB, Cache)
  • • CI/CD oder definierter Release-Prozess
  • • Rollback-Mechanik (Artefakte, DB Plan)

03 · Fixes & Refactoring

Compatibility herstellen

  • • Legacy-Code modernisieren (kritische Stellen zuerst)
  • • Extensions upgraden / ersetzen / patchen
  • • Deprecations & Warnungen entfernen

04 · Tests

Smoke-Tests als Minimum

  • • Login + Backend Kernpfade
  • • Page Rendering, Formulare, Suche
  • • Schnittstellen-Jobs / Scheduler

05 · Cutover

Kontrolliertes Go-Live

  • • Wartungsfenster & Kommunikationsplan
  • • Monitoring & Logs aktiv beobachten
  • • Rollback bereit halten (Plan + Zuständigkeiten)

Bonus

Quick Wins für Stabilität

  • • phpstan/rector als Safety-Net in CI
  • • Error-Reporting sauber konfigurieren
  • • Opcache + Memory Limits richtig setzen
  • • „Health Checks“ für Jobs & Search

Was kostet ein PHP Upgrade typischerweise?

Stark abhängig von TYPO3-Version, Anzahl/Qualität der Extensions, Deployment-Reife und Testabdeckung. Der größte Kostentreiber ist selten „PHP selbst“, sondern Legacy + fehlende Automatisierung.

  • • Low: modernes Setup, wenig Custom Code, saubere Pipelines
  • • Medium: mehrere Extensions, einige Refactorings, Basis-Tests notwendig
  • • High: Legacy v6–v8, alte APIs, Inkompatibilitäten, fehlendes CI/CD
Mehr Details: Upgrade Kosten & Aufwand →

Der einfachste Einstieg: Upgrade-Risiko in wenigen Tagen klären

Wenn du gerade unter Hosting-/Security-Druck stehst („PHP muss hoch“) und nicht riskieren willst, dass dein TYPO3-System danach instabil ist: starte mit einem kurzen Audit. Danach sind Reihenfolge und Aufwand klar – und du bekommst einen echten Plan.

  • Risiken & Aufwand (S/M/L) als Entscheidungsgrundlage
  • Extension-/Code-Check + Quick Wins
  • Teststrategie, Cutover- & Rollback-Plan

FAQ: TYPO3 PHP Upgrade

Die häufigsten Fragen aus der Praxis – kurz beantwortet.

Ist PHP Upgrade oder TYPO3 Upgrade zuerst sinnvoll? ›
Das hängt vom Ist-Stand ab. Häufig ist ein kombiniertes Vorgehen sinnvoll, weil TYPO3-Versionen nur bestimmte PHP-Versionen offiziell unterstützen und Extensions sonst „zwischen den Stühlen“ hängen. Ein kurzes Audit klärt die beste Reihenfolge.
Welche Tests brauche ich mindestens? ›
Minimum: automatisierte Smoke-Tests für Kernpfade (Startseite, Navigation, Suche, Formular, Login), plus ein definierter Abnahme-Flow. Ideal: Unit/Functional Tests für kritische Integrationen.
Was sind die größten Aufwandstreiber? ›
Custom Code ohne Tests, viele Dritt-Extensions, alte Composer-Setups, fehlende CI/CD-Pipelines, kein Staging und keine klare Rollback-Strategie. Das lässt sich aber strukturieren.
Was, wenn es schon „brennt“ und Live down ist? ›
Dann geht es um Stabilisierung: Logs lesen, Fehler eingrenzen, Hotfix/Rollback, anschließend saubere Nacharbeit (Audit + Plan). Wenn es akut ist: im Kontakt „RESCUE“ schreiben.
PHP/TYPO3 Upgrade jetzt einordnen lassen

Unverbindlich · vertraulich · Antwort i. d. R. binnen 24–48 h (Mo–Fr)