Die größten Risiken einer PHP-Migration – und wie man sie vermeidet

Eine PHP-Anwendung, die seit acht oder zwölf Jahren im Produktivbetrieb läuft, ist kein Sanierungsfall. Sie ist der Beweis, dass die Fachlogik funktioniert. Genau das geht in vielen Migrationsprojekten unter: Man behandelt das alte System wie Müll, den man wegwirft, statt wie ein Regelwerk, das über Jahre validiert wurde. Die eigentlichen PHP Migration Risiken entstehen nicht dort, wo die Software rechnet oder Bestellungen abwickelt. Sie entstehen im Code drumherum, in vergessenem Wissen und in falschen Annahmen über den Aufwand.

In diesem Artikel gehe ich die Risiken durch, die ich in der Praxis am häufigsten sehe, und wie Sie ihnen begegnen, bevor sie zu einem stehenden Shop oder einem gesprengten Budget werden.

Warum ist die komplette Neuentwicklung das größte PHP Migration Risiko?

Die Neuentwicklung auf der grünen Wiese ist in den meisten Fällen die teuerste und riskanteste Variante, weil sie jahrelang gewachsenes Fachwissen wegwirft und für lange Zeit kein lauffähiges System liefert. Der sogenannte "Big Bang Rewrite" klingt verlockend, weil der alte Code unschön ist. Aber der alte Code enthält tausende kleine Entscheidungen: Sonderfälle bei der Steuerberechnung, ein Rabatt für einen Altkunden, ein Umgang mit einer kaputten Datenquelle. Diese Regeln stehen nirgends dokumentiert. Sie stehen im Code.

Solange die Neuentwicklung läuft, muss das alte System weiter gepflegt werden. Sie zahlen also doppelt und bekommen über Monate keinen Mehrwert. Die ehrlichere Strategie ist fast immer die schrittweise Modernisierung: Das System bleibt lauffähig, Sie tauschen Teile aus, und jeder Schritt ist einzeln testbar und rückabwickelbar.

Wie gefährlich ist ein PHP-Versionssprung ohne Zwischenschritte?

Ein direkter Sprung von PHP 5.6 oder 7.x auf 8.x ohne Zwischenstufen ist riskant, weil sich Verhalten still ändert, ohne dass eine Fehlermeldung erscheint. Die harten Fehler wie entfernte Funktionen fallen sofort auf. Die gefährlichen Änderungen sind die stillen.

Konkrete Fallstricke beim Versionssprung:

• In PHP 8 werfen viele Warnungen jetzt eine TypeError-Exception statt weiterzulaufen. Code, der bisher "irgendwie" funktionierte, bricht.
• Der Vergleich 0 == "foo" ergibt seit PHP 8 false statt true. Wenn irgendwo lose Vergleiche in einer Berechtigungsprüfung stecken, ändert sich das Verhalten schlagartig.
• Änderungen bei der Sortierstabilität und beim Umgang mit numerischen Strings betreffen genau die Stellen, die niemand testet.

Der Weg dahin: In sinnvollen Schritten migrieren, zum Beispiel 7.4 als Zwischenstufe. Werkzeuge wie PHPCompatibility für PHP_CodeSniffer und Rector finden einen großen Teil der Problemstellen automatisch, ersetzen aber keinen Testlauf gegen echte Daten.

Warum sind fehlende Tests das eigentliche Kernrisiko?

Ohne automatisierte Tests haben Sie keine Möglichkeit zu beweisen, dass sich das Verhalten nach der Migration nicht verändert hat. Genau das ist bei Legacy-Anwendungen die Regel: Es gibt keine oder kaum Tests. Jede Änderung wird damit zum Blindflug.

Der Fehler ist, für alten Code erst mühsam Unit-Tests schreiben zu wollen. Legacy-Code ist oft so verwoben, dass Unit-Tests kaum möglich sind. Wirksamer sind sogenannte Characterization Tests: Sie zeichnen das aktuelle Verhalten des Systems auf, ohne zu bewerten, ob es korrekt ist. Sie schießen einen definierten Satz Eingaben durch das System und speichern die Ausgaben als Referenz. Nach jeder Migrationsstufe laufen dieselben Eingaben erneut. Weicht die Ausgabe ab, haben Sie eine Regression gefunden, bevor der Kunde sie findet.

Welche Rolle spielt die Datenbank bei PHP Migration Risiken?

Die Datenbank ist häufig das am meisten unterschätzte Risiko, weil Verhalten wie Zeichensätze, Sortierung und implizite Typkonvertierung mitmigriert werden muss und nicht nur der PHP-Code. Ich sehe regelmäßig, dass der Anwendungscode sauber portiert wird, aber die Umgebung darunter kippt.

Typische Stolperstellen:

• Zeichensatz: Ein Wechsel von latin1 oder utf8 (das in MySQL nur 3 Byte kann) auf utf8mb4 ist notwendig für Emojis und viele Sonderzeichen, kann aber bestehende Daten beschädigen, wenn er unsauber ausgeführt wird.
• Strict Mode: Neuere MySQL- und MariaDB-Versionen laufen standardmäßig im strengen Modus. Ein zu langer String wird dann abgewiesen statt stillschweigend abgeschnitten. Das ist korrekter, bricht aber Code, der sich auf das alte Verhalten verließ.
• Ungültige Datumswerte wie 0000-00-00 werden in neueren Versionen nicht mehr akzeptiert.

Testen Sie die Migration immer gegen eine vollständige Kopie der Produktionsdaten, niemals nur gegen ein sauberes Testschema. Die kaputten Datensätze aus zwölf Jahren Betrieb sind es, die Sie finden müssen.

Wie verhindert man, dass alte Sicherheitslücken mitwandern?

Eine Migration ist der richtige Zeitpunkt, um Sicherheitslücken zu schließen, aber nur wenn man sie aktiv sucht und nicht blind alten Code kopiert. Legacy-Anwendungen tragen oft Muster in sich, die zum Entstehungszeitpunkt üblich waren und heute gefährlich sind.

Worauf Sie achten sollten:

• Direkt zusammengesetzte SQL-Strings statt vorbereiteter Statements (SQL-Injection).
• Passwörter, die mit md5 oder sha1 gehasht sind, statt mit password_hash(). Diese lassen sich beim nächsten Login des Nutzers transparent auf ein sicheres Verfahren umstellen.
• Veraltete Abhängigkeiten. Ein composer audit zeigt bekannte Schwachstellen in eingebundenen Paketen.

Wichtig ist die Reihenfolge: Erst die Migration verhaltensgleich abschließen, dann gezielt härten. Wer beides gleichzeitig macht, weiß bei einem Fehler nicht mehr, ob die Migration oder die Sicherheitsänderung schuld ist.

Warum scheitern Migrationen oft an Menschen, nicht an Technik?

Der häufigste nicht-technische Grund für gescheiterte Migrationen ist, dass das Wissen über das System nur in wenigen Köpfen steckt und dieses Wissen nicht rechtzeitig gesichert wird. Wenn die eine Person, die weiß, warum der nächtliche Cronjob genau um 3:17 Uhr läuft, im Urlaub ist, steht das Projekt.

Praktisch heißt das: Dokumentieren Sie während der Migration, nicht danach. Halten Sie fest, welche externen Schnittstellen es gibt, welche Cronjobs laufen, welche Sonderfälle bekannt sind. Und planen Sie einen Rückweg ein. Jede Migrationsstufe muss zurückrollbar sein, im Zweifel per Feature-Flag, das die alte und die neue Codepfad-Variante umschaltet.

Ein ehrlicher Praxis-Tipp zum Schluss

Wenn Sie nur eine Sache mitnehmen: Migrieren Sie in kleinen, einzeln überprüfbaren Schritten und sichern Sie vorher das aktuelle Verhalten ab, statt es zu erraten. Das ist langweiliger als ein Neustart auf der grünen Wiese, aber es ist die Variante, bei der Ihr Shop am Montagmorgen noch Bestellungen annimmt. Und seien Sie ehrlich zu sich: Nicht jedes System muss migriert werden. Manchmal reicht es, die Umgebung zu aktualisieren und drei konkrete Schwachstellen zu beheben.

Genau bei dieser Abwägung und der schrittweisen Umsetzung unterstütze ich mit LegacyWerk, wenn Sie einen zweiten Blick von jemandem wollen, der solche Systeme kennt.