Taking Over a Software Project: What the First 90 Days Need

Taking over a software project built by someone else should start with an assessment and a quarter of stabilisation work. A rewrite is a last resort, however easy it is to sell.

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. 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, and several of our long engagements are attached to inherited systems. The discipline that makes software project rescue work is mostly about resisting that pitch.

How to assess an inherited codebase

The opening move is an assessment. Estimates come after it. 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 look like, compared with what the documentation claims?

The output is a risk map of the system. Some regions are fine and should be left alone, a conclusion rewrite-sellers cannot afford to reach. Some are risky but stable, worth watching and best left untouched for now. A few are dangerous: unpatched, untested and load-bearing. Effort goes there first.

Stabilising an inherited system before changing it

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 depends on someone's memory. 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. These deliverables make every later change cheaper and safer, which makes them the fastest route to features that ship without incident.

Incremental modernisation instead of a rewrite

With stability in place, improvement proceeds incrementally: modules replaced along the boundaries the system already has, while the business keeps running. The big-bang rewrite stays a last resort for systems that cannot be saved, and we say so up front even when the rewrite would be the larger engagement. Modernisation done this way is uneventful: value arrives continuously and the system stays up throughout.

Knowledge transfer after a software project takeover

The final discipline is making sure the problem does not recur. 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. Our outsourcing guide covers the handover terms to put in a contract.

Frequently asked questions

Should we rewrite a codebase we have inherited?

Usually not. Most inherited systems are better improved module by module along their existing boundaries, and a full rewrite is a last resort for systems that cannot be saved.

How long does a codebase assessment take?

A few weeks, and the findings are useful whoever does the work afterwards.

What should the first 90 days of a software project takeover include?

An assessment of risk and test coverage, then a build pipeline, tests around the most important behaviours, monitoring and logging, and updates to dependencies with known vulnerabilities.

How do we avoid ending up with an unmaintainable system again?

Write down what the assessment finds, record architecture decisions as they are made, and have your own engineers pair on the work so the knowledge stays with you.

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.