Switching software vendors: a handover checklist to take back your code

Why the handover deserves its own plan

The risky part of a vendor change is the gap between teams. If the outgoing vendor holds the only admin login to your cloud account, your domain or your app store listing, you do not fully control your product. A new team can read code. It cannot recover an account it was never given. Treat the handover as its own project, with an owner on your side, a written list and a target date.

Order of operations: what to secure first

1. Build an inventory. List every system the product touches: repositories, cloud accounts, domain registrar, DNS, email sending, payments, analytics and app stores. Use invoices, DNS records and the configuration files in the code to find what nobody wrote down.
2. Put owner access on your side. For every account, make sure a person at your company holds the owner or admin role on a company email address before anything else changes.
3. Take a full copy of the code and data. Clone every repository with its full history and confirm a recent backup of each database sits in storage you control.
4. Then announce the transition. If the relationship is good, involve the vendor early. If it is strained, finish the first three steps quietly where your contract and existing access allow, then give notice.
5. Rotate and remove last. Once the new team can build and deploy, rotate credentials and remove the old vendor's access.

Do not revoke the old vendor's access before you can deploy without them. Locking them out too early can leave a production issue with nobody able to fix it.

Code and repositories

• Move every repository into an organization account your company owns, not a vendor developer's personal account.
• Include all of it: backend, frontend, mobile apps, infrastructure code, scripts, shared libraries and forks.
• Confirm the full commit history and active branches came across, not just a zip of the latest code.
• Ask the vendor to name the exact commit or release running in production, and check that it matches the repository.
• Export build and deployment pipeline definitions, including settings that live only inside the CI/CD tool.

Cloud, hosting and domain accounts

• Cloud accounts on AWS, Google Cloud, Azure or similar should be owned by and billed to your company. If the vendor runs your product inside its own account, plan a migration.
• Confirm the domain is registered to your company and that you can log in to the registrar and change DNS records.
• Secure the Apple and Google developer accounts, plus app signing keys and certificates. Without them, shipping app updates gets hard.
• Cover the supporting pieces too: SSL certificates, CDN, container registries and any servers outside the main cloud account.

Credentials and secrets

• Find where secrets live today: environment variables, a secrets manager, CI settings, config files or a developer's password manager.
• Move them into a password manager or secrets store your company controls.
• Turn on multi-factor authentication for every admin account, tied to your people and devices, not the vendor's.
• Plan to rotate API keys, database passwords and service tokens after the new team has working access. Rotate anything that was ever shared by email or chat.

Third-party services and billing

• List every service the product calls: payments, email delivery, SMS, maps, analytics, error tracking, monitoring, search and AI APIs.
• Move billing to a company card or account so that ending the vendor contract does not shut a service off.
• Check licenses and subscriptions the vendor bought on your behalf and confirm they can be transferred to you.

Data and backups

• Confirm automated backups exist for every production database and file store, and that they land in storage you own.
• Restore a backup into a separate environment to prove it works. A backup nobody has tested is a guess.
• Find every copy of customer data, including staging environments, exported spreadsheets and vendor laptops, and ask for those copies to be deleted once the transfer is complete.

Documentation and knowledge transfer

• Ask for an architecture overview: the main components, how they connect and where each one runs.
• Get written steps for local setup, building, deploying and rolling back. Then have the new team follow them without help.
• Request a list of known bugs, workarounds, scheduled jobs, manual steps and anything that needs a restart from time to time.
• Schedule recorded walkthroughs between the outgoing and incoming teams, focused on deployment, data and the parts of the code that break most often.
• Agree on an overlap period where the old vendor answers questions after the new team takes over.

Contracts and ownership

• Review your agreement for intellectual property assignment, handover obligations, notice periods and the status of work in progress. This checklist is not legal advice, so check your contract and get legal advice for IP assignment questions.
• Ask which components the vendor reused from its own internal libraries or other projects, and what license you have to keep using them.
• Where you can, settle billing disputes separately from the handover so access and knowledge are not held up by an invoice.

After the handover

• Remove the outgoing vendor's accounts from every system and rotate the remaining shared credentials.
• Have the new team ship a small, low-risk change to production to prove the full release path works.
• Review the code, infrastructure and release process honestly before planning big changes. A full rewrite is rarely the right first move.
• Set up monitoring and alerts so problems reach your team before they reach your customers.
• Write code ownership, documentation and handoff terms into the agreement with your next partner from the start. Our FAQ explains how we approach code ownership.

If the product arrives unstable or poorly documented, you are dealing with a rescue, not only a handover. Our software project rescue work starts with exactly this access and review step. If you need a team that stays on the product, see dedicated development teams. For gaps in release flow, infrastructure or observability, see platform scaling and modernization.

Software vendor handover FAQ

Should I tell my current vendor before I secure access?

If the relationship is healthy, tell them early and make the handover a shared plan. If it is strained, first confirm your company holds admin access to the repositories, cloud accounts and domain, then give notice under the terms of your contract.

How long should the old and new teams overlap?

Long enough for the new team to build, deploy and roll back on its own. The right length depends on the size of the product and how much is documented, so tie the overlap to those milestones rather than a fixed date.

What if the vendor will not hand over the code?

Start with what you already control, such as cloud accounts, the domain and any repository access your company holds. Then review your contract for ownership and handover terms, and get legal advice on IP assignment before escalating.

Can a new team take over code with little or no documentation?

Yes, but expect a discovery phase first. The new team reads the code, maps the infrastructure and ships a small change before taking on larger work, writing down what it learns as it goes.

Planning a vendor change or already in the middle of one? Talk through your software challenge and we will start with what you need to secure and what the product needs next.