We presented MigrateX to a panel of AWS engineers, Capillary's CEO and CTO, and an external panelist from Razorpay. We didn't place in the top three.
Post-event, Capillary's entire legacy PHP surface was migrated to React using the same architecture.
The result you get on the day is one measure. Whether the architecture actually holds up against a real codebase is a different one entirely.
The problem that keeps getting deferred
Every team that inherits a PHP codebase has the same conversation.
Not now. We'll do it in phases. We're prioritising other things. There are more important projects.
What they mean is: there's no system that makes migration tractable. The retest cost is real, the regression risk is real, and without a repeatable process the decision to start is also the decision to absorb an enormous, open-ended cost.
PHP-to-React migration at scale has three compounding problems. The first is time: converting every template, every business logic block, every API contract is manual work that scales linearly with codebase size. The second is consistency: every engineer does it differently, which means no accumulated knowledge, no reusable patterns, no quality baseline. The third is validation: you need to verify that the migrated code is functionally equivalent to the original — same outputs, same edge cases, same behaviour under load — and doing that rigorously without automated tooling is expensive enough that most teams skip it or do it badly.
The result is that migration either doesn't happen, happens badly, or happens so slowly that the business doesn't notice any improvement.
The hackathon prompt was to build something using AWS's AI developer tooling. We decided to take the migration problem seriously.
48 hours, AWS-native stack
The constraints were fixed: 48 hours, team of four, AWS-native tooling stack. The AWS developer tooling stack at the time included Q Developer (AWS's developer-guided AI coding assistant), Bedrock (managed LLM APIs), and SageMaker (ML model deployment).
The first design question was how to use these tools together. Q Developer is designed for interactive, developer-in-the-loop work: a developer prompts, the model suggests, the developer refines. Bedrock is designed for bulk, automated workloads: you send a prompt programmatically and process the response downstream. These are two different interaction models, and they're good at different things.
The insight that shaped the architecture: PHP-to-React migration has both kinds of problems. Most pages — standard templates, straightforward data display, uncomplicated forms — are amenable to bulk automation. A model can look at a PHP template and produce a reasonable React component with high fidelity. But some logic — complex business rules, stateful workflows, domain-specific edge cases — benefits from developer guidance. Trying to automate everything degrades the hard cases. Trying to have a developer in the loop for everything defeats the purpose of automation.
The architecture uses both modes: Bedrock for bulk automated migration, Q Developer as an escape hatch for cases the automated path can't handle confidently. Four specialised agents, each with a defined scope.
The architecture: four agents, four layers
MigrateX is decomposed into four agents that operate in sequence across the migration pipeline.
Recorder Agent — the entry point. Before any code is transformed, you need to understand what the existing application actually does. The Recorder captures the PHP application's behaviour: DOM structure (static and dynamic), API calls, user interaction patterns. It also extracts mock data from the existing system — the inputs and expected outputs that the migrated system will need to reproduce. The goal is a complete behavioural specification of the source, not just its source code.
Context Builder Agent — the knowledge layer. Raw behavioural data isn't enough to guide transformation. The Context Builder constructs a knowledge graph: PHP code structure, UI component hierarchy, API dependencies, target stack mapping. It analyses what the PHP codebase is doing architecturally — which templates map to which components, what server-side logic should move to Node.js bridges versus what should become client-side state. The output is the migration context that the Transformation Agent operates against.
Transformation Agent — the core. This is where Bedrock runs. The agent takes each page in scope, maps the PHP template to a JSX equivalent, converts server-rendered logic to a Node.js bridge where needed, and generates the React component. For pages the model handles with high confidence, this is fully automated. For pages that exceed a complexity threshold — branching business logic, stateful server interactions, domain-specific rules — the agent routes to Q Developer mode, where a developer works through the transformation with AI assistance rather than fully automated output.
Verifier Agent — the quality gate. A migrated codebase that isn't verified is just a codebase that looks different. The Verifier runs four validation passes: functional equivalence (does the migrated code pass the test cases the Recorder extracted from the original?), UI fidelity (does the rendered output visually match the original within an acceptable threshold?), performance (are response times within bounds?), and security/compliance. The quality gates are defined upfront as success criteria, not checked after the fact.
What we built and what we showed
The demo to the judges was both slides and a live walkthrough. We ran the pipeline against a real PHP codebase — not a toy example — and walked through each agent stage: the Recorder capturing the existing application, the Context Builder constructing the migration graph, the Transformation Agent generating React components, the Verifier running validation passes.
The Recorder ran against Capillary's InTouch product — the real production UI, not a sandbox. The Chrome extension captured 73 DOM events across a 15-second session on the Brands catalog page.
From that recording, the full pipeline ran end-to-end: session data uploaded to S3, context built, React components generated, pull request created. All four stages completed in under two minutes.
The output wasn't a zip file or a code dump. It was a pull request, ready for review.
The coverage number from the demo: 90% of the PHP codebase migrated automatically by the Transformation Agent. The remaining 10% triggered the Q Developer fallback — complex business logic that the automated path flagged as needing developer review.
The quality gate targets, all demonstrated:
- Migration Coverage: 90%+ automated — achieved
- Functional Equivalence: 85%+ test pass rate
- UI Fidelity: 80%+ visual/behavioural match
- Migration Efficiency: 70%+ time reduction vs manual process
- Post-Migration Fix Rate: ≤10% manual corrections required after automated migration
The decision that the judges called out
We didn't design MigrateX as a PHP-to-React tool. We designed it as a migration framework that happens to target PHP and React in the first version.
The agent architecture — Recorder, Context Builder, Transformation, Verifier — doesn't have PHP or React hardcoded anywhere except in the specific model prompts the Transformation Agent uses. The Recorder captures behaviour from any web application. The Context Builder constructs a knowledge graph for any source and target pair. The Verifier runs equivalence checks against any migration output.
Changing the migration target from React to Vue, or from PHP to Python, is a matter of swapping the transformation prompts and target stack mappings. The pipeline stays the same.
This is the thing the judges specifically called out: the generalisability. The architecture isn't a PHP-to-React tool. It's a migration system with pluggable source and target adapters. That framing is what makes it interesting beyond the immediate use case.
What it doesn't solve
The 10% that routes to Q Developer is real. Complex business logic — deeply stateful server interactions, domain-specific rules that aren't expressed cleanly in the PHP, legacy authentication flows — doesn't respond well to bulk automation. The Q Developer path handles it, but it still requires engineering time. The system reduces that time materially, but it doesn't eliminate it.
The Verifier's 85% functional equivalence threshold is also a defined minimum, not a guarantee. Edge cases that weren't captured by the Recorder — unusual user flows, infrequently triggered states, environment-specific behaviour — won't be in the test set. The automated verification catches what the recording caught. What it didn't catch is still a manual responsibility.
The SageMaker layer — continuous learning from migration outcomes, improving pattern recognition over time — was designed into the architecture but partially implemented in the hackathon version. The migration pattern recognition model exists; the feedback loop that trains it on production outcomes was a post-hackathon item.
What happened after
We didn't place in the top three. The judges scored across the field and other submissions placed higher.
What happened after is a different story. The architecture was adopted internally at Capillary. Not as a pilot on a subset of pages. The entire legacy PHP surface — every page, every template, every server-rendered view that needed to move to React — went through the MigrateX pipeline.
That's the actual validation. A hackathon score tells you how a panel evaluated your work on the day against other submissions with different scopes and different tradeoffs. Production adoption tells you whether the architecture holds up against a real codebase under real constraints.
It held up.
The architecture that didn't win the hackathon migrated an entire production codebase. That's the version of the story that matters.
The framework exists. The coverage number is real. The generalisation — any source, any target — is what makes it useful beyond the specific migration it was designed for.
The architecture isn't a PHP-to-React tool. Swap the transformation prompts and target stack mappings, and it migrates anything to anything. That's the version worth building. Whether anyone does is a different question.