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. Wir bringen 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 gehen wir vor

Inventur: Wir lassen Rector und PHPStan mit Deprecation-Regeln laufen und bekommen eine vollständige Liste der Bruchstellen, statt sie erst in Produktion zu finden.
Absicherung: Charakterisierungstests um die kritischen Pfade (Login, Bestellung, Import), damit wir Änderungen messen können.
Migration in Stufen: 5.6 → 7.4 → 8.x, jeweils grün, jeweils deploybar. Kein Sprung ins Leere.
Ü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?

Wir empfehlen die aktuellste Version, die Ihre Abhängigkeiten zulassen. Sonst stehen Sie in zwei Jahren wieder vor demselben Problem. Wo 8.4 nicht geht, sagen wir Ihnen, warum.

Wie lange läuft mein System parallel weiter?

Die ganze Zeit. Wir arbeiten 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?

Wir ersetzen 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.