Software Vendor Takeover: A Handover Checklist

Taking over a software project from another vendor goes well when you secure ownership before you announce anything. In order: get admin access to the code repository with its full history, move every cloud, domain, app store, and third-party account into your company's name, collect the credentials and configuration for each environment, take a database backup and prove that it restores, and get hold of the signing keys and build pipelines. Only then give notice.

The order matters because your position is strongest while the outgoing vendor still expects to be paid, and because a few of these items cannot be recreated once they are lost. The sections below cover each item, then the contract, the handover meeting, and the incoming team's first week.

Secure Access Before You Give Notice

Most outgoing vendors behave professionally. Some do not, and you will not know which kind you have until the conversation happens. Everything in the next four sections can be done quietly and framed as housekeeping, and none of it damages a vendor relationship that turns out to be fine.

Keep a plain spreadsheet with five columns: the asset, where it lives, who owns the account today, who has admin rights, and whether someone on your side has personally logged in and confirmed it. People skip the last column.

The Code Repository and Its History

Ask for owner or admin rights on the repository itself, inside an organization account your company controls on GitHub, GitLab, or Bitbucket. A zip file of the latest code is a poor substitute. The commit history shows why things were done and when each bug arrived.

Once you have access, make your own copy. A mirror clone (git clone --mirror) brings down every branch and tag. It does not bring issues, pull request discussions, wikis, or CI secrets, because those live on the hosting platform and have to be exported or transferred separately. If the vendor hosts the repository under their own organization, ask them to transfer it to yours, which keeps the issues and the history together.

Check whether there is more than one repository. Mobile apps, the backend, the admin panel, and infrastructure scripts are often kept apart, and the one nobody mentions tends to be the one you need on deployment day.

Accounts That Must Be in Your Company's Name

Code can be rewritten. Accounts are harder to replace, because customers and payment history are attached to them.

Cloud, Domain, and DNS

The cloud account should be owned by an email address on your company domain, with your company's payment method on it. If the vendor runs your servers inside their own account alongside other clients, plan a migration into an account of yours.

The domain is the asset we worry about most. Whoever controls the registrar account controls your website, your email, and every password reset that goes to that email. Log in to the registrar yourself and confirm that the registrant is your company. Do the same for the DNS host, which is frequently a different provider.

App Store Accounts

Apple and Google developer accounts should be organization accounts in your company's legal name. For Apple, that means enrolling as an organization (Apple asks for a D-U-N-S number to verify the legal entity) and having a company officer hold the Account Holder role.

If your app is currently published under the vendor's developer account, both stores provide an app transfer process that moves the listing to your account and keeps its reviews and users. It needs the cooperation of the current account owner, which is one more reason to arrange it before anyone is upset.

Third-Party Services

List every outside service the product calls: payments, email, SMS, push notifications, analytics, maps, error tracking. Each account should belong to your company. Payment processors deserve particular care, because the account is tied to a verified legal entity and a bank account, and it must be yours.

Credentials, Backups, and the Restore Test

Credentials and Environment Configuration

Every environment (production, staging, and anything else) has configuration that is deliberately kept out of the repository: database passwords, API keys, webhook secrets, encryption keys. Ask for all of it, per environment, delivered through a password manager and never pasted into email or chat.

Plan to rotate these secrets with the incoming team once the handover is complete, since people outside your company have seen them.

Database Backups and the Restore Test

Ask where backups are stored, how often they run, and who gets the alert when one fails. Then ask for a recent backup file, or a snapshot shared to your own cloud account.

A backup that has never been restored proves nothing. Have someone restore it to a scratch server and compare a few facts with production, such as the number of customers and the time of the most recent order. Backups turn out to be empty, or to be of the wrong database, or to come from a job that stopped running months ago, more often than anyone expects. User uploads and other files usually live outside the database, so check that they are backed up as well.

Signing Keys, Build Pipelines, and Design Files

Build Pipelines and Signing Keys

Get admin access to the CI/CD pipeline. Most CI systems will not let you read stored secrets back out, so those have to come from the vendor separately.

Android signing deserves its own paragraph because the consequences are permanent. With Play App Signing, which recent apps use, Google holds the app signing key and the developer holds an upload key. A lost upload key can be reset by the account owner through Google Play support. Older apps that never enrolled are signed with a keystore held only by the developer. If that keystore or its password is lost, the app can never be updated again under the same listing, and the only route is to publish a new app and ask users to move. Find out which situation you are in, and get the keystore file with its passwords.

Apple is more forgiving. Distribution certificates and provisioning profiles can be revoked and recreated by whoever controls the developer account, so account ownership is what counts.

Documents, Designs, and the Backlog

Ask for the design files with ownership of them, not a view link. In Figma, that means moving the files into a team your company owns. Export the ticket history from Jira, Trello, or whatever was used, because it records the known bugs. Collect whatever documentation exists and expect it to be thin. The handover meeting is where you fill the gaps.

What Your Contract Should Say

Read the contract before you talk to the vendor, ideally with a lawyer, and treat what follows as a list of things to look for, not legal advice. Look for an intellectual property assignment or work-for-hire clause stating that the code and designs belong to you, and check whether it is conditional on invoices being paid in full. Note the notice period. See whether the vendor has any stated obligation to assist with a handover. Look for anything the vendor licenses to you instead of assigning, such as their own internal framework. If the contract is silent on handover, negotiate a short paid transition period. Paying for the outgoing team's cooperation is nearly always cheaper than reverse-engineering the system.

The Handover Meeting and the First Week

Running the Handover Meeting

Have the incoming technical lead in the meeting, record it with everyone's consent, and ask the outgoing developers to share their screen and perform a production deployment from start to finish.

Then ask about the things that are never written down. Which parts of the system are fragile. What is done by hand on a schedule, such as renewing a certificate or running a month-end script. Which background jobs exist and where they run. What they would fix first if they were staying. Most developers answer these questions honestly when asked with respect, and the answers save weeks.

What the Incoming Team Does First

A competent new team does four things before it writes any features. It gets the project building on a clean machine using only the repository and the documents, and writes down every step that was missing. It reproduces the production deployment into a staging environment, which proves the pipeline and the credentials work. It inventories the dependencies and their versions, noting anything out of support. And it identifies the knowledge that lived in one person's head, then gets it onto paper while that person still answers messages.

Only after that should the team commit to estimates, because a number given before the code builds locally is a guess.

When the Old Vendor Is Hostile or Gone

Start with what you can recover without them. Domain registrars and cloud providers have recovery processes for a company that can prove ownership through invoices and registration documents. Apple and Google support can help when the developer account is in your company's name. If you have no source code at all, the production servers still hold a great deal, including the database and, for interpreted languages, the deployed backend code.

If the vendor is holding assets back over a payment dispute, get legal advice early and keep the communication in writing. Meanwhile, back up everything you can already reach.

Common Mistakes

The most expensive mistake is announcing the switch before securing access. The second is letting a vendor's personal accounts own production systems for years because it was convenient at the start. The third is skipping the restore test. People also underestimate the transition, since any incoming team spends its first weeks reading before it writes.

Lionasys Technologies, based in Ahmedabad, India, and founded in 2010, takes over software, AI, IoT, mobile, and game projects from other vendors. The initial rescue audit is free and takes one to two days, a written recovery plan follows in three to five days, and a dedicated team is in place within about a week. If you are preparing a switch, get in touch before you give notice and we will go through this checklist with you.