Taking over a software project from another agency: a rescue checklist

To take over a software project from another agency, spend the first two weeks proving what you actually own and what actually works, before you change anything. Secure access to the repository, cloud accounts, domains and secrets first. Then review the code, tests, deployment pipeline, data and security, and only then decide whether to refactor or rewrite. Most rescues go wrong because someone starts building before they have read the evidence.

Key takeaways

• The first job in a takeover is establishing ownership and access, because you cannot fix, deploy or even legally control a system whose accounts sit in someone else’s name.
• Warning signs are visible well before a project fails: no working demo for weeks, no tests, deployments only one person can do, and reports that say “almost done” instead of showing software.
• A two-week audit covering access, code, tests, deployment, data and security produces a written picture you can decide from, and it costs far less than a wrong rewrite.
• Refactor when the data model and core architecture are sound and the problems are local; rewrite only when the foundations block what the business needs, and even then keep the data.
• Keep the product running during the transition by freezing risky changes, fixing backups and monitoring first, and moving responsibility in stages rather than in one day.
• Most future rescues are avoidable with contract terms that give you the code, accounts and documentation from day one, plus weekly demos on a live URL.

What are the warning signs that a project needs rescuing?

A project needs rescuing when you can no longer see or verify progress, and when changing anything feels dangerous. These signs usually appear in this order.

• No working software for weeks. Reports, slide decks and percentages replace demos. “90% done” has been true for a month.
• The same bugs keep coming back. A fix in one place breaks another, which suggests missing tests or tangled code.
• One person holds all the knowledge. Only one developer can deploy, or explain how a feature works.
• You do not control the accounts. The repository, cloud hosting, domain or app store listing belongs to the agency or a contractor.
• Releases are rare and frightening. Deployments happen at night, by hand, with crossed fingers.
• The team keeps changing. The people you met in the sales process are gone, and nobody can say who is writing the code.

Two or three of these deserve a closer look. If you cannot judge it yourself, a short independent review is the cheapest first step. A fractional CTO or a technical due diligence review does exactly this.

What should you do in the first two weeks?

Spend week one on access and ownership and week two on assessing the code and the way it runs. Do not rewrite anything yet. The goal is a written assessment you can act on.

A workable order: days 1 to 5 for access and securing a snapshot, days 6 to 12 for code, tests, deployment, data and security, and days 13 to 14 for a written decision.

Step 1: Access and ownership audit

Start here, because everything else depends on it. List every asset the product needs and confirm who owns each one:

• Source repository (GitHub, GitLab, Bitbucket): is it in an organisation you control, or the agency’s account?
• Cloud accounts (AWS, GCP, Azure, Cloudflare, Vercel): who is the root owner? Who has billing access?
• Domains and DNS: registered in whose name, and who holds the registrar login?
• App store accounts (Apple Developer, Google Play): the app listing and signing keys are tied to the account holder.
• Third-party services: payment provider such as Stripe, email, SMS, analytics, error tracking, maps, AI model APIs.
• Secrets: API keys, database passwords, signing certificates, where they are stored and who has seen them.
• CI/CD (GitHub Actions or similar), monitoring dashboards and ticketing history.

Get yourself added as an owner or administrator on each. Where the agency holds the account, ask for a formal transfer, not just an invitation. Keep a short register as you go.

Step 2: Secure and snapshot

Before reading code, protect what exists. Clone the full repository including history and branches, and store database backups in an account you control. Rotate widely shared credentials in a planned sequence, because rotating a production key without a plan can take the product down.

Step 3: Code and architecture review

Read the system from the outside in:

1. How is it structured? Monolith, services, serverless, a mix? Draw it on one page.
2. What is the data model? This is the part that matters most. Messy code can be cleaned up. A broken data model is expensive to fix once real customers exist.
3. What are the dependencies? Are frameworks and libraries current or abandoned? Which version of Node.js, Python or PHP is running, and is it still supported?
4. Where are the sharp edges? Look for hard-coded configuration or secrets, the largest files, the most-changed files and the parts people avoid touching.

Run the project locally from scratch, following whatever documentation exists. If that takes more than a day, that is a finding on its own.

Step 4: Test coverage

Ask: if you change one line in the checkout flow, how do you know nothing else broke? Check which tests exist, whether they pass, and whether they run on every pull request. Coverage of the critical flows (sign-up, payment, core workflow) matters more than a raw percentage. A project with no tests can still be saved, but you write tests around those flows before refactoring.

Step 5: Deployment pipeline

Find out exactly how a change reaches production. Is it automated or someone’s laptop? Is there a staging environment? Can a bad release be rolled back in minutes? Is infrastructure defined in code (Terraform, for instance) or clicked together in a console? If only one person can deploy, fix that in the first month.

Step 6: Data and backups

Locate every place data lives: the main database (PostgreSQL, MySQL, MongoDB), file storage, queues, third-party systems. Then check backups. A backup that has never been restored is a hope, not a backup, so do one test restore into a separate environment.

Step 7: Security review

This is not a penetration test. Check the basics: secrets in the repository history, dependencies with known vulnerabilities, exposed admin interfaces, who has production access, and whether multi-factor authentication is on for critical accounts. If the product handles personal data, note obligations such as GDPR and whether they seem to have been considered.

Takeover checklist

Use this table as a working document. Mark each row as confirmed, partly known or unknown.

Area	What to confirm	Typical finding	Priority
Repository	You own the organisation; full history is cloned	Repo in agency’s account	Day 1
Cloud	You are root owner or admin; billing is in your name	Agency pays and re-invoices	Day 1
Domains and DNS	Registrar login is yours	Registered by a developer	Day 1
App stores	You hold the developer account and signing keys	Listing under agency’s name	Day 1
Secrets	Stored in a manager; rotation order planned	Keys in code, chat or email	Week 1
Code structure	One-page map exists	Undocumented	Week 1 to 2
Data model	Reviewed and understood	Tables added ad hoc	Week 1 to 2
Tests	Critical flows covered, run on each change	Few or none	Week 2
Deployment	Automated, repeatable, reversible	Manual, one person	Week 2
Backups	Running and restore-tested	Never restored	Week 1
Monitoring	Errors and uptime tracked, alerts reach you	None	Week 1 to 2
Security	MFA on, dependencies checked, access reviewed	Shared logins	Week 2
Documentation	Local setup, deploy, accounts, decisions	Missing	Week 2
Contract and IP	Assignment of rights confirmed	Unclear	Day 1 to 3

Should you refactor or rewrite?

Refactor in almost every case where the data model and core design are sound. Rewrite only when the foundation blocks what the business needs. A rewrite feels attractive because nobody likes reading someone else’s code, but it is slower and riskier than it looks. It also throws away small bug fixes nobody remembers.

Use these criteria.

Lean towards refactoring when:

• The data model reflects the business reasonably well.
• The technology is mainstream and supported.
• Problems are local: a few messy modules, missing tests, poor deployment.
• You can add tests around critical flows and improve step by step.

Lean towards rewriting when:

• The technology is abandoned or cannot be hired for.
• The data model is fundamentally wrong for the business (for example, single-tenant when you need multi-tenant).
• Security or performance problems are structural, not local.
• The cost of understanding and changing the code is higher than the cost of rebuilding, and you can show that with evidence.

A middle path often wins. Keep the database and the parts that work, put the new code behind the existing interface, and replace one module at a time. This is sometimes called the strangler fig pattern: the new system grows around the old one until the old one can be removed. You ship working software throughout.

Whatever you decide, base it on the written findings from the two-week audit, and put a rough cost and timeline range next to each option. If someone proposes a rewrite before reading the code, be careful.

How do you keep the product running during the transition?

Keep it running by freezing risky changes, making production safe first, and moving responsibility in stages. Customers should not notice the handover.

1. Freeze non-essential changes during the audit. Only ship fixes for real incidents.
2. Make production visible. Add error tracking and uptime monitoring before anything else. You cannot protect what you cannot see.
3. Fix backups. Confirm they run, then test a restore.
4. Write a runbook. Even a one-page document: where the system runs, how to restart it, who to call, how to roll back.
5. Run in parallel for a defined period. The outgoing team keeps responsibility for incidents while the incoming team shadows deployments, then leads them with the old team on hand.
6. Move access in stages. Read access first, then deploy rights, then ownership and billing. Rotate credentials only once the new team can deploy and has a rollback plan.
7. Set a handover date with acceptance criteria: documentation delivered, accounts transferred, a deployment done by the new team.

What contract and IP lessons come out of a rescue?

Most takeover pain traces back to contract terms nobody read at the start. Check the existing contract now, and fix the terms in the next one.

• Intellectual property. Confirm that rights in the code are assigned to you, not just licensed, and from when. Some contracts transfer ownership only after final payment. If you are in a dispute, that matters. Get legal advice for your jurisdiction.
• Accounts and credentials. The contract should say that repositories, cloud accounts, domains and developer accounts are opened in your name.
• Documentation as a deliverable. Local setup, deployment steps, architecture decisions and account lists should be listed in the scope, not assumed.
• Handover and exit. A clause that states how long a handover takes, what is included and who pays.
• Non-solicitation and notice periods. Check whether you are restricted from hiring the agency’s developers, and how much notice you must give.
• Warranty and data protection. Is there a period in which the agency fixes defects at its own cost, and a data processing agreement if it handles personal data for you?

If the previous agency is cooperative, a few hours with their lead developer is worth a lot: an architecture walkthrough, a recorded deployment and a list of known issues. If not, rely on what you can verify yourself, and ask a lawyer before escalating.

How do you avoid needing a rescue next time?

Make the project transparent from the first week, so that a takeover would be an easy job. These habits matter more than any single tool.

• Own everything from day one. Repository, cloud, domains and app store accounts should be created by you and shared with the vendor, not the other way round.
• See working software weekly. A demo on a live URL every week makes “almost done” impossible to maintain. It is the best early-warning system there is.
• Require tests and review. Automated tests on important flows, run on every change, and code review before merge.
• Keep documentation and decisions current. Short architecture decision records explain why things are the way they are.
• Use an independent reviewer. Someone with no stake in the vendor’s invoices catches problems early. See how to choose a software development company for the questions that screen vendors in the first place.
• Keep scope small. Smaller releases make failure visible earlier. If you are scoping a first version, the MVP development approach is built around that.

How Hidook approaches this

Hidook is a remote-first product engineering studio. Our non-negotiable defaults are that the client owns the repository and cloud accounts from day one, tests run on every pull request, every change gets a preview URL, error tracking is in place before the first user, and documentation is handed over.

We do not think a rewrite should be the default; the recommendation should come from evidence, as in the audit above. We also support this work through our fractional CTO and technical due diligence service when a client wants an independent view of a project before deciding.

Frequently asked questions

How long does it take to take over a software project?

A first assessment takes about two weeks if you get access quickly. Becoming fully responsible for production, with documented deployment, monitoring and tested backups, typically takes a few more weeks. Clearing the underlying problems can take months, depending on the size and condition of the code.

What if the previous agency refuses to hand over the code or accounts?

Start with your contract, which should say who owns the code and the accounts. Ask a lawyer in your jurisdiction before escalating. Meanwhile, secure what you can verify yourself, such as domains and accounts registered in your name, and avoid changes that could damage the working product.

Is it cheaper to rewrite than to fix someone else’s code?

Usually not. Rewrites are tempting but they take longer than estimated and discard many bug fixes already made. Decide from evidence gathered in an audit, and consider replacing the system one module at a time.

How do I know if a codebase is salvageable?

Check the data model, the technology and the tests. If the data model matches the business, the stack is supported and you can add tests around critical flows, it is almost always salvageable. If the foundation cannot support what you need, a staged replacement is more realistic than a patch.

What should I do first if I suspect my project is in trouble?

Check who owns the repository, cloud accounts and domains. Then ask for a live demo of the current version. These two steps cost nothing and tell you a great deal.

If you have a project that needs a second opinion or a takeover, write to no.bs@hidook.tech or book a call at https://hidook.tech/contact/.