Vom alten PHP auf PHP 8. Im laufenden Betrieb, mit Rückweg je Schritt.

Der Befund kostet ab 1.250 Euro netto und sagt Ihnen, was die Umsetzung kostet. Ohne Analyse ist jede Zahl geraten: Zwei Anwendungen mit derselben Zeilenzahl können um den Faktor zehn auseinanderliegen, je nachdem, ob die Abhängigkeiten gepflegt sind und ob es Tests gibt. Die Umsetzung wird nach dem Befund zum Festpreis angeboten, bevor sie beginnt.

Stand August 2026: PHP 8.2 bis zum 31. Dezember 2026, PHP 8.3 bis Ende 2027, PHP 8.4 bis Ende 2028 und PHP 8.5 bis Ende 2029. Alles bis einschließlich 8.1 ist ohne Unterstützung, PHP 7.4 seit Ende 2022. Als Ziel empfehle ich in der Regel 8.4: eine Fassung, die lange genug draußen ist, dass die Bibliotheken nachgezogen haben, und die noch über zwei Jahre Unterstützung hat.

Nein, das ist ein regelmäßiger Fall. Er ist aber ein anderes Vorhaben als ein Sprung von 7.4: Zwischen 5 und 7 liegen die härteren Brüche, die alten Datenbankfunktionen sind ersatzlos entfernt, aus Fehlern wurden Ausnahmen. Deshalb läuft der Weg über eine Zwischenversion in zwei Etappen, jede einzeln produktiv und einzeln zurückdrehbar. Ich bin Zend Certified Engineer für PHP 5.3, kenne die Ausgangswelt also nicht nur aus der Migrationsdokumentation. Was Ihr Fall bedeutet, steht nach dem Befund fest, nicht vorher.

Ja, das ist der Normalfall. Dann entsteht vor dem ersten Eingriff ein Netz aus Characterization Tests, das festhält, was das System heute tut. Es muss nicht vollständig sein: Es deckt die Stellen ab, die angefasst werden, und die Wege, an denen Geld hängt. Dieses Netz bleibt Ihnen danach erhalten.

Nein. Das Upgrade läuft als Folge kleiner Umstellungen, jede einzeln ausrollbar und einzeln zurückdrehbar. Bei der Redaktionsplattform aus meinen Case Studies lief die Modernisierung ohne einen Tag Ausfall, obwohl Sprache, Suche und Plattform gewechselt wurden. Entscheidend ist, dass möglichst wenig gleichzeitig in Bewegung ist: Sprachwechsel, Suche und Plattform waren dort drei getrennte Vorhaben mit eigenem Rückweg.

Das ist der häufigste harte Fall, und er hat drei Antworten: eine gepflegte Alternative mit derselben Aufgabe, eine eigene schmale Umsetzung genau dessen, was Sie tatsächlich benutzen, oder das Abtrennen des Bereichs hinter eine eigene Schnittstelle. Welche Antwort trägt, steht im Befund samt Aufwand, statt sich mitten in der Umsetzung zu zeigen.

Das ist die Ausgangslage in den meisten dieser Vorhaben. Es gibt keine Dokumentation, keine Tests und niemanden mehr zu fragen. Der erste Schritt ist dann kein Umbau, sondern zu verstehen, was das System heute wirklich tut, samt der Eigenarten, die niemand geplant hat und auf die sich trotzdem jemand verlässt. Diese Bestandsaufnahme gehört ohnehin zum Befund.

Ja, aber als eigenes Vorhaben, nicht nebenbei. Ein Sprung über mehrere Symfony- oder Laravel-Hauptversionen ist regelmäßig größer als der Sprachwechsel selbst und braucht eine eigene Reihenfolge. Beides gleichzeitig zu machen ist der zuverlässigste Weg, hinterher nicht mehr zu wissen, woran ein Fehler lag.

Messbar schneller, aber die Größenordnung hängt an Ihrer Anwendung, nicht an der Sprache. Ich nenne dazu keine Prozentzahl aus einer Broschüre. Was ich stattdessen tue: vorher und nachher an denselben Wegen messen und die Zahl in den Abschlussbericht schreiben.