What AWS’s PHP-to-Java migration engine gets right, and what’s left to build

On 29 October 2026, AWS published a how-to and an open sample repository for a PHP-to-Java migration engine, built around a principle worth repeating: treat the original PHP application as the specification, and build the verification harness before writing the Java.

We agree with all four of their principles, because they describe how MigrateForge works:

• Discovery before translation. Inventory what exists before guessing at structure.
• Build the judge before the code. Define done before the first line of Java.
• Fix the loop, not the code. When the same mistake appears across files, amend the rules and regenerate rather than hand-patching.
• One shared brain. Write the methodology once, share it across projects, improve it with each migration.

That last one matters more than it sounds. On our own benchmarks, five of six recurring hand fixes became permanent engine rules, which is the difference between a migration tool and a consultant with a script.

Where the walkthrough stops

Their write-up is also candid about its limits, which is rarer than it should be. In the BookStack sample, four of thirty-seven models were ported as a read-only slice, and the parity harness for that slice was not built. They call that the single biggest gap. The repository’s Symfony example does include a request/response parity harness.

That gap is the work.

Describing a verification approach takes an afternoon. Building one takes weeks, and then it fails you repeatedly, which is the point. Ours has told us, on separate nights, that a wave we had called finished was only 88%, that a security check we claimed to catch reliably we did not, and that our own verification command was quietly rewriting the code it was supposed to be checking.

A harness that never contradicts you isn’t a harness.

What a judge has to compare

A request/response harness catches a surprising amount. It does not catch the two things that cost real money.

Database writes. On a public CodeIgniter application, our comparison caught a migrated delete that also removed the client’s invoices, quotes and payments. The HTTP response was identical. The redirect was identical. Only the database told the truth.

Outgoing calls. On a WhatsApp Business platform, a referral flow silently skipped a cashback payout and the message that went with it. Again, the page looked right.

So MigrateForge compares three things on every recorded journey: responses, database changes and outgoing API payloads. Cutover stays blocked until all three match.

What we publish alongside parity

Two numbers that most vendors would leave out.

Coverage. Parity means nothing without it. Behaviour never exercised is outside the claim, so every evidence report states what share of the recorded capture was actually compared.

How well the checker works. We plant deliberate bugs and count how many it catches. With a fixed set of planted sites, that is 57% on one benchmark and 36% on the other. Lost writes, changed outgoing payloads and missing escaping are caught reliably; edge values and some access-control patterns are not yet. We publish that because a verification engine claiming to catch everything is selling the same confidence a rewrite does.

Where we are

Four migrated waves across two applications: a production multi-tenant SaaS in plain PHP, and InvoicePlane, a public CodeIgniter invoicing application written by other developers. 858 recorded journeys, all matching, zero differences in data written or messages sent, zero high-severity findings in the generated code.

Both are benchmarks, not client projects. We say so on every page that mentions them. See the proof and compare pages for the published record.

The methodology is becoming consensus, and that’s good for everyone who has to modernise a PHP system. The harness is still the part someone has to build.

AWS, Kiro and AWS Transform are products of Amazon Web Services. We are not affiliated with or endorsed by AWS.