SERVICE

Legacy modernisation

Replacing a system that still works, without stopping it working.

What this actually is

Legacy modernisation is the work of replacing a system nobody wants to touch and nobody can turn off. It is rarely a technology problem — the technology is usually well understood — and almost always a sequencing and risk problem.

The failure mode is famous enough to have a name. A full rewrite is announced, runs long, and is abandoned with two systems to maintain instead of one. The alternative is strangling: new functionality alongside the old, traffic moved piece by piece, and the old system retired only when nothing depends on it.

What we do

Understand what it does
Including the behaviour nobody documented and somebody depends on. This is most of the risk and most of the first month.
Carve the seams
Finding boundaries where a piece can be replaced independently, which is what makes incremental replacement possible at all.
Build alongside
New services running in parallel with the old, taking a share of traffic while both are compared.
Migrate data
Usually the hardest part, because legacy data encodes decades of exceptions that the new schema has to accept.
Retire deliberately
Turning the old system off only when nothing calls it, verified by monitoring rather than by asking around.

The stack

Strangler-fig patternAPI gateways and anti-corruption layersChange data capturePython and TypeScriptPostgreSQLDocker and KubernetesContract testing

What it connects to

Integration surface is the honest driver of effort — ten systems is not ten times one system.

Mainframe and AS/400 interfaces
SOAP and legacy XML services
Batch file exchange — SFTP, fixed-width
Databases without a documented schema
Third-party systems built against the old API

How a project runs

Discovery

3–5 weeks

What it does, who depends on it, and where the seams are.

First slice

4–8 weeks

One capability replaced and serving live traffic behind a switch.

Migration waves

3–12 months

Capabilities moved in dependency order, each independently reversible.

Retirement

2–4 weeks

The old system decommissioned once monitoring shows nothing calls it.

Where teams use it

Financial services

Core systems where the rewrite risk is existential and downtime is not available.

Public sector

Systems of record with statutory obligations and long dependency chains.

Manufacturing

Bespoke software written for a plant by someone who left a decade ago.

Healthcare

Clinical systems where a migration error has patient-safety consequences.

Any acquisition

Two organisations with overlapping systems and no agreement on which survives.

When this is the wrong answer

If the system works and the cost of running it is tolerable, leaving it alone is a legitimate decision. Age is not a defect.

A full rewrite is the most expensive project in software and the one most likely to be abandoned. If someone is proposing one, the burden of proof is on them.

Undocumented behaviour is the real risk. Something depends on the bug you are about to fix, and finding out which is discovery work rather than optimism.

You will run both systems in parallel for a while, and that costs money. It belongs in the budget from the start rather than as a surprise in month four.

Frequently asked questions

Should we rewrite or refactor?

Almost always incremental replacement. A rewrite is defensible only when the platform is genuinely dead — unsupported hardware, a language nobody can hire for — and even then it happens piece by piece.

Nobody knows how it works. Is that a problem?

It is normal, and it is why discovery comes first. Behaviour is recoverable from the code, the data and the logs; what takes longer is finding who depends on the parts nobody mentions.

Can this happen without downtime?

For most capabilities, yes — parallel running and traffic shifting. Some data migrations need a window, and we identify which early rather than during the cutover.

How long does it take?

Longer than a rewrite estimate and considerably shorter than a rewrite. Discovery gives a real range; anything quoted before that is a guess about code nobody has read.

Who owns the code?

You do, from the first commit — work happens in your repository under your licence, and the contract assigns IP outright. We keep no rights and build no dependency that makes leaving expensive.

What does it cost?

We do not publish a number, because the honest one depends on scope, integrations and the accuracy bar. Tell us the budget you are working with and we will say what it buys — or say plainly if it does not buy enough.

Custom Software Development →Cloud Migration & Infrastructure →API Development & Integration →Hire engineers for this →