AWS: build the parity test before the Java in a Kiro PHP migration

AWS published a how-to on 29 October 2026 describing a repeatable way to migrate a mature PHP application to Java using Kiro, its AI IDE (integrated development environment). The authors, Sarat Guttikonda, Pallavi Jha and Phani Parcha, argue that a Java port can compile cleanly and still behave differently, because business rules in Laravel, Symfony and Doctrine codebases sit in places such as Eloquent traits and XML mapping files.

The method: PHP is the spec, the harness is the judge

The authors say the engine rests on two rules. The PHP code is the specification, so the port is finished only when a parity harness agrees or each mismatch is logged as an approved change. And you fix the loop, not the code: when the same mistake recurs, amend the rulebook and regenerate rather than patching by hand.

Everything lives in skill files, versioned Markdown packages for Kiro. The post says the same files can be handed to AWS Transform, its agentic migration service, to run across many applications in parallel, while Kiro handles one application at a time with approval gates.

Eight phases, human effort up front

• Phase 0: a scanner inventories every model, field, cast and relationship. It reads source text only and does not execute the code.
• Phase 1: build the parity harness, replaying request and response pairs against both the PHP and the Java. The authors say it must pass on working PHP and fail when broken on purpose, because a harness that misses injected breakage is not trusted.
• Phases 2 and 3: write a rulebook and gap inventory, then stress-test them on representative files.
• Phases 4 to 8: scaffold, translate the data model, the I/O layer and the business logic, then prove parity and cut over. The post calls these mostly self-driving loops.

Ambiguity goes to a person. The scanner raises a plain-English flag, for example when a $fillable list is built from a runtime expression, and that flag list becomes the review queue.

What the sample did and did not show

The worked example is a read-only slice of an open-source Laravel app, migrated to Spring Boot 3.4.1 on Java 21 with an in-memory H2 database. It covers the Book, Chapter, Page and User models. The mapping is described as mechanical: an Eloquent model becomes a JPA entity, and fields in Page's $hidden list become @JsonIgnore.

The post is candid that only 4 of 37 models were ported and that the parity harness was never built for this slice, which it calls the single biggest gap. In other words, the one control the method depends on is absent from its own demonstration.

What the post leaves out

• No timings, token or cloud costs, or defect counts from a real migration are given.
• No customer migration is described; the evidence is one small, read-only sample.
• How well the parity harness catches subtle behaviour changes in a large application is not measured.
• Which model Kiro uses is not stated in the post.

For a team with an ageing PHP system, the portable idea is the ordering: decide how you will prove equivalence before any code is generated, and test that the proof can fail. The tooling claims are AWS's own and unmeasured here.