Rewrite your legacy system. Without betting the institution on it.
AI lets us document the whole system before we change a line, then rebuild it in small, verified steps and services keep running.
The cost of standing still is now higher than the cost of moving.
For two decades, modernisation was too expensive, too slow and too disruptive to start. The economics have changed.
Source: McKinsey & Company, AI for IT modernization: Faster, cheaper, better, December 2024.
Your legacy system is not the problem. The way it is rewritten usually is.
The failure is rarely technical. It is a failure of understanding: replacing a system before anyone can say, precisely, what it does today.
- 01Knowledge has left the building
The rules that matter most live in code written by people who have moved on. A rewrite from a requirements document quietly drops them.
- 02The big bang never lands
Multi-year replacements chase a business that keeps changing. By go-live, the new system is already behind.
- 03Two systems, double the cost
Running old and new in parallel for years is where budgets and patience run out.
- 04Risk is concentrated at the end
Everything is staked on one cut-over weekend, after all the money has been spent.
Not faster typing. A different order of work.
The breakthrough is not that AI writes code. It is that AI can read an entire codebase, which no team ever has the time to do. Paired with a structural map of the code, it recovers the business rules buried inside, and answers questions that once waited for the one person who remembered. Understanding stops being the bottleneck.
Read. Fence. Strangle. Transform. Retire.
Five disciplines, applied module by module. The institution never stops, and no step is taken that cannot be undone.
- 01
Read
AI reads the codebase, database and integrations into a knowledge graph, and extracts the business rules hidden inside.
- 02
Fence
Tests are written around current behaviour, so every later change is checked against reality, not memory.
- 03
Strangle
New services grow around the old core, one capability at a time, behind the same front door.
- 04
Transform
Code is refactored in small steps into idiomatic, modern code, then reviewed, tested and owned by our engineers.
- 05
Retire
Old modules are switched off only when the data matches and the new path has carried real load.
AI is a powerful instrument. It is not the strategy.
The programmes that succeed are not the ones that use the most AI. They are the ones that know exactly where it helps.
- 01Use AI where it adds
Understanding unfamiliar code, recovering business rules, explaining systems at every level, and drafting refactors at a scale no team could match.
- 02Use proven tools where they already work
Finding dead code, dependency analysis and security scanning are solved problems. Mature static and runtime analysis does them better, and we use it.
- 03Modernise for outcomes, not line counts
Not every module deserves to be rewritten. We map capabilities to business value first, then spend effort where it changes what the institution can do.
Wherever the past is holding back the mission.
- 01Monoliths
Large Java, .NET Framework and PHP applications that have become too risky to change.
- 02Spreadsheet and Access systems
Critical processes running on Excel macros, Access databases and shared drives.
- 03Ageing platforms
Unsupported CMS, CRM and ERP versions that block security updates and new features.
- 04On-premise estates
Servers in a cupboard, moved to a modern cloud with data kept in India.
- 05Programme MIS
Reporting systems built years ago for one programme, now asked to serve ten.
- 06Brittle integrations
Nightly file transfers and hand-built connectors, replaced with governed APIs.
Speed without recklessness.
Institutions cannot afford a modernisation that breaks payroll, payments or a public service. These rules are not negotiable on any engagement.
On every engagement
- Humans own every change — AI proposes; engineers decide. Nothing reaches production without review.
- Behaviour before beauty — we preserve what the system does today before we improve how it does it.
- Data parity, proven — old and new run side by side until the numbers match, record for record.
- Every step reversible — releases are small, and each can be rolled back in minutes.
- Secure by default — code stays in your environment. Personal data is handled under the DPDP Act.
Our own platform was the first patient.
Before we offered this to anyone, we modernised the platform that runs our own products. Commons CodeMill, our AI-assisted engineering practice, brings models from Anthropic, Google and OpenAI into the codebase alongside our engineers.
The change was not in how fast people typed. It was in what a small team could safely take on: work we once planned in quarters now moves in days.
Quick answers.
Only when it is treated like any other code: reviewed by engineers, covered by tests and released in small, reversible steps. That discipline, not the model, is what makes it safe.
Not necessarily. Sometimes the right answer is to modernise in place: add tests, document, refactor and upgrade. We recommend a new stack only where the old one is a genuine constraint.
No. We work inside your repositories and infrastructure, under your access controls, and use enterprise model agreements that do not train on your code.
The first map of your system arrives in weeks. Transformation then proceeds module by module, so value arrives continuously rather than at the end.
That is the intent. Your engineers work alongside ours, learn the practice, and own the system when we step back.
Modernise without stopping the institution.
Start with a map of the system you have. Decide what to do with it once you can see it whole.