Getting Out of a Legacy System

A codebase that's grown over ten years carries a lot of decisions whose reasons have long since vanished. Every change starts with detective work - what might this break? - and with no automated tests, the only place a change really gets tested is often the live site. Releases are manual and take two hours, and anyone who's run one knows the stress. The biggest risk isn't a crash, it's that the system becomes too scary to touch - so new features stall and competitors pull ahead.

The idea is simple: never switch off the old system until a new piece is ready to take over. We start with an audit - documenting what exists, what's in the worst shape, and what causes the most painful nights on call. Then we take one clearly-bounded part, such as login or the product catalogue, and rebuild it properly, with tests. Traffic is shifted onto the new version gradually, a little more each week, until the old part can be quietly retired. The business keeps running the entire time.

There's been no planned downtime and no single risky switchover. Releases that took two hours now take eight minutes and run on their own. The team can ship a new piece to the live site at the end of every week without long debates about whether it's safe - the tests answer that. They spend less time firefighting and more time building things that move the business forward.

The hardest part was uncovering hidden dependencies - indirect links between parts of the system, built up over a decade, that no documentation mentions. We traced what was actually connected by watching how the system behaved and what it queried. The second challenge was human: when there are no tests, every change feels dangerous, so the team had grown cautious. The first few weeks went mostly into writing tests for the existing features - only then did the rebuild gain real momentum.