Your legacy system is one retirement away from a crisis

Every long-running system accumulates a small group of people who understand why it’s built the way it’s built. When that group is down to one or two names, the system has a risk profile that has nothing to do with its code and everything to do with a calendar you don’t control.

The knowledge isn’t written down

It rarely is, for legacy systems built before documentation was a habit — or built during a crunch where documenting the decision took a back seat to shipping it. What exists instead is a handful of people who can explain why a particular workaround is there, which tables are safe to touch, and which parts of the system are load-bearing in ways that aren’t obvious from the code.

Why this is a migration problem, not an HR problem

You can’t hire your way out of key person risk on a system nobody else has context on — a new engineer reading the code doesn’t get the history, the near-misses, or the reason a “temporary” fix from four years ago is still in production. The knowledge that’s actually at risk is tacit, and it only fully transfers through a process that forces someone to externalize it: documenting it, or migrating the system to something the rest of the team can actually reason about.

What this changes about timing

If your system’s key person risk is concentrated in one or two people, the migration decision isn’t really about system age or tech debt — it’s about a clock you don’t control. Waiting for a natural pause in the roadmap assumes the clock waits too. It usually doesn’t, and the audit is worth doing before it runs out rather than after. See what a legacy migration specialist actually does for how that knowledge transfer gets handled deliberately instead of accidentally.