← Back to archive

Legacy code risk: the handover tax and key-person RISK

From my experience legacy code doesn’t become dangerous because it’s old but when nobody dares to read it.

That instinct has a cost. Call it the handover tax - the weeks you burn waiting on documentation and knowledge transfer from a team that has usually already moved on.

A company came to us with a legacy transportation platform and three things missing:

  • no documentation
  • no handover
  • no original team to call

Just the repo. We said: that's fine and to tell the truth during our 20 experience is quite common - send us the code. A lot of decision-makers still treat documentation as the handover.. of cours, it helps. But the real handover is the codebase itself. Docs can be outdated The original team can be gone and the wiki can describe how the system was supposed to work two years ago The repo shows what is actually running today.

So that's where we started: reading it, tracing the dependencies, rebuilding the pieces that were holding the business back…. and all without a single onboarding call to someone who no longer worked there.

The dependency that leadership teams quietly protect - "we can't afford to lose the people who understand this system" - is mostly a comfort blanket. A good senior engineer reads an unfamiliar codebase roughly the way you'd read someone else's P&L: slow going for the first hour, fluent by the end of the week.

➡️ If your platform can't survive the people who built it leaving, the problem was never the code but it's key-person RISK with a deploy pipeline. ⬅️

The legacy system you're nervous to touch is rarely a technical problem at heart - it's an organizational one, where the future of the platform hangs on whoever happens to still be around to explain it.

Legacy code risk: the handover tax and key-person RISK

Originally posted on X

PS: I'm pretty active on 𝕏 if you'd like to follow along

Archive

2026

2025

2024

2018