Legacy modernisation one verified module at a time
AI agents map the code nobody understands, write the tests it never had and migrate it behind an API, while your engineers review every pull request and a parity gate proves nothing changed.
The system works, and that is exactly why nobody touches it
Every organisation has one: the application written years ago in a framework that is out of support, by people who have left, with business rules that exist only in the code. It processes orders or payroll reliably, so it survives. But every new feature, integration or security patch has to go around it, and the workaround pile grows.
The blocker is not writing new code. It is understanding the old code well enough to be sure the new code does the same thing. That understanding used to take months of reading. An agent can build the map in days and keep it current.
How it works
From unreadable codebase to migrated module
The legacy system stays live throughout. Each module is tested as it is, migrated, proven equivalent and switched at the gateway. The map and the documentation are regenerated as the code changes.
1. Map before you move
Using Claude Code against a clone of the repository, we produce a dependency graph, a dead-code list and a plain-language catalogue of the business rules buried in the code. Veterans correct it in a workshop.
2. Pin the behaviour down
The agent generates characterisation tests that record what each module does today, including the quirks. These tests become the contract the new code must honour.
3. Migrate behind a switch
Modules are translated or refactored one at a time, exposed as APIs and opened as pull requests. Engineers review; the parity gate runs; the gateway routes traffic to the new module.
What you get
Deliverables that outlive the engagement
Codebase map and rule catalogue
Dependencies, entry points, dead code and every business rule as a readable document, regenerated on each merge so it never goes stale again.
Characterisation test harness
A suite that captures current behaviour across normal and edge inputs, runnable in CI against both the old and the new implementation. Our AI QA and testing agent maintains it.
Migration plan in slices
A sequenced list of modules with risk, effort and dependencies, so you can fund one slice at a time and stop with a working system at any point.
API layer and integration
Legacy functions wrapped as documented APIs, and where useful an MCP server so AI tools can call them safely, following our AI integration and MCP server development practice.
Migrated modules, reviewed
Modern, tested code in the stack you choose, Laravel, Node.js, Swift, Kotlin or React, delivered as pull requests your team has read and approved.
Guardrails we build in
Accuracy thresholds: a migrated module ships only when it passes the full characterisation suite; any difference is a reviewed, documented decision rather than a surprise. Human-in-the-loop: the agent never merges, deploys or switches traffic; engineers review every pull request and the gateway change is a separate approval. Audit trail: each pull request links the rule catalogue entry, the tests and the reviewer, so an auditor can follow a business rule from old code to new. PII handling: production data never enters prompts; test fixtures are synthetic or masked, and secrets are scrubbed from clones before analysis. Tool and model provenance follow model supply chain security and the wider AI security and governance practice.
Typical rollout
First module in eight to twelve weeks
Map (2–3 weeks)
Repository access in your environment, automated codebase map, rule catalogue and dead-code report, validated in a workshop with the people who know the system.
Harness (2–3 weeks)
Characterisation tests for the first module, CI wiring so they run against the legacy code, and the slice plan with risks and sequencing agreed.
Migrate and verify (3–4 weeks)
The module is translated or refactored as reviewed pull requests, wrapped behind an API, and run in parallel until the parity gate is green.
Switch and repeat (1–2 weeks)
Traffic moved at the gateway with a rollback path, documentation regenerated, and the next slice started under the same harness.
Illustrative example
What a first release usually looks like
An illustrative scenario rather than a client case
A membership organisation runs its renewals and invoicing on a PHP application from the previous decade, maintained by one contractor. The map reveals three modules that nothing calls any more, a pricing rule nobody remembered that gives discounts to a category of member, and a tangled dependency between invoicing and the member directory. The team chooses invoicing as the first slice. Characterisation tests capture its behaviour, including the forgotten discount, which the finance lead decides to keep. The module is rebuilt in Laravel behind an API, runs in parallel for a billing cycle, and is switched once the outputs match. The directory module follows on the same harness. Nobody outside the project noticed the change, which was the point.
No. Big-bang rewrites fail because the old system keeps changing while the new one is built. We use the strangler pattern: the legacy system stays live, each module is wrapped behind an API, migrated, verified for identical behaviour and switched over. Users notice nothing until the last module moves.
Which legacy stacks can the agent read?
Any language with a text source: older PHP and Laravel versions, classic ASP.NET and VB, Java 6 to 8 era applications, Objective-C and early Swift, jQuery-era front ends and stored-procedure-heavy MySQL or SQL Server databases are the ones we meet most. Compiled binaries without source are out of scope.
How do you prove the new code behaves the same?
Characterisation tests. Before any change, the agent generates tests that record what the current code does for a wide set of inputs, including the odd cases. The migrated module must pass the same tests. Differences are reviewed by an engineer and either fixed or documented as intended changes.
Does our code leave our environment?
Only under terms you approve. We can run Claude Code against a repository clone inside your own cloud account or on a hardened workstation, with no training on your data and secrets scrubbed first. Model and tooling provenance is covered under model supply chain security.
How long does a modernisation take?
The first module takes eight to twelve weeks, including the codebase map and the test harness. Each subsequent module is faster because the harness and conventions exist. A full programme is scoped per module so you can stop at any point with a working system.
Talk to us about your AI project
Tell us what you are trying to do, which systems are involved and what is in the way. We reply within one business day with an opinion and a suggested next step.
