Legacy system modernisation
The system still works, nobody wants to touch it, and the person who wrote it left in 2019. We replace systems like that incrementally — without the rewrite that puts the business at risk.
Why the big rewrite keeps failing
The instinct is to rebuild from scratch. It is also the approach with the worst track record in the industry, and the reason is structural rather than technical.
The old system encodes years of accumulated business rules, most of them undocumented and many of them apparently irrational until you learn the specific incident that caused each one. A rewrite has to rediscover all of it while the original keeps changing, and the two diverge faster than the new one can catch up. Meanwhile no new features ship for eighteen months.
Incremental replacement avoids the trap. The old system keeps running while functionality moves across piece by piece behind a routing layer, and each piece is small enough that reverting it is a decision rather than a crisis.
How we approach it
Audit first
What the system does, what depends on it, where the risk actually sits, and what it is costing you to keep. Delivered as a written report you can act on with or without us.
Stabilise before changing
Backups verified by actually restoring them, monitoring added, the most urgent security issues closed. There is no point modernising something that might fall over next week.
Characterisation tests
Tests that capture what the system currently does — including behaviour that looks like a bug but that something downstream depends on. This is what makes changing it safe.
Strangle incrementally
A routing layer in front, then functionality moved across one capability at a time. Each move is independently reversible, and the old system shrinks until switching it off is uneventful.
Data migration in stages
Dual writes and reconciliation rather than a weekend cutover with a rollback plan nobody has rehearsed.
Documentation as you go
The business rules recovered during the work get written down. On most legacy projects this is the single most valuable artefact produced.
What we work with
Chosen per project, not by habit. If your team already runs something that works, we use it.
- Commonly inherited
- PHP
- legacy .NET
- Java
- classic ASP
- Visual Basic
- stored-procedure-heavy databases
- Migration targets
- TypeScript
- Python
- modern .NET
- containerised deployment
- Techniques
- strangler fig pattern
- anti-corruption layers
- characterisation testing
- dual writes
- Data
- schema migration tooling
- reconciliation jobs
- staged backfills
How a modernisation runs
It starts with an audit priced as a standalone piece of work, because deciding what to do is genuinely separate from doing it — and the honest answer is sometimes to leave the system alone.
- 01
Audit
Two to three weeks producing a written assessment: condition, risks, options and rough costs. Yours to keep and act on independently.
- 02
Stabilise
Backups, monitoring and urgent security fixes. Sometimes this is all that is needed, and we will say so.
- 03
Replace incrementally
Capability by capability behind a routing layer, each move reversible, with new features still shipping throughout.
- 04
Decommission
The old system switched off once nothing depends on it, with data archived to meet whatever retention you are subject to.
Common questions
Should we rewrite or modernise incrementally?
Incrementally, in almost every case where the system is still doing real work. Full rewrites are defensible when the system is small enough to rebuild in a couple of months, or when the platform underneath is genuinely at end of life with no upgrade path.
Nobody here understands the system. Can you still work on it?
Yes — that is the normal starting position. We read the code, trace the data, talk to the people who use it, and reconstruct the rules from behaviour. It is slower than having a knowledgeable owner, and we price for that honestly.
Can you work on it without disrupting operations?
That is the point of the incremental approach. Changes go out in small reversible pieces behind routing, so the blast radius of any single change stays small and business continues throughout.
What if the audit says leave it alone?
Then that is the report. A stable system that is unglamorous but working is often the correct answer, and modernising it would be spending your money to satisfy an aesthetic preference of ours.
How long does modernisation take?
Longer than a rewrite appears to on paper, and shorter than one actually takes. The difference that matters is that value arrives continuously rather than at the end, and you can stop at any point with the work done so far still useful.
Start with a scoping call.
Thirty minutes, no obligation. If we are not the right fit we will tell you on the call rather than after a proposal.
Related services
Custom software development
Web applications, internal tools, customer portals, APIs and mobile apps. Built by small senior teams in short…
API development & integrations
Connecting systems that were never designed to talk to each other — including the awkward ones with a SOAP end…
Cloud & DevOps
Migration without a big-bang cutover, infrastructure defined in code so environments are reproducible, and pip…