The system everyone's afraid to touch
Most organisations have one. Classic ASP, VB6, .NET Web Forms — a system that still runs the business but that nobody wants to change, because the people who built it have moved on and the cost of getting it wrong is measured in headlines.
It's too critical to retire and too fragile to touch, so it sits there quietly accruing risk while every plan to replace it dies at the same three words: too risky. The usual instinct is to wait until the case is overwhelming, then replace the whole thing at once. That instinct is the problem.
Why the big-bang rewrite keeps failing
A big-bang rewrite asks an organisation to fund years of work with nothing to show until the end, switch everything over on one weekend, and hope.
It concentrates all the risk into a single moment — the cutover — and hides all the learning until it's too late to act on cheaply. Most of these programmes don't fail loudly. They fail slowly: the budget half-spends, the scope drifts, the old system keeps running because nobody trusts the new one, and the whole thing is quietly shelved. The rewrite didn't reduce the risk. It postponed it and made it bigger.
Our approach, in three moves
We do the opposite. Instead of one large bet settled at the end, we make a series of small ones, each settled as we go.
Prove before you promise
The first thing we build is a working demonstration on your actual system — a modernised slice running against real data, in weeks, not a slide deck of projected benefits. It's the cheapest way to turn "too risky" into something leadership can see and judge for themselves.
Run old and new side by side
The modernised slice doesn't replace anything on day one. It runs alongside the legacy system — both serving real users, both reading the same data. There's no cutover weekend and no leap of faith: the old system stays as the safety net until the new one has earned its place.
Replace in slices
Functionality moves across a piece at a time, each slice delivering value on its own. Stop after any slice and you keep everything delivered so far. The system is modernised by the end not because of one heroic switch, but because the old one has been quietly, verifiably emptied out.
The patterns underneath
Two well-known patterns make this possible. This is the overview — each deserves a piece of its own.
The strangler fig
Named after the vine that grows around a tree until it can stand on its own, the strangler fig pattern grows the new system around the old one, routing more functionality to it over time until the legacy system can simply be removed. Nothing is thrown away until its replacement is proven.
The anti-corruption layer
Between old and new sits a translation layer that stops the legacy system's assumptions leaking into the new one. It's what lets both run on the same data without the new system inheriting the old one's compromises — and what makes each step reversible.
Keeping the risk visible, bounded and small
The whole method is really about one thing: the risk you're carrying at any given moment.
A big-bang rewrite keeps that risk invisible and lets it grow until cutover. Our approach keeps it in plain sight and small — every step is a slice you can inspect, and every step is reversible. At each point along the way you have:
- A working system in production, not a promise.
- The old system still there as a fallback.
- Something of stand-alone value you keep even if you stop.
Where AI actually helps
Legacy modernisation is mostly archaeology — reading undocumented code to work out what it really does before you can safely replace it.
That's exactly the kind of slow, careful work where guardrailed AI agents earn their place: they make the archaeology dramatically faster without being trusted to make the decisions. The engineers still own the judgement; the agents take the toil.
What this looks like for you
No big-bang, no lock-in, and a risk you can see the whole way through. In practice, the journey is:
- A free first conversation about the system and what it's costing you.
- A fixed-price proof of concept — a modernised slice on your real system, in weeks.
- Incremental delivery in stages of six weeks or less, each ending in working software you own.