Guide · Taking over a project

Taking over an existing software project: the complete rescue guide

By MervenorPublished 29 Oct 2026Last reviewed 29 Oct 20265 min read

In short

Taking over software someone else built is a sequence, not a leap: secure the accounts, find out what you really have, stop the incidents, then plan the fixes in small, reversible steps. Most rescues go wrong because a new team starts changing code before it knows what the code does. Rebuilding from scratch is rarely the cheaper answer, and it should be chosen only when the evidence says so.

Signs a project needs rescuing

Every release breaks something, so releases have slowed to a crawl.
Nobody can build or deploy the application from a clean machine.
The developer or agency who built it has left, gone quiet or been let go.
Parts of the platform no longer get security updates.
A customer, investor or insurer has sent a security questionnaire you cannot answer.
Hosting and third-party bills keep rising and nobody can say why.

One of these is a warning. Three or more mean the project needs a deliberate takeover, not another patch.

Stage 1: Secure access before anything else

The code is only useful once you control everything around it. Get the domain, the hosting accounts, the source repository, the secrets and the third-party services into your company's name, in that order, then change every password and key the previous team knew. Do not start changes until this is done: a fix you cannot deploy, or a domain someone else can point elsewhere, is not a fix. The 10-step recovery checklist walks through it.

Stage 2: Find out what you really have

Before anyone writes code, get a read-only review of the whole system. It should cover:

Architecture and dependencies, including every framework, runtime and package that has reached the end of its support.
Build, deploy and environments: can it be built from a clean machine, and who holds the keys?
Tests and continuous integration: what exists, what it covers and what already fails.
Security: authentication, access checks, secret handling and known vulnerabilities.
Data: the schema, migrations and backups, and whether a backup has ever been restored.
Documentation and single points of knowledge: what is written down, and what lives only in one person's head.
Ownership and licences for accounts, services and paid components.
Speed, accessibility and search health of the public pages.

The result should be a written report with findings ranked by severity and a plan in three horizons: what must happen now, what should happen this quarter, and what becomes possible after.

Stage 3: Stop the incidents

Stabilise before you improve. Reproduce the incidents that hurt most and fix their causes; put automated tests around the parts that keep breaking; make deploys repeatable from a clean machine; add monitoring for errors and uptime; write a runbook for the things that go wrong at night. A short pause on new features during this stage costs less than shipping onto a foundation that keeps failing.

Stage 4: Decide what to fix, upgrade or rebuild

Choose	When	How
Fix	The code works and the risk is local	Targeted changes with tests around them
Upgrade or migrate	The platform is out of support or holding the product back	Small, reversible slices while the application stays live
Rebuild	The platform cannot run anywhere supported, the business rules are few and well understood, and the evidence shows a rebuild costs less than a staged modernisation	A new system behind the old one, moved over screen by screen

Rebuilds disappoint for predictable reasons: they deliver nothing until they are finished, they lose business rules nobody wrote down, and the old system keeps changing while the new one is built. Joel Spolsky's essay on rewrites (see Sources) makes the case in a few pages. Choose a rebuild on evidence, never because the old code is unpleasant to read.

Stage 5: Keep it healthy

After stabilisation, someone senior who knows the codebase should keep it current every month: dependency and security updates, monitoring during stated hours, small improvements from a list you control, and a written monthly report. The guide on what a maintenance retainer should include lists what to ask for.

Ownership and handover

Intellectual property: check that your contract with the previous developer or agency assigns the code and designs to your company; if it does not, ask for a written assignment. This is a question for your lawyer, not something to assume.
Accounts: every account the application depends on belongs to the company, with a company payment method, not a person's card.
A paid handover: if the previous team is still reachable, a few hours of paid handover (a walkthrough, the deploy steps, the known problems) is worth more than any amount of reverse engineering.
Communication: tell users and stakeholders what is happening, and send a short written status every week until the application is stable.

Questions people ask

How long does a takeover take?
Recovering access takes days if the previous team cooperates and longer if it does not. A read-only review takes about a week. Stabilising the worst problems usually takes a few weeks, depending on what the review finds.
What if the previous agency keeps the hosting account or the domain?
Ask in writing for a transfer, and keep the request and the replies. If an account cannot be recovered, migrate to a new one in your name: plan it like a release, with a rehearsal and a way back.
Can the previous developer stay involved?
Often that is the best outcome: a short, paid handover, then questions answered by email while the new team learns the system.
When is a rewrite the right answer?
When the evidence in Stage 4 says so. In most takeovers it does not: staged modernisation delivers value sooner and keeps the business rules that already work.
What drives the cost of a takeover?
How much is missing (code, documentation, access), the state of tests and deploys, the number of integrations, how far the platform is out of support, and how urgent the first fixes are. A fixed price is possible once someone has read the code.