Short answer: AWS published a worked example of a repeatable PHP-to-Java migration engine for the Kiro AI IDE. Everything is packaged as skill files and steering rules: a mechanical scanner first inventories the PHP models, a parity harness is built before any Java is written, and an eight-phase workflow then scaffolds and translates a Spring Boot port, with the original PHP treated as the specification. The same files can be handed to AWS Transform for portfolio-scale runs. The AWS Machine Learning blog post is unusually candid about its limits: the sample ported only 4 of 37 models and never built its parity harness.
TL;DR
| Question | Answer |
|---|---|
| What is it? | A skill-file methodology and scanner for PHP-to-Java migration in Kiro |
| Core rule | Discovery before translation: run the scanner before reading or translating models |
| How is correctness judged? | A parity harness comparing PHP and Java responses |
| Phases | Eight (0 to 8 counting preparation), human effort front-loaded in 0 to 3 |
| Targets | Spring Boot 3.4.1, Java 21, Maven, JPA, in-memory H2 in the sample |
| Frameworks detected | Laravel, Symfony, CodeIgniter, plain PHP |
| Interactive vs scale | Kiro one app at a time; AWS Transform many in parallel |
| Candid gap | 4 of 37 models ported; parity harness not built for the sample |
Why migrations go wrong
AWS opens with the real risk. A mature PHP app built with Laravel, Symfony or Doctrine carries business rules in non-obvious places, from Eloquent traits to XML mapping files. A structurally similar Java port can compile cleanly and still behave differently. The answer the post gives is to stop trusting that it looks right and to make behavior the measure.
The engine's three parts
AWS describes one principle, "one shared brain, many projects." A global .kiro/ layer holds two skills and a steering file, and each project folder holds its own PHP source, Java output and specification.
- Skill
php-model-discoveryis the scanner workflow. - Skill
php-to-java-migrationis the eight-phase playbook. - Steering file
core-workflow.mdcarries the standing instructions.
Because the knowledge lives in versioned Markdown files rather than inside one tool, every rulebook improvement benefits later projects. If you are new to the idea, see our guide to what agent skills are.
Rule one: discovery before translation
The most important rule fires first: do not read, guess at or hand-translate a model or entity file until the scanner has run.
The scanner, discover-models.php, is a single-file, dependency-free PHP command-line tool that does not execute the target code; it reads source text as tokens. It runs three strategies each time: Eloquent model discovery (walking the class chain to the base Model), Doctrine attribute detection (#[ORM\Entity]), and ORM XML mapping files. The output is one JSON manifest. A models[] array lists every field, cast, relationship and visibility rule, and a flags[] array carries ambiguities in plain English. For example, a $fillable list built from a runtime expression becomes a flag, and the flag list is the human review queue. The scanner flags uncertainty instead of guessing.
Rule two: build the judge first
Phase 1 builds the parity harness before Java exists. It replays request and response pairs against both the PHP original and the Java port. The harness must pass against working PHP and fail when you deliberately break it, because a harness that misses injected breakage cannot be trusted. This is essentially mutation testing applied to the test rig, and it is the idea most worth stealing.
The phases
A gear fading at sunset beside a green replacement gear, illustrating a PHP-to-Java migration with Kiro
| Phase | Name | Deliverable |
|---|---|---|
| 0 | Assess and discover | Model manifest, inventory, cutover choice |
| 1 | Build the judge | Parity harness runnable against PHP and Java |
| 2 | Rulebook and gap inventory | RULEBOOK.md, GAP_INVENTORY.md |
| 3 | Stress-test the rulebook | Hardened rulebook validated on representative files |
| 4 | Scaffold | Compiling Spring Boot project |
| 5 | Translate the data model | JPA entities and schema baseline |
| 6 | Translate the I/O layer | Controllers, security, templates respond |
| 7 | Convert business logic | Logic converted, tests green |
| 8 | Prove parity and cut over | Parity report and cutover checklist |
Phases 0 to 3 concentrate human expertise with approval gates: you review the discovery manifest, approve the rulebook, and sign off before the next phase. Phases 4 to 8 are mostly self-driving loops refereed by the harness. Two principles govern them. The PHP is the specification, so the port is done when the referee agrees or each mismatch is logged as an approved change. And you fix the loop, not the code: when the same mistake appears across files, amend the rulebook and regenerate instead of hand-patching.
The sample: Laravel Eloquent to Spring Boot
AWS's walkthrough migrates a read-only slice of an open-source Laravel application (Book, Chapter, Page and User models) to Spring Boot 3.4.1 on Java 21 with Maven and in-memory H2. The mappings are mechanical and traceable to the manifest:
- A PHP namespace becomes a Java package.
- An Eloquent model becomes a JPA
@Entity. hasManyandbelongsTobecome@OneToManyand@ManyToOne.- Eloquent query scopes become Spring Data repository methods.
- Fields listed in a model's
$hiddenget@JsonIgnore; in the sample thehtml,markdownandtextfields of Page are hidden, while Book's description deliberately is not.
The candid part
The post says plainly that only 4 of 37 models were ported and that the parity harness was never built for this slice, "the single biggest gap," and notes that documenting where it falls short is part of the design. That honesty is useful, and it also means the sample does not demonstrate the headline promise. It shows the structure of the method, not a measured parity result. Before using this for production work, expect to build the harness for your own app and to measure how many mismatches the loop finds.
Kiro versus AWS Transform
| Kiro | AWS Transform | |
|---|---|---|
| Mode | Interactive, developer in the loop | Agentic, autonomous with checkpoints |
| Scale | One application at a time | Many applications in parallel |
| Best for | First-of-a-kind frameworks, learning the output | Portfolios once the rulebook is stable |
| Shared | The same skill files | The same skill files |
AWS recommends starting in Kiro on one application, reading the generated Java and running the tests, then moving to AWS Transform for more. Rulebook fixes in either improve the other.
What to measure if you run it on a real app
A methodology is only as good as its evidence, so decide the scorecard before you start:
- Parity rate. The share of recorded request and response pairs where PHP and Java agree, tracked per phase. The sample never reached this stage, so this is the number you must produce.
- Approved differences. The log of mismatches you accept on purpose, such as a corrected bug. A long list is a warning sign.
- Rulebook churn. How many times the rulebook changed after Phase 3. Late changes mean the stress test was too gentle.
- Review flags resolved. How many scanner flags needed a human decision, and how many were resolved incorrectly and found later.
- Elapsed time and model cost per module, so you can forecast the rest of the portfolio.
The data the harness replays also matters. Recorded traffic from production covers real usage but can contain personal data, so scrub it first. Synthetic cases cover edge conditions that traffic never hits, such as rounding, time zones and character encodings, where PHP and Java differ in quiet ways. A good harness uses both.
How to try it
- Clone the sample repository linked from the post and open its root, the folder containing
.kiro/, as a Kiro workspace. - Install PHP 8.0 or newer for the scanner and Java 21 with Maven.
- Fetch your PHP source into the project's
source-php/folder. - Ask Kiro to migrate the application. The skill activates, runs the scanner first, generates a spec under
.kiro/specs/, and walks the approval gates. - No AWS resources are provisioned by the engine itself, so cleanup is stopping the app and deleting the generated folders and manifest.
How it compares with other skill-based workflows
The pattern here, a methodology encoded as skills plus steering, is the same one behind other agent toolkits we have covered, such as the AI-DLC workflows for Claude Code, Codex, Cursor and Kiro and the Superpowers skills framework. AWS also sets out its view of bounded autonomy in Trust in depth for agents, which fits the approval gates here.
Takeaways beyond PHP
AWS notes none of this is specific to PHP or Java. The transferable ideas are to inventory mechanically before generating, define done with a referee before writing code, and treat repeated errors as rulebook bugs. Any migration where the old system is the only complete specification can use the same shape. The risk to watch is trusting an AI-written harness that shares the same blind spots as the AI-written port, which is why breaking the code deliberately to check the harness matters.
Related reading
- What are agent skills? A complete guide
- AI-DLC workflows for Claude Code, Codex, Cursor and Kiro
- Superpowers: agentic skills framework
- AWS trust in depth for agent autonomy
- Agent plugins and the OpenAI standard across AWS, Cursor and GitHub
Sources: AWS Machine Learning blog, Kiro.
Details are as published by AWS on October 29, 2026 and may change.