PHP-Migration auf PHP 8.4

PHP 5 und 7 bekommen keine Sicherheits-Updates mehr, Hoster schalten sie ab, moderne Bibliotheken laufen nicht mehr darauf. Ich bringe Ihre Anwendung schrittweise und getestet auf PHP 8.4 – ohne dass Ihr Betrieb dafür stehen muss.

Typische Symptome

• Der Hoster kündigt das Ende von PHP 7.x an – oder hat es schon abgeschaltet.
• Nach einem Versuch, PHP hochzudrehen: weiße Seite, mysql_*-Fatals, each(), create_function().
• Composer-Pakete lassen sich nicht mehr aktualisieren, weil die PHP-Version zu alt ist.
• Ein Audit oder ein Kunde verlangt eine unterstützte Version.

So gehe ich vor

1. Inventur: Ich lasse Rector und PHPStan mit Deprecation-Regeln laufen und bekomme eine vollständige Liste der Bruchstellen – statt sie in Produktion zu finden.
2. Absicherung: Charakterisierungstests um die kritischen Pfade (Login, Bestellung, Import), damit ich Änderungen messen kann.
3. Migration in Stufen: 5.6 → 7.4 → 8.x, jeweils grün, jeweils deploybar. Kein Sprung ins Leere.
4. Übergabe: Änderungsprotokoll, aktualisierte Docker-Umgebung, Liste dessen, was bewusst nicht angefasst wurde.

Dauer und Paket

Eine reine Versions-Migration ist meist in 2–6 Wochen erledigt – das ist die Minimal-Migration. Soll dabei auch Struktur und Testabdeckung entstehen, ist es die Vollmodernisierung. Unsicher? Der Befund sagt es Ihnen schwarz auf weiß.

Häufige Fragen

Muss ich direkt auf 8.4, oder reicht 8.1?

Ich empfehle die aktuellste Version, die Ihre Abhängigkeiten zulassen – sonst stehen Sie in zwei Jahren wieder vor demselben Problem. Wo 8.4 nicht geht, sage ich, warum.

Wie lange läuft mein System parallel weiter?

Die ganze Zeit. Ich arbeite auf einer Kopie und in Git; Produktion wird erst umgestellt, wenn alle Tests grün sind und Sie abgenommen haben.

Was passiert mit Bibliotheken, die es nicht mehr gibt?

Ich ersetze sie durch gepflegte Alternativen oder – wenn die Funktion klein ist – durch eigenen, getesteten Code. Das wird vorab im Befund aufgelistet, nicht erst während der Arbeit entdeckt.