Taking Over Someone Else's Codebase: What Happens in the First Two Weeks

The call usually sounds the same.

The team that built it has moved on — an agency relationship ended, a contractor stopped replying, a lead developer resigned. The software still runs. It’s still making money, or scheduling work, or serving customers. But nobody left in the building can safely change it, and there’s a release the business needs next month.

This is one of the most common situations in commercial software, and one of the least written about, because it isn’t a story anyone enjoys telling. It’s also a large share of the work we do — MUTTS came to us exactly this way, needing a legacy-built system upgraded and maintained after their previous developers.

Here’s what the first two weeks actually look like, and why they matter more than anything that follows.

Week one: read, don’t refactor

The strongest instinct on inheriting an unfamiliar codebase is to start improving it. Resist that completely.

Code that looks wrong is often load-bearing. That bizarre conditional handles a real customer’s real edge case. The duplicated function exists because someone learned the hard way that the shared one broke something. A codebase is a record of decisions, and you cannot read the decisions from the code alone — you have to infer them, and inference takes time.

So week one is archaeology, not surgery. The single most valuable output is a working local build and a repeatable deployment. Until you can run the thing and ship a trivial change through the full pipeline, you don’t have a codebase — you have a folder.

That’s often harder than it sounds. Undocumented environment variables, a dependency that no longer resolves, a build step that only ever ran on one person’s laptop. Getting from zero to “I can deploy a comment change safely” is a genuine milestone, and we treat it as the first deliverable.

What we’re actually looking for

A handful of things tell you most of what you need to know about inherited software.

Can it be built and deployed reproducibly? This predicts almost everything else about the project’s health.

Are there tests, and do they run? Not for coverage vanity — tests are documentation of intent. A test tells you what the original team believed the system should do, which is information you cannot get any other way once they’re gone.

Where does the data actually live, and what shape is it in? The data model is the part you’re least likely to be able to change later. Application code can be replaced incrementally; a schema that half the business depends on cannot.

What’s hard-coded that shouldn’t be? Credentials in the repo, a payment threshold buried in a constant, an integration pointed at someone’s personal account. These are urgent and they’re common.

What’s the dependency situation? A framework three major versions behind with known vulnerabilities is a scheduling problem you want to discover in week one, not month four.

Who still knows something? Almost always someone does — an ops person, an early employee, the client-side project manager. An hour with them is worth days of reading.

The rewrite trap

At some point in the first fortnight, someone will suggest rebuilding from scratch. Sometimes it’s us who’s tempted.

It’s almost always the wrong call, for a reason that has nothing to do with technology: a rewrite delivers no value until it’s finished, and it’s finished much later than anyone estimates — while the existing system still needs maintaining in parallel. You end up funding two systems and shipping neither.

The alternative that works is unglamorous. Wrap the existing system, build new functionality alongside it, and migrate piece by piece as each piece earns its replacement. The old system shrinks gradually instead of being switched off dramatically. Every step delivers something. Nothing is bet on a single cutover date.

There are genuine exceptions — a platform that’s out of support entirely, a security posture that can’t be remediated, a technology nobody can be hired for. But those are decisions to make in month three with evidence, not in week one on instinct.

Stabilise, then improve

The order matters and it’s frequently got backwards.

First, make it safe to change: reproducible builds, a staging environment, error monitoring, backups you’ve actually tested restoring. Then, fix what’s actively hurting — the bugs users hit, the security issues, the thing that falls over every Friday. Only then improve the architecture, and only where it blocks something the business wants.

Refactoring before you have monitoring is how you discover you broke something from a customer complaint rather than an alert.

Ship something visible, early

There’s a trust problem in every takeover. The client has just been through a bad experience, they’re paying a new team to read code rather than write features, and week two feels like nothing is happening.

So we ship something small and visible fast — a bug that’s been annoying people for months, a slow screen made quick. It’s not a stunt. It proves the pipeline works end to end, it validates that we understand a slice of the system, and it changes the relationship from anxious to collaborative. That matters more to the eventual outcome than most technical decisions.

What to have ready

If you’re planning a handover, the transition goes dramatically faster when these exist on day one: repository access with full history, every environment and its configuration, the credentials and third-party accounts the system depends on, domain and DNS control, app store accounts, database access with a restorable backup, and — most valuable of all — a conversation with anyone who worked on it.

The history matters more than people expect. A repo delivered as a single “initial commit” throws away years of context about why things are the way they are.

The honest version

Inheriting software is rarely as bad as the client fears on the first call. Most systems that feel unmaintainable are simply undocumented, and undocumented is a solvable problem given a methodical few weeks.

Sixteen years and 800+ projects have taught us that the teams who take over well are the ones willing to be slow for a fortnight in order to be fast for a year.

---

Got a system nobody wants to touch? Tell us about it — we’ll give you an honest read on whether it needs rescuing, replacing, or just documenting. Or see how we build custom software.