A system becomes legacy on the day a reasonable change request gets refused because nobody is confident about what it would break. The code did not change that day. The organisation's relationship with it did.
The symptoms
- Small changes are quoted in weeks, and the estimate is mostly fear.
- There is one person who can deploy, and they are cautious about holidays.
- Nobody can set up a working local environment from scratch.
- There are no tests, or there are tests that everyone has agreed to ignore.
- The dependencies are several major versions behind and upgrading them is its own project.
Why the rewrite is usually the wrong first move
A full rewrite means reproducing years of accumulated business rules — most of them undocumented, many of them discovered only when someone complains that the new system got it wrong. Meanwhile the old system still needs maintaining, so you are funding two systems and getting new value from neither. Rewrites are not impossible, but they are the most expensive option on the table and they are usually chosen first, on instinct.
A sequence that works
- 01Make it observable. Before changing anything, add logging, error tracking and metrics. You cannot safely modify a system whose current behaviour you cannot see.
- 02Make it reproducible. Get it building and running from a clean checkout, in a container, with a documented procedure. This alone removes a surprising share of the fear.
- 03Make it deployable. An automated pipeline that builds, tests and deploys turns releases from events into routine. Confidence to change comes largely from confidence to release.
- 04Characterise the behaviour. Write tests that capture what the system does now, correct or not. These are your safety net for everything that follows.
- 05Change at the edges. New functionality goes into new, well-structured components alongside the old system rather than inside it.
- 06Strangle the core. Route responsibility for one capability at a time to the new components, and retire the old paths as they go quiet.
Each of these steps delivers value on its own. If the programme is paused after step three, you are still meaningfully better off — which is not true of a rewrite abandoned at sixty percent.
What an assessment should tell you
Before committing to any of this, it is worth paying for an honest assessment. A good one answers four things: what the system actually does, what condition it is really in, which parts are worth keeping, and what the realistic options cost — including the option of leaving it alone.
That last option deserves genuine consideration. Some systems are stable, unloved and best left running until the business need changes. Modernisation is worth doing when the business is being held back by the software, not merely because the software is old.