How to Take Over a Software Project From Another Vendor: The Handover Checklist

To take over a software project from another vendor safely, do it in this order: secure every account and the repository in your own name, collect a written handover, get an independent audit of the code, reproduce the build and deployment from scratch, fix the dangerous issues, and only then restart feature work. Founders who reverse that order, giving notice first and asking for passwords later, are the ones who end up locked out of their own product.

We take over stalled codebases regularly. Some were abandoned by a freelancer who stopped answering. Some were “80% done” for a year. Some were generated with AI tools and fell over the moment real users arrived. The technical problems differ. The handover mistakes are almost always the same. This is the software project handover checklist we wish every client had before calling us.

Signs it is time to switch vendors

Switching has a real cost, so be honest about whether you need to. These are the signals that usually mean yes:

• Deadlines move, and the reasons get vaguer. One slip is normal. A pattern of slips with no specific cause means nobody has a grip on the work.
• You cannot see working software. You get status reports and screenshots, but no staging URL you can click through.
• Every fix creates a new bug. That is a sign of missing tests and a tangled codebase, and it gets worse with time, not better.
• The people changed. The senior engineer from the sales call has been replaced by people you have never met.
• Simple questions get slow or defensive answers. “Where is the code hosted?” should not take a week.
• The invoice grows, the scope does not. You are paying more each month for the same unfinished feature list.

If three or more of these are true, start preparing. Preparing does not mean giving notice. It means quietly making sure you can walk away.

Before you tell the current vendor: secure ownership

This is the most important section in this article. Do it while the relationship is still friendly.

Make a list of every account your product depends on and check who the owner is. “We have a login” is not ownership. Ownership means your company is the account owner or organisation admin, and the vendor is a collaborator you can remove.

Asset	Where it usually lives	Who should own it	How to check
Source code	GitHub, GitLab, Bitbucket	Your organisation	You are an owner of the org, and full history is there
Cloud hosting	AWS, Google Cloud, Azure, Vercel, Render	Your account and billing	You can see billing and IAM, not just one project
Domain and DNS	Registrar, Cloudflare	Your account	The domain is registered to your company
Database and backups	Managed database, Supabase, MongoDB Atlas	Your account	You can download a fresh backup yourself
Payments	Stripe, Paddle, PayPal	Your company	You are the account owner, payouts go to your bank
Email sending	SendGrid, Postmark, Amazon SES	Your account	Sending domain verified under your account
App stores	Apple Developer, Google Play	Your company	You are Account Holder, not just a team member
Analytics and tracking	Google Analytics, Tag Manager, Mixpanel	Your account	You have admin rights
Third-party APIs	OpenAI, maps, SMS, auth providers	Your account	API keys are issued under your billing
Secrets and environment variables	Vault, CI settings, a .env file somewhere	You, in a password manager	You have a complete, current copy

The app store row deserves special attention. Transferring an app between developer accounts is possible but slow, and if the vendor published your app under their own account, you need their cooperation to move it. Start that early.

Also check your contract for the IP clause. Many agreements assign intellectual property only on full payment. If invoices are disputed, resolve that or get a written assignment before you announce anything. Arguing about ownership after the relationship has broken down is slow and expensive.

The handover checklist

Once you own the accounts, ask the outgoing team for a structured handover. Put the request in writing, with a list:

• Full repository history, including all branches, not a zip file of the latest version.
• Every environment variable and secret for every environment (local, staging, production).
• A description of how to build and deploy, step by step, including anything run by hand.
• A list of scheduled jobs, cron tasks, webhooks and background workers, and where they run.
• A list of every third-party service, what it does, and who pays for it.
• Database schema, migration history, and a recent backup you have verified you can restore.
• Known bugs, open tasks and half-finished branches, with a sentence on each.
• Any manual operations the team performs, such as monthly data fixes or restarting a stuck service.
• One or two recorded walkthrough sessions with the engineers who wrote the code.

The recorded sessions matter more than the documentation. Engineers explain things in a call that they never write down: “Oh, that endpoint, we never use that, it’s from the old version.” Record it and keep it.

Be civil. The outgoing team will know things you need for months, and a professional exit costs you nothing. Pay what you owe, thank them, and keep the door open for questions.

The first two weeks: audit before you build

The new team’s first job is not features. It is understanding what you actually have. A proper takeover audit covers:

Build and deploy. Can a new engineer build the product from a clean machine using only the repository and documented secrets? If not, that is finding number one. A product that only deploys from one person’s laptop is one laptop away from being frozen.

Security. Secrets committed to the repository, missing authorisation checks on API endpoints, admin routes protected only by being hard to guess, outdated dependencies with known vulnerabilities, and user data exposed through overly broad database rules.

Data. Is there a real schema and migration history, or has the database been edited by hand? Are backups automatic, and has anyone ever restored one?

Payments and integrations. Are Stripe webhooks verified and idempotent? What happens when a webhook arrives twice, or not at all?

Tests and observability. Is there any automated test coverage on the critical paths: sign-up, payment, the core workflow? Is there error tracking, or do you learn about errors from customers?

Maintainability. Duplicated logic, dead code, inconsistent patterns, and how hard it is to change one thing without breaking another.

The result should be a written verdict: what is healthy, what is risky, what to fix first, and roughly how much effort each fix takes. If you want that verdict before committing to anyone, a free code audit is exactly this exercise, done by a senior engineer, in writing.

Fix, refactor or rebuild?

Every inherited codebase tempts someone to say “we should rewrite this.” Usually that is the wrong call. A rewrite throws away years of edge cases the old code already handles, and rewrites routinely take longer than the original build.

Situation	Usual verdict	Why
Code is messy but works, data model is sound	Fix and refactor gradually	Behaviour is correct, you only need to make change safe
Security holes, no tests, but sensible structure	Fix urgently, then add tests	The danger is concentrated and fixable
Data model is fundamentally wrong for the product	Rebuild the core, migrate data	Every feature fights the model, fixes will not stick
Framework or platform is abandoned or unpatchable	Planned migration in stages	Keep the product running while you move it
Small product, mostly scaffolding, few users	Rebuild can be cheapest	Little to lose, and a clean base speeds everything after
Fixing would touch most files anyway	Rebuild, reusing what you can	You are effectively rewriting already

The right verdict comes from reading the code, not from the new team’s preferences. Be suspicious of a new vendor who recommends a full rebuild before they have looked, because a rebuild is the biggest invoice they can write.

Common traps in a software project takeover

These are the issues we find again and again when taking over a codebase:

• The vendor’s personal accounts. The production database runs on the agency’s cloud account, and the bill has been passed through to you. Moving it is a migration, not a password change.
• Hard-coded secrets. API keys in the source code, sometimes in the frontend bundle where any visitor can read them. Rotate every key after the handover, regardless.
• Undocumented cron jobs. A nightly script on a server nobody remembers keeps something important in sync. You find it when it stops running.
• Licences in someone else’s name. Paid themes, UI kits, fonts or SDK licences bought by the vendor and not transferable.
• Manual fixes disguised as features. Someone has been editing data by hand every week to keep a report correct.
• Half-merged branches. Important fixes live on a branch that never reached production.
• Unknown webhooks. Payments or CRM integrations post to an endpoint on a server you are about to shut down.

None of these are disasters if you find them in week one. All of them are disasters if you find them after the old vendor has gone quiet.

How to choose the team that takes over

Taking over someone else’s code is different work from building fresh. You want engineers who read code calmly, write down what they find, and do not reach for a rewrite by reflex. Ask any candidate team:

• Have you taken over a codebase before? What did you find, and what did you change first?
• Will you audit before quoting? (The answer must be yes. Anyone quoting a takeover without reading the code is guessing.)
• How will you keep the product running while you fix it?
• Can the fixes be quoted as a fixed scope?

The general vendor questions still apply, and we cover them in how to choose a software development company.

On pricing, separate the two phases. The audit and the first round of fixes are a defined piece of work and can be quoted at a fixed price. Ongoing development after that is better run as a team with monthly billing. If you are weighing the pricing models, see fixed price vs time and materials. For the cost of building and maintaining custom software more broadly, our custom software development cost guide shows market ranges and what drives them.

Our own approach to this work is our software rescue service: audit first, a written verdict, then a fixed price for the agreed list of fixes. If our estimate is wrong, the extra hours are our cost. Changes you ask for along the way are scoped and quoted separately before work starts. After the rescue, many clients keep going with a dedicated development team on monthly terms.

A realistic takeover timeline

Every project is different, but a healthy takeover of a typical product usually follows this shape:

1. Before notice: secure accounts, the repository and the IP clause.
2. Handover period: collect secrets, documentation, backups and recorded walkthroughs.
3. First one to three weeks: audit, reproduce the build and deployment, rotate secrets, add error tracking.
4. Next phase: fix security, data and payment issues, add tests to the critical paths.
5. Then: resume the roadmap, now on code you understand and can change safely.

It is not glamorous, and the first weeks produce few visible features. That is fine. Those weeks are what turns a stalled project into one that ships again.

The short version

• Secure accounts and the repository before you give notice.
• Ask for a written, itemised handover and record walkthrough sessions.
• Audit before you build, and reproduce deployment from a clean machine.
• Fix security, data and payments first.
• Prefer fixing over rebuilding unless the core is wrong.
• Quote the rescue as a fixed scope, then move to a steady team.

If you are stuck with a stalled or abandoned codebase, start with a free code audit. A senior engineer reads your code and tells you in writing what is healthy, what is risky, and whether to keep, refactor or rebuild. If you want us to do the fix, you get a fixed quote for it. If you do not, the audit is still yours to keep.

FAQ

Can I switch software development companies in the middle of a project?

Yes, and it is more common than vendors admit. The safe order is to secure ownership of every account and the repository first, get an independent audit of the code second, and only then give notice. Switching mid-project costs time, but continuing with a vendor that keeps missing dates usually costs more.

Who owns the code if I stop working with my developer?

It depends on your contract. Many agreements assign IP only on full payment, so read the clause before you act. If the IP is yours, ask for the repository to be transferred to your own GitHub or GitLab organisation. If the contract is unclear, settle outstanding invoices or negotiate a written assignment before the relationship turns sour.

What should a software handover include?

Full repository history, every environment variable and secret, admin access to cloud, domain, DNS, email, payment and app store accounts, database backups, documentation of the deployment process, a list of third-party services and their owners, open bugs, and at least one recorded walkthrough session with the engineers who built it.

How long does it take a new team to take over a codebase?

For a typical product, expect the first one to three weeks to go into access, an audit, rebuilding the deployment pipeline and fixing the most dangerous issues. Feature work speeds up after that. Anyone promising full speed on day one has not read the code yet.

Should we fix the existing code or rebuild from scratch?

Fix it in most cases. Rebuilds take longer than everyone expects and throw away the edge cases the old code already handles. Rebuild only when the core data model is wrong, the stack is abandoned or insecure at its foundation, or fixing would touch most of the code anyway. An audit should give you that verdict with reasons.

What if the previous vendor refuses to cooperate?

If you own the accounts and the repository, you can take over without them, it just takes longer to reverse-engineer deployment and integrations. If they hold the accounts, check your contract, document every request in writing, and get legal advice early. This is exactly why account ownership comes first in the checklist.

How much does a software project rescue cost?

It depends on the size and state of the code. Enterprise rescue vendors publicly quote six-figure fixed scopes, while smaller products often need a focused fix of a few weeks. Start with an audit, then get a fixed quote for a defined list of fixes so the rescue itself does not become another open-ended project.