Software Vendor Handover Checklist: Code, Access, Documentation and Ownership
A checklist for taking over software from a vendor: code and IP, infrastructure, credentials, domains, app stores, data, documentation and verification.
What should a software handover include?
A complete handover transfers source code with history, every account and credential (cloud, domains, app stores, third-party services), data and backups, build and deployment pipelines, monitoring, documentation and runbooks, and open issues, followed by knowledge transfer sessions and verification that a new team can build, deploy, restore and operate the system alone. Then rotate all credentials. Contracts decide ownership, so involve a lawyer early.
This guide is for business owners and technical leads changing vendors, bringing work in-house or ending a contract. For ongoing support arrangements, see software maintenance contracts.
Key takeaways
- Own your accounts from day one where possible.
- Check IP and licences in the contract before the handover.
- Use a written checklist with owners and dates.
- Verify by building, deploying and restoring without the old vendor.
- Rotate every credential afterwards.
Handover checklist
| Area | What to receive or confirm |
|---|---|
| Code | All repositories with full history, branches, tags; build instructions; licences of dependencies |
| Intellectual property | IP assignment per contract; third-party and vendor component licences (legal advice) |
| Infrastructure | Cloud accounts or admin access, infrastructure as code, environment list |
| Credentials | Inventory of secrets and where they live; plan to rotate |
| Domains and certificates | Registrar access, DNS, certificate renewal, email sending records |
| Third-party services | Payment, email, SMS, maps, analytics, monitoring accounts and billing |
| App stores | Apple and Google developer accounts, signing keys and certificates |
| Data and backups | Database access, backup locations, a tested restore |
| CI/CD | Pipelines, runners, deployment permissions |
| Documentation | Architecture, runbooks, known issues, decisions, onboarding notes |
| Operations | Monitoring, alerts, on-call contacts, incident history |
Knowledge transfer
Schedule sessions covering architecture, codebase walkthrough, deployment, operations and incidents, and record them. Ask for written answers to recurring questions. Pair the new team with the previous one on at least one real release and one support issue if the relationship allows. Agree a short period during which the previous vendor answers questions.
Verifying the handover
- Build the application from a fresh clone on a clean machine using the documentation.
- Deploy to a test environment through the pipeline.
- Restore a database backup to a test environment.
- Release a small change to production.
- Renew or confirm automatic renewal of certificates and domains.
- Rotate credentials and remove the previous vendor's access; see secrets management.
Hypothetical example: a booking app
This example is hypothetical. A tourism operator moved its booking web app and mobile apps to a new supplier. The checklist found that the app store accounts and the payment provider account were registered to the previous agency, and that there were no infrastructure scripts. The operator's lawyer confirmed IP ownership under the contract, the accounts were transferred through the stores' processes, the new team recreated infrastructure as code, restored a backup and shipped a release before the previous agency's access was removed and all keys were rotated.
Common mistakes
- Accounts registered in the vendor's name.
- Receiving a code zip without history.
- Missing app signing keys.
- Forgetting domains, DNS and email records.
- Not rotating credentials after the vendor leaves.
Related guides
- Software architecture review for assessing what you inherit.
- Infrastructure as code for reproducible environments.
- Open-source software audit for licences.
- Software team augmentation for adding capacity after handover.
Conclusion
A good handover leaves you able to build, deploy, restore and operate the software without the previous vendor. Own your accounts, check IP and licences, follow a checklist, verify with real tasks and rotate every credential.
Taking over software from another vendor?
ZSpace Labs is an India-based, remote-first technology studio working with Australian and international businesses on web applications and mobile apps, including software built by other teams. If it would help to plan a handover, we are happy to talk it through.
Common questions.
Source code and full history, infrastructure and cloud account access, credentials and secrets (then rotated), domains, DNS and certificates, third-party service accounts, app store accounts, data and backups, documentation and runbooks, CI/CD pipelines, monitoring, and a list of open issues and known risks.