Die Frage kommt in fast jedem Erstgespräch, meist schon in den ersten fünf Minuten: "Wie lange dauert das?" Verständlich, denn an der Antwort hängen Budget, Roadmap und oft die Nerven eines ganzen Teams. Ehrlich ist aber auch: Wer Ihnen ohne einen Blick in den Code eine Wochenzahl nennt, rät. Und wer "drei Monate" sagt, weil das gut klingt, verkauft Ihnen ein Risiko.
Dieser Artikel gibt Ihnen kein magisches Datum, sondern etwas Nützlicheres: ein realistisches Modell, um die PHP Migration Dauer für Ihr konkretes System selbst einzuordnen. Und eine Haltung, die Ihnen viel Geld sparen kann.
Warum die PHP Migration Dauer nicht am PHP-Update hängt
Der eigentliche Sprung von PHP 7.4 auf 8.2 oder 8.3 ist technisch überschaubar. Deprecations, geänderte Typ-Coercion, das entfernte each(), striktere Fehlerklassen statt stiller Warnungen. Für einen sauberen Codebestand ist das eine Sache von Tagen, unterstützt von Werkzeugen wie Rector und PHPStan.
Zeit kostet nicht das neue PHP. Zeit kostet alles, was sich in den Jahren um die Fachlogik herum angesammelt hat. Ein System, das seit acht Jahren zuverlässig Rechnungen schreibt, ist kein Sanierungsfall. Es ist der Beweis, dass die Geschäftslogik stimmt. Das Problem sitzt fast nie in dieser Logik, sondern in der Schicht drumherum: globaler Zustand, direkte SQL-Strings mitten in der View, eine Handvoll Abhängigkeiten, die seit Jahren nicht mehr gepflegt werden.
Welche Faktoren die Dauer wirklich bestimmen?
Die realistische Schätzung entsteht aus wenigen, gut prüfbaren Fragen. Diese Faktoren verschieben den Aufwand am stärksten:
- Testabdeckung. Gibt es automatisierte Tests, kann man jede Änderung sofort gegenprüfen. Gibt es keine, ist das Schreiben von Charakterisierungstests oft der größte Einzelposten der Migration, noch vor der eigentlichen Code-Anpassung.
- Kopplung an das Framework oder die PHP-Version. Ein altes Symfony 3 oder eine selbstgebaute Struktur mit Logik in globalen Funktionen braucht mehr Vorarbeit als eine bereits halbwegs entkoppelte Anwendung.
- Abhängigkeiten Dritter. Eine veraltete Bibliothek ohne PHP-8-Support kann ein Update blockieren, bis sie ersetzt oder gekapselt ist.
- Datenbank und Datenmengen. Schema-Migrationen auf großen Tabellen im laufenden Betrieb sind ein eigenes Kapitel mit eigenem Zeitbedarf.
- Deployment und Umgebung. Läuft alles auf einem manuell konfigurierten Server ohne reproduzierbare Umgebung, gehört das Herstellen einer testbaren Staging-Umgebung mit zur Migration.
Auffällig: In dieser Liste taucht "Komplexität der Fachlogik" nicht auf. Das ist kein Zufall.
Wie läuft eine realistische Migration ab?
Eine seriöse Migration ist kein einzelner Kraftakt, sondern eine Abfolge von Schritten, die jeweils lauffähigen Code hinterlassen. In der Regel sieht das so aus:
- Bestandsaufnahme. Codebasis, Abhängigkeiten, PHP-Version, Testlage und Infrastruktur werden gesichtet. Hier entsteht die belastbare Schätzung.
- Sicherheitsnetz. Reproduzierbare Umgebung und Charakterisierungstests für die kritischen Pfade, bevor eine einzige Zeile geändert wird.
- Abhängigkeiten aktualisieren. Composer-Pakete auf PHP-8-fähige Stände bringen, Blocker ersetzen.
- Code anpassen. Deprecations beheben, meist teilautomatisiert mit Rector, statisch geprüft mit PHPStan.
- Schrittweise ausrollen. Wo möglich in kleinen, einzeln deploybaren Etappen statt in einem großen Big-Bang.
Wie lange dauert eine PHP-Migration im Durchschnitt?
Eine ehrliche Spanne statt einer Scheinpräzision: Eine gut gepflegte Anwendung mit Tests und aktuellem Framework lässt sich oft in wenigen Wochen auf eine neue PHP-Version heben. Ein gewachsenes System ohne Tests, mit veralteten Abhängigkeiten und ohne Staging-Umgebung landet realistisch bei mehreren Monaten, weil das Sicherheitsnetz erst geschaffen werden muss.
Der Unterschied zwischen diesen beiden Fällen liegt fast vollständig im Zustand des Codes drumherum, nicht in der Größe der Anwendung. Ein kleines, aber untestbares System kann länger dauern als ein großes, sauber strukturiertes.
Ist Neuentwicklung nicht schneller als Migration?
Meistens nicht. Neuentwicklung ist in der Regel die teuerste und riskanteste Option, auch wenn sie sich zu Beginn befreiend anfühlt. Der Grund: Sie werfen dabei nicht nur alten Code weg, sondern auch jahrelang erprobtes Wissen über Sonderfälle.
Jede seltsame if-Verzweigung in einem alten System ist oft die Narbe eines echten Problems, das irgendwann jemand gemeldet hat. Ein Neubau reproduziert diese Sonderfälle nicht automatisch. Er reproduziert sie schmerzhaft, einen Bug-Report nach dem anderen, während das alte System längst wusste, wie es geht. Eine Migration bewahrt dieses Wissen. Sie erneuert die Hülle und lässt den bewährten Kern arbeiten.
Das heißt nicht, dass Neuentwicklung nie sinnvoll ist. Wenn die Fachlogik selbst überholt ist, kann sie der richtige Weg sein. Aber diese Entscheidung sollte man bewusst treffen, nicht aus Frust über unaufgeräumten Code.
Wie kommen Sie zu einer belastbaren Schätzung?
Bevor Sie irgendjemandem einen Termin nennen, beantworten Sie diese fünf Fragen für Ihr System:
- Gibt es automatisierte Tests, und für welche Teile?
- Welche PHP-Version läuft heute, und welche Composer-Pakete blockieren ein Update?
- Gibt es eine reproduzierbare Staging-Umgebung?
- Wie eng hängt die Anwendung an ihrem Framework oder an globalen Strukturen?
- Wie groß und wie kritisch sind die Datenbank-Migrationen?
Wer diese fünf Punkte ehrlich beantwortet, hat die grobe Größenordnung schon in der Hand. Wer sie überspringt, plant mit Wunschzahlen.
Wir haben genau diese Logik in eine Zeitschätzungs-Vorlage gegossen, mit der Sie die Faktoren für Ihr eigenes Projekt Punkt für Punkt durchgehen und eine realistische Spanne ableiten können.
Der ehrliche Praxis-Tipp
Wenn Sie nur eine Sache aus diesem Artikel mitnehmen: Investieren Sie zuerst in das Sicherheitsnetz, nicht in die Migration selbst. Ein paar Charakterisierungstests für Ihre kritischsten Pfade, geschrieben bevor Sie migrieren, machen die eigentliche PHP-Umstellung planbar und oft überraschend kurz. Ohne dieses Netz ist jede Zeitschätzung geraten, egal wer sie ausspricht.
Wenn Sie bei genau dieser Einordnung eine zweite, ehrliche Meinung möchten, ist das der Bereich, in dem wir bei LegacyWerk täglich unterwegs sind.
