When "if it ain't broke" starts costing you money

“It still works” is the reason most legacy systems never get scheduled for migration. It’s also the wrong question. The right question is whether the system is still cheap to keep, and for most systems that have been running untouched for five or ten years, it isn’t — the cost has just moved somewhere less visible than a line item.

Where the cost actually goes

A working legacy system taxes the organization in ways that don’t show up on a system-health dashboard: every new feature takes longer to ship because it has to route around what the old system can’t do, every hire needs longer onboarding because the system’s quirks aren’t documented anywhere, and every incident takes longer to resolve because the person who understood that subsystem left two years ago.

None of that shows up as downtime. It shows up as velocity that quietly gets worse every quarter, and a team that has stopped proposing ambitious things because they know what it would take to build on top of what’s there.

The tell

The clearest signal isn’t a specific outage — it’s when “let’s not touch that” becomes a standing answer to roadmap conversations. Once a system is load-bearing enough that nobody wants to be the one who breaks it, the cost of leaving it alone and the cost of migrating it have usually already crossed, even if nobody’s measured it directly.

Putting a number on it

Measuring the hidden cost is possible — it shows up in engineering time spent working around the system, in the delay on features that touch it, and in the risk premium the team quietly attaches to any change near it. That’s the starting point for deciding whether a migration is overdue rather than optional.

Once the cost is real enough to act on, the next question is how to move the system without adding a second cost on top of it — see big-bang vs. strangler-fig for how that choice gets made.