A twenty-year-old core system supports most of the business. It is on unsupported technology, three people understand it, and the last replacement attempt was abandoned after two years. Design the programme.

Learn from the abandoned attempt first

The most important input is why the last one failed, and the reasons are usually structural rather than technical: a big-bang rewrite that never reached parity; funding withdrawn when a multi-year programme showed no interim value; feature parity as a moving target because the old system kept changing; or the knowledge in the old code rediscovered painfully in production.

A second attempt with the same shape will fail the same way. Say so explicitly, because the organisation's appetite for this is finite and probably already low.

Assess on evidence, not reputation

Business value — which capabilities, how critical, what revenue depends on them. Technical condition — change lead time, change failure rate, incident frequency, support status. Integration surface, discovered from network flow logs and database audit rather than documentation, which will be wrong. Data — volume, quality and retention obligations. Knowledge risk, which here is the binding constraint.

Address the knowledge risk immediately, before anything else

Three people is a programme-ending risk and a scheduling risk that is rarely on a register. It is also the cheapest thing to act on.

Pair them with others now. Record how the system works — a captured conversation is worth more than a document nobody writes. Prioritise capturing the undocumented behaviour, which is what the last attempt failed to reproduce.

Build the case on risk, not on obsolescence

"The technology is out of date" is not a business case and will be defunded again.

Quantifiable risk funds this work: unsupported software with no security patches, a compliance obligation that cannot be met, skills the market no longer supplies, and a single point of failure in a critical capability. Cost, including the maintenance effort nobody has counted. Delivery capability, naming specific blocked initiatives with their expected revenue.

And structure it as increments with their own value, so funding is not an all-or-nothing multi-year commitment — which is what made the last attempt easy to cancel.

Wrap before you migrate

The highest-value first move: put a modern API or event stream in front of it, translating to whatever the legacy system actually offers.

That decouples every future consumer without the legacy system changing, and the anti-corruption boundary stops twenty years of legacy modelling propagating into new services. Publishing raw legacy structures — particularly a CDC feed carrying the source's table and column names — would make the legacy model the organisation's permanent contract.

Then strangle, capability by capability

Find the seams, and create one if there is none. CDC into a read model to offload query traffic first, which reduces load, unblocks new development and is low risk. Then migrate capabilities one at a time behind the facade, with feature flags for instant rollback and shadow running for the high-risk ones — pricing, calculations, anything regulated.

Sequence by value and risk: something valuable, moderately complex and lightly coupled first, to prove the approach and build the pipeline. Not the hardest, most entangled core.

Plan for the parts people skip

Data migration is the longest pole — continuous replication with a short cutover, verification by reconciliation rather than "the job completed", and a tested rollback for every step with the one-way step marked.

The coexistence period has its own cost — synchronisation, routing, reconciliation, duplicate operations — and it extends indefinitely if the business keeps changing the old system. Keep increments short and complete.

Decommissioning must be funded and scheduled up front, with a brownout to surface the last consumers. A migration that does not decommission has produced two systems and doubled the cost.

State the acceptable end

Some of the system may never move, because the value does not justify the cost. Saying that at the start means the programme is judged on the objective rather than on reaching zero — which is precisely the trap the last attempt fell into.