Taking Over Someone Else's Codebase

Sooner or later every organisation ends up holding a codebase built by people who are gone: a departed vendor, a disbanded team, an acquisition. The system works, mostly, which is why it survived. And the first consultancy through the door will reliably recommend rewriting it, because rewrites are easy to sell, pleasant to build, and someone else's problem by the time the invoices mature.

We take over codebases regularly, ours is a business with long engagements attached to inherited systems, and the discipline that makes it work is mostly about resisting that pitch.

First, learn what it actually does

The opening move is an assessment, not an estimate. What does the system do, and for whom? Where does risk concentrate: the modules that change most, the dependencies furthest out of date, the parts only the departed author understood? What do the tests cover, and what do they merely touch? What does production actually look like, versus what the documentation claims?

The output is a map with honest colours on it. Some regions are fine and should be left alone, a conclusion rewrite-sellers cannot afford to reach. Some are risky but stable, worth watching rather than touching. A few are genuinely dangerous: unpatched, untested and load-bearing. Effort goes there first.

Stabilise before you renovate

The first deliverables on an inherited system are almost always the same, and none of them are features. A build pipeline that produces a deployable artefact from source, because until then every deployment is a ritual. Tests around the behaviours that matter most, written from observed behaviour where no specification survives. Monitoring and logging that make production explainable. Dependency updates for anything with known vulnerabilities.

Clients sometimes chafe at a first quarter without visible features. The honest answer is that these deliverables make every subsequent change cheaper and safer, which is another way of saying they are the fastest route to features that ship without incident. A system you cannot deploy confidently is a system you cannot change, whoever wrote it.

Renovate along the seams that exist

With stability in place, improvement proceeds incrementally: modules replaced along boundaries the system actually has, not the boundaries a whiteboard wishes it had, while the business keeps running. The big-bang rewrite stays what it should be, a last resort for systems that are genuinely unsalvageable, and we say so up front even when the rewrite would be the larger engagement. Modernisation done this way is dull in the best sense: value arrives continuously and nothing burns down in between.

The knowledge is the real inheritance

The final discipline is making sure the problem never recurs. Everything learned in the assessment gets written down. Architecture decisions get recorded as they are made. The client's own engineers pair on the work if the client has them, because the goal, as with everything we hand over, is a system the owners can run. Inheriting a codebase once is circumstance. Being in a position to be inherited badly is a choice.

If you are holding a system whose authors are gone, the assessment is a few weeks and stands on its own, whoever does the work after it.

Ha Nguyen is Head of Delivery at Coder Trove's Vietnam delivery centre, where several long-running engagements began as exactly this kind of takeover.