Was die PHP-zu-Java-Migrations-Engine von AWS richtig macht – und was noch zu bauen bleibt

Am 29. Oktober 2026 hat AWS eine Anleitung und ein offenes Sample-Repository für eine PHP-zu-Java-Migrations-Engine veröffentlicht — gebaut um ein Prinzip, das es wert ist, wiederholt zu werden: die originale PHP-Anwendung als Spezifikation behandeln und den Verifikations-Harness bauen, bevor Java geschrieben wird.

Wir teilen alle vier ihrer Prinzipien, weil sie beschreiben, wie MigrateForge arbeitet:

• Discovery vor Übersetzung. Inventarisieren, was existiert, bevor man Struktur rät.
• Den Richter vor dem Code bauen. Fertig definieren, bevor die erste Zeile Java entsteht.
• Die Schleife reparieren, nicht den Code. Wenn derselbe Fehler über Dateien hinweg auftritt, Regeln ändern und neu generieren statt von Hand zu patchen.
• Ein gemeinsames Gehirn. Die Methodik einmal schreiben, über Projekte teilen, mit jeder Migration verbessern.

Das Letzte wiegt mehr, als es klingt. In unseren eigenen Benchmarks wurden fünf von sechs wiederkehrenden Handkorrekturen zu dauerhaften Engine-Regeln — der Unterschied zwischen einem Migrationswerkzeug und einem Berater mit Skript.

Wo der Walkthrough endet

Ihr Text ist auch ehrlich über die Grenzen, und das ist seltener, als es sein sollte. Im BookStack-Beispiel wurden vier von siebenunddreißig Modellen als schreibgeschützter Ausschnitt portiert, und der Paritäts-Harness für diesen Ausschnitt wurde nicht gebaut. Sie nennen das die größte Lücke. Das Symfony-Beispiel im Repository enthält einen Request/Response-Paritäts-Harness.

Diese Lücke ist die eigentliche Arbeit.

Einen Verifikationsansatz zu beschreiben dauert einen Nachmittag. Einen zu bauen dauert Wochen, und dann lässt er einen wiederholt durchfallen — das ist der Punkt. Unserer hat uns an verschiedenen Abenden gesagt, dass eine Welle, die wir für fertig hielten, nur 88 % war, dass eine Sicherheitsprüfung, die wir für zuverlässig hielten, es nicht war, und dass unser eigener Verifikationsbefehl still den Code umschrieb, den er prüfen sollte.

Ein Harness, der einem nie widerspricht, ist kein Harness.

Was ein Richter vergleichen muss

Ein Request/Response-Harness fängt überraschend viel. Er fängt nicht die zwei Dinge, die richtig Geld kosten.

Datenbankschreibvorgänge. Bei einer öffentlichen CodeIgniter-Anwendung hat unser Vergleich ein migriertes Löschen erwischt, das auch die Rechnungen, Angebote und Zahlungen des Kunden entfernte. Die HTTP-Antwort war identisch. Die Weiterleitung war identisch. Nur die Datenbank sagte die Wahrheit.

Ausgehende Aufrufe. Auf einer WhatsApp-Business-Plattform hat ein Referral-Flow still eine Cashback-Auszahlung und die zugehörige Nachricht übersprungen. Wieder sah die Seite richtig aus.

MigrateForge vergleicht deshalb auf jeder aufgezeichneten Reise drei Dinge: Antworten, Datenbankänderungen und ausgehende API-Payloads. Der Cutover bleibt blockiert, bis alle drei übereinstimmen.

Was wir neben Parität veröffentlichen

Zwei Zahlen, die die meisten Anbieter weglassen würden.

Coverage. Parität bedeutet ohne sie nichts. Nie ausgeübtes Verhalten liegt außerhalb des Anspruchs; jeder Evidenzbericht sagt deshalb, welcher Anteil der aufgezeichneten Capture tatsächlich verglichen wurde.

Wie gut der Checker funktioniert. Wir pflanzen absichtlich Bugs und zählen, wie viele er findet. Mit einem festen Satz gepflanzter Stellen sind das 57 % auf dem einen Benchmark und 36 % auf dem anderen. Verlorene Schreibvorgänge, geänderte ausgehende Payloads und fehlendes Escaping werden zuverlässig gefunden; Randwerte und manche Zugriffskontrollmuster noch nicht. Wir veröffentlichen das, weil eine Verifikations-Engine, die behauptet, alles zu fangen, dieselbe Zuversicht verkauft wie ein Rewrite.

Wo wir stehen

Vier migrierte Wellen über zwei Anwendungen: eine produktive Multi-Tenant-SaaS in Plain PHP und InvoicePlane, eine öffentliche CodeIgniter-Rechnungsanwendung von anderen Entwicklern. 858 aufgezeichnete Reisen, alle übereinstimmend, null Differenzen bei geschriebenen Daten oder gesendeten Nachrichten, null Findings hoher Schwere im generierten Code.

Beides sind Benchmarks, keine Kundenprojekte. Das sagen wir auf jeder Seite, die sie erwähnt. Den veröffentlichten Stand finden Sie unter Nachweis und Vergleich.

Die Methodik wird zum Konsens — und das ist gut für alle, die ein PHP-System modernisieren müssen. Der Harness ist immer noch der Teil, den jemand bauen muss.

AWS, Kiro und AWS Transform sind Produkte von Amazon Web Services. Wir sind nicht mit AWS verbunden und werden von AWS nicht empfohlen.