Switching off a legacy system: why it takes longer than you think

Updated in September 2026. The original post from November 2021 was three sentences and a photo; the lessons behind it deserved more.

'Decommissioning legacy systems is an art.' a wise architect once told me. He was right.

The photo is the digital team at Maxeda DIY, on the day the old system went off. We had been there years earlier when the new platform went live, and I had made a prediction: one year, and the old one is gone. It took a good deal longer. Not because anyone was asleep, but because switching off a legacy system is a different thing from switching on a new one. This is why, and what you arrange up front so it happens anyway.

Building a new platform has an owner, a budget, a deadline and a party at the end. Switching off an old platform has none of the four. As soon as the new system runs, attention moves to what the new system cannot do yet. The old one keeps running "just in case", and that reassurance costs money every month: licences, servers, an administrator who still understands it, and a team maintaining two systems at once.

The real problem is that nobody knows exactly who still uses the old system. Not the users you know about, but the others: a report that pulls an export every Monday, a link to the accounting package nobody has touched since the person who built it left, a supplier still delivering files to the old address. Each of those consumers only surfaces when you pull the plug. And then you do not pull it.

My one-year estimate was not stupid, it was optimistic in a predictable way. Three things make it longer:

• The last five percent is not five percent of the work. The new system does 95 percent of what the old one did, because that is what it was built for. The remaining five percent are the exceptions: the process one customer uses once a quarter, the screen only the finance department knows. Those five percent cost the most in proportion, and they are the easiest to postpone.

• Data outlives software. The new system has the current data; ten years of history still sit in the old one. As long as anyone might ever want to look up an order from 2016, the old system stays on. As long as nobody decides how long that history must be kept, and where, nothing happens.

• Switching off is nobody's priority. It delivers no new feature and no revenue. It delivers lower costs, and those sit on a different budget than the team that has to do the work.

What we have done differently since, for ourselves and for clients who modernise a legacy system:

1. Plan the switch-off as part of the build, not as aftercare. The end date of the old system is in the project plan of the new one, with an owner and a budget. No date is no plan.

2. Inventory the consumers before you start. Not by asking, because people do not know, but by measuring: logging on every entry point of the old system, for a quarter. Every IP address, every username, every nightly batch. That list is the real scope.

3. Move step by step, with the old system alongside. The strangler pattern: every function the new system takes over is switched off or redirected in the old one. The old system shrinks while the new one grows, and there is never one big moment where everything has to happen at once.

4. Make it read-only first. Months before it goes off, nothing may be written to it any more. Whoever still tries reports themselves, and that is exactly the consumer you had missed.

5. Decide about the data separately from the software. How long the history must be kept, who may access it, and in what form: an archive you can search is not the same as a server that stays on. Usually an export to cheap storage plus one search screen is enough, at a fraction of what the old system costs per month.

6. Pull the plug on an agreed day, and celebrate. Not "when everything is done", because it never is. A day, a list of what still hangs off it, and a decision per item: move, archive or drop. The photo at the top is what you get when you do that.

The most visible part is the bill: licences, hosting and maintenance that stop. Less visible, and bigger, is what the team gets back. Every change had to be made twice, every incident could come from either system, and every new colleague had to learn two worlds. That stops.

And a risk disappears. A system that runs "just in case" gets no updates, no attention and no security. It is exactly the system an attacker looks for: known, old, and without an owner. Switching off is the only patch that always works.

Not when the new system is live. By then it is too late to measure the consumers and too early to put anyone to work. The moment is the start of the build: who owns the switch-off, what is the date, and what do we do with the data. Three questions, half an hour. In our case it would have saved a good deal more than a year.

Stuck with a system that "should have been off by now"? We are happy to look at what still hangs off it. That first conversation costs nothing, and neither does a script to make an export or to reroute a link.