Was kostet eine PHP-Migration?

"Was kostet das?" ist fast immer die erste Frage. Und die einzige, auf die eine seriöse Pauschalantwort nicht möglich ist. Eine Migration ist keine Ware mit Preisschild. Sie ist ein Vorhaben, dessen Aufwand von wenigen, aber gewichtigen Dingen abhängt. Wenn Sie diese Dinge kennen, können Sie den Preis Ihres eigenen Projekts selbst grob einordnen, noch bevor Sie mit jemandem gesprochen haben.

Die fünf Faktoren, an denen es hängt

Für den eiligen Überblick, bevor wir jeden Punkt einzeln durchgehen:

• Versionsabstand: Wie weit liegen Start und Ziel auseinander?
• Testabdeckung: Gibt es ein Netz, das die Umstellung absichert?
• Fremdabhängigkeiten: Ziehen alle Composer-Pakete und Bundles mit?
• Code-Qualität: Sauber geschichtet oder über Jahre gewachsenes Geflecht?
• Umfang: Wie viel Anwendung ist es wirklich?

Der Versionsabstand ist der offensichtlichste. Der Sprung von PHP 7.4 auf 8 ist etwas völlig anderes als von PHP 5.6 auf 8. Je größer der Abstand, desto mehr Zwischenschritte, entfernte Funktionen und veraltete Muster kommen zusammen.

Der wichtigste Faktor ist aber die Testabdeckung. Ein Projekt mit guten automatisierten Tests lässt sich schnell und mit ruhigem Gewissen umstellen. Fehlen Tests, gibt es nur zwei Wege, und beide kosten. Entweder prüft man alles von Hand, was langsam und fehleranfällig ist. Oder man baut zuerst eine minimale Testabdeckung auf. Das kostet zwar Zeit, zahlt sich aber sofort aus und bleibt danach als Wert im Projekt, lange nach der Migration.

Dann die Fremdabhängigkeiten. Jedes Composer-Paket, jedes Bundle, jede Bibliothek muss den Sprung mitmachen. Ein nicht mehr gepflegtes Paket kann teuer werden, weil es ersetzt oder selbst übernommen werden muss. Manchmal ist eine einzige verwaiste Abhängigkeit der größte Posten im ganzen Angebot.

Die Code-Qualität wirkt in die gleiche Richtung. Sauber geschriebener Code mit klaren Schichten migriert schnell. Ein über Jahre gewachsenes Geflecht aus Sonderfällen, globalem Zustand und kopierten Stellen braucht länger, weil man erst verstehen muss, was da eigentlich passiert.

Und schließlich der Umfang. Zehntausend Zeilen sind planbarer als eine Million. Aber Vorsicht mit dieser Zahl: Ein kleines, verworrenes Projekt kann teurer sein als ein großes, ordentliches. Die reine Zeilenzahl sagt wenig.

Ein Wort noch zur Angst vor endloser Handarbeit, die hinter der Kostenfrage oft steckt. Ein großer Teil der stumpfen Änderungen läuft heute automatisiert. Werkzeuge wie Rector schreiben wiederkehrende Muster selbst um, statische Analyse zeigt die kritischen Stellen. Das drückt genau die Fleißarbeit, die früher die Rechnung aufgebläht hat.

Warum eine Pauschale niemandem hilft

Ein Festpreis ohne Kenntnis dieser Faktoren ist entweder ein Risikoaufschlag zu Ihren Lasten oder eine Kalkulation, die später nachverhandelt wird. Beides ist unangenehm, und beides haben wir bei Projekten gesehen, die vorher woanders lagen. Sauberer ist ein zweistufiges Vorgehen: erst eine Analyse, die den Aufwand belastbar macht, dann ein Angebot mit klarem Rahmen.

Was Sie selbst tun können, um den Preis zu senken

Sie sind dem Aufwand nicht ausgeliefert. Ein paar Dinge senken ihn spürbar.

Früh handeln hilft am meisten. Je aktueller die Ausgangsversion, desto kleiner der Sprung. Wer wartet, vergrößert den Abstand und damit die Rechnung.

Zugang zu Wissen spart ebenfalls. Wenn jemand die fachlichen Eigenheiten der Anwendung erklären kann, entfällt teures Rätselraten darüber, warum eine bestimmte Stelle so gebaut ist, wie sie ist.

Und trennen Sie die Migration von einem Redesign. Eine Migration bringt die Anwendung technisch auf einen aktuellen Stand, funktional bleibt sie gleich. Wer neue Features gleich mit einplant, vermischt zwei Vorhaben und macht beide unübersichtlicher. Erst umziehen, dann umbauen.

Ein Kostenfaktor, den viele erst spät auf dem Schirm haben, sind die indirekten Kosten: die Zeit, in der Ihr Team keine neuen Features baut, weil es an der Migration arbeitet oder den Code während der Umstellung doppelt pflegen muss. Eine saubere Planung hält dieses Zeitfenster so kurz wie möglich. Das gehört in die Rechnung, auch wenn es auf keiner Rechnung steht.

Der ehrliche Weg zur Zahl

Bei uns steht am Anfang immer eine kostenlose Ersteinschätzung. Wir schauen uns die Ausgangslage an, also Versionsstand, Abhängigkeiten, Teststand und Struktur, und nennen einen realistischen Rahmen statt einer Wunschzahl. Das kostet Sie nichts, und Sie wissen danach, woran Sie sind. Das ist mehr wert als eine schnelle Pauschale, die ohnehin nicht gestimmt hätte.

Was eine PHP-Migration kostet, hängt also an Versionsabstand, Tests, Abhängigkeiten, Code-Qualität und Umfang, nicht an einer Preisliste. Die gute Nachricht: Diese Faktoren sind messbar, und einige davon haben Sie selbst in der Hand. Der erste Schritt ist immer, den Ist-Zustand ehrlich zu erfassen. Alles Weitere baut darauf auf.

Weiterführende Quellen

• Rector reduziert den manuellen Migrationsaufwand spürbar
• Unterstützte PHP-Versionen auf php.net (zeigt, wie dringend ein Upgrade ist)
• Im Ratgeber weiterlesen: PHP 7.4 End-of-Life: Warum Warten teuer wird