A software handover checklist that reduces vendor dependence

A project is difficult to maintain when the receiving team gets source code but cannot reproduce a build or explain the business rules. Define the handover requirements at the start and update them as the system evolves. Assign a receiving owner who can verify each item rather than accepting a folder of documents without review.

Inventory repositories, cloud accounts, domains, certificates, package registries and third-party services. Distinguish company-owned accounts from individual developer accounts. Confirm administrative ownership, recovery contacts and billing responsibilities. Rotate shared credentials through an agreed process and remove access that is no longer required after the transition.

Ask the receiving team to build, deploy and roll back using the provided instructions. Include environment configuration, database migrations and scheduled jobs. Test the process in a safe environment before making production changes. A screen recording can help, but it should complement current written instructions that another person can follow independently.

Document major architectural choices, known limitations, important data relationships and difficult business rules. List unresolved defects with severity and workarounds. Explain how alerts are investigated and how common support cases are handled. Good documentation helps a future engineer reason about a change; it does not need to reproduce every function in the codebase.

Specify who responds to incidents during transition, what warranty or support covers and how new work is requested. Conduct a final operational review with product and engineering owners. Record any gaps and their resolution dates. The strongest handover is demonstrated independence: the receiving team can ship a small change, recover from an error and locate the information it needs without relying on informal access to the original developers.

Ask the receiving team to deploy a small change and diagnose a simulated failure using the supplied documentation. The outgoing team should observe first and help when needed. This reveals missing permissions and implicit knowledge more reliably than a walkthrough alone.

• Verify repository and infrastructure ownership.
• Check deployment, rollback and restore instructions.
• Transfer secrets through an approved secure channel.
• Record support contacts and escalation boundaries.

Close the handover with a short list of accepted limitations and remaining actions. Each action needs an owner. Access should be reviewed after the transition so former contributors do not retain unnecessary privileges.