Legacy Systems and the Hidden Cost of "It Still Works"

"It still works" is one of the most expensive sentences in a scaling business's technology strategy, precisely because it sounds like a reason for confidence rather than a warning sign. A system that hasn't failed yet is not the same as a system that's still the right choice, and the gap between those two things tends to widen quietly, for years, before it becomes impossible to ignore.

Why "it still works" is the wrong test

The test a business should be applying isn't whether a system currently functions. It's whether that system still fits the business it's running in: the headcount, the number of sites, the volume of data, the integrations the rest of the stack now needs, and the level of risk the business can actually tolerate. A system can pass the first test for a decade while failing the second one for most of that time.

The costs that don't show up on an invoice

Opportunity cost. Every hour a team spends working around a legacy system's limitations, manual workarounds, duplicate data entry, manual reconciliation, is an hour not spent on work that grows the business. This cost rarely appears on a budget line, because it's distributed across dozens of small inefficiencies rather than one visible expense.

Key-person risk. The longer a system has been in place, the more likely it is that its quirks, workarounds and undocumented dependencies live in the heads of one or two long-serving staff, rather than in any documentation. That's a serious, and usually invisible, single point of failure.

Integration drag. Every new system the business adopts has to be made to work around the legacy system's limitations, rather than the other way round, and that drag compounds with every new tool added to the stack.

Security exposure. Older systems are more likely to be running on unsupported versions, with fewer, less frequent security updates, and less vendor attention generally, all of which widens the business's attack surface in ways that are easy to underestimate because nothing has gone wrong yet.

Recruitment and retention friction. New hires, particularly younger or more technically capable ones, notice quickly when a business is asking them to work around systems that feel a decade behind what they've used elsewhere, and it shapes how they feel about the business more than most leaders expect.

Why "it still works" persists as an answer

Replacing a legacy system carries real, visible cost and risk: migration effort, retraining, the chance something goes wrong during the transition. Leaving it in place carries cost too, but that cost is diffuse, distributed, and easy to defer, which is exactly why it tends to lose the argument against a system that, on the surface, still works.

The better question to ask

Not "does this system still work" but "if we were choosing our systems today, for the business we actually are now, would we choose this one again?" If the honest answer is no, the system is legacy in every sense that matters, regardless of whether it's still technically functioning.

What a considered approach looks like

The businesses that manage this well don't treat legacy replacement as a single, dramatic project forced by a failure. They treat it as an ongoing discipline: reviewing core systems on a regular cycle against the business's current and near-future shape, not just their historical uptime; documenting the workarounds and dependencies that have built up, so key-person risk is visible rather than hidden; and planning migrations proactively, on a timeline the business controls, rather than reactively, once a system fails or a vendor withdraws support.

This is quietly one of the most valuable things dedicated IT leadership does for a scaling business: not making dramatic changes, but asking the uncomfortable "would we choose this again" question on a schedule, before the answer is forced by an outage, a security incident, or a vendor decision entirely outside the business's control.