AWS: a Kiro PHP-to-Java migration that builds the test first

AWS published a technical how-to on 29 October 2026 describing a repeatable way to migrate PHP applications to Java using Kiro, its AI development environment. The three AWS authors say the aim is to turn a rewrite from 'a one-time leap of faith' into a measurable process. The post is vendor-published and promotes Kiro and AWS Transform, so treat its design as a method to test, not a result.

The core idea: the old code is the spec

The post argues that a Laravel or Symfony codebase hides business rules in places such as Eloquent traits and XML mapping files, so a Java port can compile and still behave differently. Its answer is to treat the original PHP as the specification. The port is done only when a parity harness, which replays request and response pairs against both the PHP original and the Java port, agrees, or each mismatch is logged as an approved change.

Discovery before translation

A dependency-free PHP scanner reads source text as tokens, without executing the target code, and emits one JSON manifest of models, fields, casts and relationships. It uses three strategies: Eloquent model discovery, Doctrine attribute detection and ORM XML mapping files. Anything ambiguous, such as a fillable list built at runtime, goes to a flag queue for a person to resolve. The post's rule is that no one translates a model until the scanner has run.

Eight phases, with the judge first

Phase 0 runs the scanner. Phase 1 builds the parity harness before any Java exists, and the post says it must pass against working PHP and fail when the team breaks it on purpose, because a harness that misses injected breakage is not trusted. Phases 2 and 3 write and stress-test a rulebook and a gap inventory on representative files. Phases 4 to 8 scaffold a Spring Boot project, translate the data model, the controllers and the business logic, then prove parity and cut over. The authors say human judgement is concentrated in the first four phases and the rest mostly runs as loops.

Two principles govern the loops. The PHP is the specification, and the team 'fixes the loop, not the code': when a mistake repeats, they amend the rulebook and regenerate instead of editing output by hand. Approval gates sit at the discovery manifest, the rulebook and each phase.

What the sample shows, and what it does not

The sample project is a read-only slice of an open-source Laravel application. It migrates the Book, Chapter, Page and User models to Spring Boot 3.4.1 on Java 21 with an in-memory H2 database. The post states plainly 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'.

So the post demonstrates the discovery and translation steps, not the step it argues matters most. It gives no figures for elapsed time, cost, model used, defect rates or how many parity mismatches the method caught. Nothing in it compares the approach with a plain agent session or a human team.

What a team can take from it

The portable parts do not depend on Kiro: inventory the old system mechanically before the agent touches it, build and test the checker before the translation, and route repeated errors into shared rules. The post says the shape applies to other migrations where the old system is the only complete specification. The same skill files can also be handed to AWS Transform, which the post describes as running many applications in parallel, though it offers no evidence on that mode.