Ein PHP-Upgrade klingt nach einem Wochenendprojekt. Freitagabend anfangen, Sonntagabend fertig sein, Montag entspannt in die neue PHP-Version deployen. Wer das schon einmal versucht hat, weiß: Der Montag wird sehr lang. Deprecated Functions, geänderte Typregeln, subtile Verhaltensänderungen in der Standard-Library – und das alles mitten im laufenden Betrieb, während der Chef fragt, warum der Checkout nicht mehr funktioniert.

Das Grundproblem: Big-Bang funktioniert nicht

Der erste Reflex vieler Teams ist ein Feature-Freeze und ein dediziertes Upgrade-Sprint. Das klingt strukturiert, scheitert aber regelmäßig an zwei Faktoren:

  • Die Anzahl der Inkompatibilitäten ist größer als erwartet.
  • Das Wissen über das System ist im Team ungleich verteilt – und der eine Kollege, der das alles noch weiß, ist gerade im Urlaub.

Statt das gesamte System auf einmal umzubauen, setze ich auf eine inkrementelle Strategie, die parallel zum Tagesgeschäft läuft.

Mein Ansatz in drei Phasen

Phase 1: Diagnose

Zunächst analysiere ich den aktuellen Ist-Zustand. Tools wie phpcs, psalm oder rector liefern in Minuten eine Liste aller Inkompatibilitäten – geordnet nach Severity. Damit entsteht ein klares Bild: Wo brennt es, und welche Bereiche sind unkritisch?

Phase 2: Automatisierung

Vieles, was sich wie manuelle Arbeit anfühlt, lässt sich automatisieren. Rector kann Hunderte von Codeänderungen auf Knopfdruck durchführen – type-safe, testbar, rückgängig machbar. Das gibt dem Team Sicherheit und spart Zeit für die wirklich komplexen Stellen, an denen kein Tool der Welt helfen kann.

Phase 3: Schrittweise Umstellung

Das Upgrade läuft als Parallelzweig. Mit PHPStan-Level 0 starten, iterativ erhöhen. Kein Produktionsdeployment ohne grüne CI-Pipeline. Kurze Wartungsfenster statt langer Freezes. Das Ergebnis: Das Team liefert weiter, die Codequalität steigt kontinuierlich – und niemand muss am Wochenende arbeiten.

Was dieser Ansatz bringt

Teams, die so vorgehen, berichten nach einem erfolgreichen Upgrade nicht nur von besserer Performance durch JIT und neue PHP-8-Features – sie berichten auch von gestiegenem Vertrauen in den eigenen Code. Weil Tests existieren. Weil die CI sauber ist. Weil das Upgrade nicht als Krise, sondern als normaler Schritt im Entwicklungsprozess lief.

Das Ziel ist nicht das Upgrade selbst – das Ziel ist ein System, das man ohne Angst anfassen kann.