PHP 7 auf PHP 8 migrieren lassen: Aufwand, Kosten und Risiken

Irgendwann kommt die Mail vom Hoster: PHP 7.4 wird abgeschaltet, bitte stellen Sie Ihre Anwendung um. Oder der Wirtschaftsprüfer fragt im Rahmen der IT-Prüfung nach dem Patchstand. Oder ein Kunde schickt einen Sicherheitsfragebogen, den Sie mit der aktuellen Konstellation nicht ehrlich ausfüllen können. In allen drei Fällen steht dieselbe Frage im Raum: Was kostet es, eine gewachsene PHP-Anwendung auf PHP 8 zu heben, wie lange dauert das und was kann dabei schiefgehen? Dieser Beitrag beantwortet genau das, ohne Marketingversprechen und ohne Pauschalpreise, die im Ernstfall nicht halten.

Warum ist die Umstellung auf PHP 8 jetzt dringend?

Weil für PHP 7 seit Jahren keine Sicherheitsupdates mehr erscheinen. PHP 7.4 hat den Support für Sicherheitskorrekturen im November 2022 verloren, PHP 8.0 folgte im November 2023. Für PHP 8.1 lief die reine Sicherheitsunterstützung nach dem offiziellen Zeitplan bis Ende 2025 aus. Die verbindliche Übersicht steht auf php.net unter "Supported Versions", und wir empfehlen ausdrücklich, dort den tagesaktuellen Stand nachzusehen, bevor Sie ein Zielversion festlegen.

Das Ende des Supports ist keine Formalie. Es bedeutet: Wird morgen eine Schwachstelle im PHP-Kern gefunden, gibt es für Ihre Version keinen Patch mehr. Sie können dann nur noch die Anwendung abschalten, den Zugriff einschränken oder unter Zeitdruck migrieren, also genau das tun, was Sie mit einem geplanten Projekt vermeiden wollten.

Drei weitere Treiber kommen in der Praxis hinzu:

• Hoster ziehen die alten Versionen ein. Managed-Hosting-Anbieter halten veraltete PHP-Versionen nicht unbegrenzt vor. Wenn die Abkündigung kommt, haben Sie meist wenige Wochen Vorlauf.
• Compliance und Nachweispflichten. Die DSGVO fordert in Artikel 32 Maßnahmen nach dem "Stand der Technik". Eine Laufzeitumgebung ohne Sicherheitspflege ist in einer Prüfung schwer zu verteidigen. Wer Kartenzahlungen verarbeitet, findet in den PCI-DSS-Anforderungen eine noch deutlichere Formulierung zum Patchmanagement.
• Der Aufwand wächst mit jedem Jahr. Je länger Sie warten, desto mehr Versionssprünge liegen zwischen Ihrem Stand und der aktuellen Zielversion, und desto größer wird die Zahl der Bibliotheken, die zwischenzeitlich selbst eingestellt wurden.

Der Umkehrschluss lautet nicht, dass Sie panisch reagieren müssen. Er lautet, dass die Umstellung ein planbares Projekt mit klarem Umfang ist, solange Sie es aktiv anstoßen und nicht auf einen Vorfall warten.

Was bricht beim Wechsel von PHP 7 auf PHP 8 wirklich?

PHP 8 ist strenger als PHP 7. Vieles, was früher eine Warnung war und im Hintergrund weiterlief, ist heute ein Fehler, der die Ausführung abbricht. Genau daraus entsteht der Migrationsaufwand: nicht aus einer Handvoll spektakulärer Umbauten, sondern aus vielen kleinen Stellen im Code, die jahrelang unbemerkt am Rand der Regeln gearbeitet haben.

Die Punkte, die uns in Bestandsanwendungen am häufigsten begegnen:

• Entfernte Funktionen und Erweiterungen. each() und create_function() sind gestrichen, die alte mysql_*-Erweiterung ist seit PHP 7 verschwunden. Anwendungen, die noch mit mysql_query() arbeiten, brauchen zwingend eine Umstellung auf mysqli oder PDO.
• Strengere Typprüfung. Interne Funktionen werfen bei unpassenden Datentypen jetzt eine TypeError-Ausnahme, statt still null zurückzugeben. Das deckt echte Fehler auf, bringt aber zunächst Seiten zum Stehen, die vorher scheinbar funktioniert haben.
• Vergleiche zwischen Zeichenketten und Zahlen. PHP 8 hat die Regeln geändert. Der berühmte Fall, dass 0 == "irgendein Text" als wahr galt, ist Geschichte. In Anwendungen mit vielen losen Vergleichen kann das Rechte, Filter oder Preislogik verändern, ohne dass eine Fehlermeldung erscheint. Das ist die Kategorie von Änderung, die Tests braucht.
• Warnungen werden zu Fehlern. Der Zugriff auf einen nicht vorhandenen Array-Schlüssel oder auf eine undefinierte Variable wird deutlich lauter gemeldet. In produktiven Systemen mit unterdrückter Fehleranzeige fällt so etwas vorher nie auf.
• Benannte Argumente ändern die Regeln für Parameternamen. Seit PHP 8 sind Parameternamen Teil der öffentlichen Schnittstelle einer Funktion. Wer Bibliotheken erweitert oder Methoden überschreibt, muss das berücksichtigen.
• Alte Frameworks laufen nicht mit. Symfony 3 und 4, Laravel 5, Zend Framework 1 oder CodeIgniter 2 sind nicht für PHP 8 gebaut. In diesen Fällen ist die PHP-Migration untrennbar mit einem Framework-Upgrade verbunden, und das ist meist der größere Teil der Arbeit.
• Composer-Pakete ohne PHP-8-Unterstützung. Jedes Paket, dessen Pflege eingestellt wurde, ist eine eigene Entscheidung: ersetzen, selbst weiterpflegen oder die Funktion neu bauen. Das gilt genauso für WordPress-Installationen mit Plugins, die seit Jahren kein Update mehr gesehen haben.

Die gute Nachricht: Der überwiegende Teil dieser Fundstellen ist mechanisch. Es sind viele kleine, gut verstehbare Änderungen. Die Kunst liegt darin, sie vollständig zu finden, bevor sie ein Anwender findet.

Wie läuft eine PHP-8-Migration in fünf Schritten ab?

Eine saubere Migration folgt immer demselben Ablauf: erst messen, dann Abhängigkeiten klären, dann parallel aufbauen, dann in kleinen Sprüngen umstellen, dann absichern. Wer diese Reihenfolge umdreht und einfach die PHP-Version auf dem Server hochsetzt, produziert einen Ausfall.

1. Bestandsaufnahme mit Werkzeugen statt Bauchgefühl. Der Code wird statisch analysiert, bevor irgendetwas angefasst wird. PHPCompatibility zeigt versionsspezifische Inkompatibilitäten, PHPStan deckt Typprobleme und toten Code auf, Rector kann einen großen Teil der Anpassungen automatisiert vorschlagen und durchführen. Das Ergebnis ist eine zählbare Liste von Fundstellen, aus der sich ein Aufwand ableiten lässt.
2. Abhängigkeiten inventarisieren. Welche Composer-Pakete sind im Einsatz, welche davon unterstützen PHP 8, welche werden nicht mehr gepflegt? Dazu kommen PHP-Erweiterungen auf dem Server, Datenbanktreiber, Cron-Jobs, Schnittstellen zu Fremdsystemen und die Frage, ob die eingesetzte MySQL- oder MariaDB-Version zum Zielstand passt.
3. Testumgebung mit PHP 8 parallel aufbauen. Die Migration wird nie am Produktivsystem entwickelt. Es entsteht eine zweite, möglichst identische Umgebung mit der Zielversion, in der die Anwendung umgestellt und geprüft wird. Wie eine solche Umgebung abgesichert gehört, beschreiben wir in unserem Beitrag zu den PHP-Sicherheitseinstellungen für die Produktivumgebung.
4. Schrittweise umstellen statt in einem Sprung. Der Weg führt von 7.4 über 8.0 und 8.1 auf 8.2 oder 8.3. Jede Stufe bringt eigene Änderungen mit, und wer sie einzeln nimmt, weiß nach einem Fehler sofort, welche Stufe ihn verursacht hat. Bei Anwendungen mit Framework wird das Framework-Upgrade in diesen Ablauf eingeflochten, weil beide Themen voneinander abhängen.
5. Regressionstests und Monitoring nach dem Go-live. Vor der Umstellung werden die geschäftskritischen Abläufe durchgespielt: Bestellung, Rechnung, Login, Export, Zahlungsschnittstelle. Nach der Umstellung läuft für einige Wochen ein aufmerksames Fehler-Logging mit, weil die stillen Änderungen bei Vergleichen und Zahlenformaten erst im echten Datenverkehr sichtbar werden.

Ein wichtiger Zwischenschritt wird oft vergessen: der Rückweg. Vor dem Go-live steht fest, wie innerhalb weniger Minuten auf den alten Stand zurückgeschaltet wird, falls etwas Grundlegendes nicht funktioniert. Ohne diesen Plan wird aus einem kleinen Problem ein langer Ausfall.

Was kostet die Migration von PHP 7 auf PHP 8?

Als Erfahrungswert: Eine kleine Anwendung ohne Framework ist in wenigen Tagen umgestellt, eine mittlere Anwendung mit veraltetem Framework braucht zwei bis sechs Wochen inklusive Framework-Upgrade, ein großes Altsystem mit mehreren Modulen und Schnittstellen bewegt sich im Bereich von Monaten. Diese Spannen beruhen auf Projekten, die wir gesehen haben, nicht auf einer Formel. Belastbar wird die Zahl erst nach der Bestandsaufnahme aus Schritt eins, und genau deshalb steht diese Analyse am Anfang und nicht das Angebot.

Vier Faktoren bestimmen den Aufwand stärker als die reine Codemenge:

• Gibt es automatisierte Tests? Ohne Tests muss jede Funktion manuell geprüft werden. Das ist häufig der größte Einzelposten.
• Wie alt ist das Framework? Ein Sprung von Symfony 4 auf 6 ist ein eigenes Projekt neben der PHP-Version.
• Wie viele Fremdanbindungen existieren? Jede Schnittstelle zu Warenwirtschaft, Zahlungsdienstleister oder Versanddienst muss nach der Umstellung nachgewiesen funktionieren.
• Wie sauber ist der Betrieb? Versionsverwaltung, ein reproduzierbares Deployment und eine dokumentierte Serverkonfiguration sparen Tage. Fehlen sie, entsteht zuerst Aufwand für das Herstellen dieser Grundlagen.

Für sehr große Systeme ist die Umstellung in einem Rutsch selten sinnvoll. Dort arbeiten wir mit dem Strangler-Ansatz, bei dem das Altsystem produktiv bleibt und Stück für Stück durch neue Komponenten ersetzt wird. Wie dieses Vorgehen im Detail funktioniert, haben wir im Beitrag zum Thema Legacy-Systeme warten und modernisieren beschrieben. Unsere Stundensätze und Wartungsmodelle finden Sie auf der Seite Preise.

Welche Risiken gibt es und wie begrenzt man sie?

Das größte Risiko einer PHP-Migration ist nicht die neue PHP-Version, sondern fehlendes Wissen über den Bestand. Wenn niemand mehr sagen kann, was die Anwendung im Detail tut, welche Cron-Jobs laufen und wo überall Sonderfälle einprogrammiert wurden, dann ist jede Änderung ein Blindflug.

Wenn der ursprüngliche Entwickler nicht mehr erreichbar ist, geht der Übernahme der Anwendung ein eigener kleiner Schritt voraus. Was dabei zu klären ist, von Zugangsdaten über Domains bis zu Lizenzen, haben wir in unserem Beitrag dazu zusammengefasst, wie Sie Software übernehmen lassen, wenn der Entwickler nicht mehr erreichbar ist.

Migration oder Neubau: Wann lohnt sich was?

Als Faustregel gilt: Solange die Fachlogik der Anwendung noch zum Geschäft passt, ist die Migration fast immer die günstigere Entscheidung. Ein Neubau lohnt sich erst, wenn die Anwendung inhaltlich nicht mehr das tut, was der Betrieb heute braucht.

Für die Migration spricht, wenn die Abläufe im Kern stimmen, die Anwendung täglich genutzt wird und die Änderungen sich auf technische Anpassungen beschränken. Ein Neubau ist zu erwägen, wenn ohnehin ganze Prozesse neu gedacht werden müssen, wenn wesentliche Teile durch Standardsoftware ersetzbar sind oder wenn der Aufwand für die Migration in die Nähe eines Neubaus kommt, ohne dass sich fachlich etwas verbessert.

In der Praxis ist der dritte Weg der häufigste: Migration jetzt, Modernisierung in Etappen danach. Die Anwendung läuft zuerst wieder auf einer gepflegten Laufzeitumgebung, das akute Sicherheitsthema ist vom Tisch, und die inhaltliche Weiterentwicklung wird in ein Budget mit ruhigerem Zeitplan verschoben. Was das langfristig für Ihre Wartungskosten bedeutet, beleuchten wir im Beitrag zu Softwarewartung und technischen Schulden.

Was sollten Sie vor dem ersten Gespräch vorbereiten?

Für eine erste Einschätzung brauchen wir keine Dokumentation und kein Lastenheft. Sechs Angaben genügen, und die meisten davon kann Ihr Hoster oder Ihr Administrator innerhalb einer Stunde beantworten.

• Welche PHP-Version läuft aktuell, und welche Versionen bietet Ihr Hoster an?
• Gibt es ein Framework, und wenn ja, welche Version? Ein Blick in die Datei composer.json reicht meist.
• Gibt es ein Git-Repository oder liegt der Code nur auf dem Server?
• Wer hat die Anwendung gebaut, und ist diese Person noch erreichbar?
• Welche Abläufe dürfen auf keinen Fall ausfallen, und gibt es Zeiträume, in denen ein Wartungsfenster möglich ist?
• Welche Fremdsysteme sind angebunden, etwa Zahlungsdienstleister, Warenwirtschaft, Versand oder Buchhaltung?

Auf dieser Basis lässt sich bereits sagen, in welche Größenordnung Ihr Fall fällt und ob es sinnvoll ist, mit einer kostenpflichtigen Analyse zu beginnen oder direkt in die Umsetzung zu gehen. Wenn Sie ohnehin gerade Ihre Absicherung prüfen, hilft ergänzend unsere Checkliste zur IT-Sicherheit für KMU.

Häufige Fragen zur PHP-8-Migration

Kann ich einfach die PHP-Version beim Hoster umstellen und schauen, was passiert?
Technisch ja, betrieblich nein. Bei einer produktiven Anwendung führt das mit hoher Wahrscheinlichkeit zu Fehlerseiten und im schlimmsten Fall zu fehlerhaften Daten, weil sich manche Änderungen nicht durch Abstürze zeigen, sondern durch stille Verhaltensänderungen. Der Test gehört in eine Kopie der Umgebung, nicht in den Livebetrieb.

Auf welche PHP-Version sollten wir migrieren?
Auf eine Version, die zum Zeitpunkt der Umstellung noch aktive Unterstützung hat, in der Regel also nicht auf die allerneueste und nicht auf die älteste noch unterstützte. Prüfen Sie die Tabelle "Supported Versions" auf php.net und wählen Sie so, dass Sie nach dem Projekt mindestens zwei Jahre Ruhe haben.

Muss unser Framework mit umgestellt werden?
Wenn es sich um Symfony 3 oder 4, Laravel 5 oder eine ähnlich alte Version handelt, ja. Diese Versionen sind nicht mit PHP 8 lauffähig. Das Framework-Upgrade ist dann meist der größere Teil des Aufwands, und beide Themen werden gemeinsam geplant, weil sie voneinander abhängen.

Wie lange ist die Anwendung während der Umstellung nicht verfügbar?
Die eigentliche Umschaltung dauert in der Regel Minuten bis wenige Stunden und wird in ein Wartungsfenster gelegt, oft am Wochenende oder in der Nacht. Die vorangehende Arbeit findet in der Testumgebung statt, ohne dass der Livebetrieb betroffen ist.

Was passiert nach der Migration, damit wir nicht in fünf Jahren wieder hier stehen?
Genau das ist der Sinn eines Wartungsvertrags: regelmäßige Updates von PHP, Framework und Bibliotheken in kleinen Schritten statt in einem großen Sprung. Was dazu gehört, beschreibt unser Leitfaden zur Softwarewartung. Den laufenden Betrieb inklusive Serverpflege übernehmen wir auf Wunsch im Rahmen der Hosting-Betreuung.

Fazit

Eine Anwendung auf PHP 7 zu betreiben heißt, ohne Sicherheitsupdates zu arbeiten. Das ist weniger eine technische als eine unternehmerische Entscheidung, und sie wird mit jedem Monat teurer, weil der Abstand zur aktuellen Version wächst und die Zahl der nicht mehr gepflegten Abhängigkeiten zunimmt. Die Umstellung selbst ist gut planbar: Bestandsaufnahme, Abhängigkeiten klären, Testumgebung, schrittweise Versionssprünge, Regressionstests und Monitoring. Der Aufwand reicht von wenigen Tagen bei kleinen Anwendungen bis zu Monaten bei großen Altsystemen, die man sinnvollerweise in Etappen ablöst.

Wenn Sie wissen möchten, wo Ihr System steht: Schicken Sie uns die PHP-Version, das Framework samt Version und eine kurze Beschreibung, was die Anwendung tut. Wir sagen Ihnen ehrlich, ob das ein Projekt von Tagen, Wochen oder Monaten ist, und ob eine Migration oder eine schrittweise Ablösung der bessere Weg für Sie ist. Vereinbaren Sie dazu ein kostenloses Erstgespräch oder schreiben Sie uns über das Kontaktformular.