The legacy replacement that fails is almost always the one that ships all at once. A team spends eighteen months building a replacement in parallel, picks a weekend, cuts over — and discovers that the old system did forty things nobody documented, several of which the business depends on daily.
We have replaced and modernised enough of these to be fairly opinionated about how to avoid that.
Start by finding out what the old system actually does
Not what the documentation says. Not what the original spec said. What it does now, including the behaviour nobody intended: the report someone exports every Tuesday, the field being used for something other than its name, the job that quietly fixes bad data at 3am.
The fastest way to find these is to watch the work rather than read the code — sit with the people who use it, and check the logs for what actually runs. Undocumented behaviour is not an edge case in a fifteen-year-old system. It is a large fraction of the system.
Strangle it, don’t replace it
Pick one bounded capability, build it properly in the new system, and route just that traffic across. Then the next. The old system keeps running and keeps shrinking. Every step is small enough to reverse, and the business never waits on a single cutover date.
This takes longer on paper than a rewrite. In practice it finishes, which rewrites frequently do not.
Run both and reconcile
For anything that touches money, compliance, or customer-facing output, run the old and new paths together for a period and compare results automatically. Disagreements are the highest-value thing you will find — each one is either a bug in the new system or undocumented behaviour in the old one, and you want to know which before you rely on it.
The data migration is the project
Teams routinely budget the migration as a final task. In a long-lived system it is usually the largest single piece of work: years of records written under rules that changed several times, values that mean different things depending on when they were entered, and duplicates nobody has ever reconciled.
Plan for it early, migrate repeatedly into a staging copy, and let the failures teach you what the real data model is.
Keep the old URLs, keep the audit trail
Two things are easy to forget and expensive to lose: the addresses people and search engines already have, and the history that regulators or auditors may ask about. Redirect the former deliberately and carry the latter across — a modern system that cannot answer questions about last year is not an improvement.
What this looks like as an engagement
We start by mapping the current operation and the real dependencies between its parts, then propose a sequence — what moves first, what stays, what gets retired. Often part of the answer is that some of the old system should be bought rather than rebuilt, and we will say so. See custom software development, or start with a readiness audit.