ChecklistCustom Software Development
Software handover checklist: what to receive from a vendor, and how to verify it
A handover is complete when your team can build, run, fix and change the system without the people who wrote it. Documents alone do not prove that. This checklist lists what an external team should transfer, grouped by area, and pairs each item with a practical check, ending in four acceptance tests: rebuild from scratch, restore from backup, a rehearsed incident and a first unaided release.
On this page
- Why handovers fail when the documentation looks complete
- Four acceptance tests that prove a handover worked
- Code, infrastructure and delivery pipelines
- Documentation a newcomer can actually work from
- Quality and security evidence to inherit
- Operations: runbooks, alerting and on-call
- Access, secrets and account ownership
- Intellectual property and open-source licences
- From pairing period to the first unaided release
- Questions and answers
- Sources
Why handovers fail when the documentation looks complete
Failed handovers usually share three causes. Knowledge lives in people: the outgoing engineers know which alert is noise and which means the disk is filling, and none of it is written down. Access lives in the wrong accounts: the domain, cloud billing, CI service or signing keys belong to someone about to leave. And runbooks are untested: they describe how recovery should work, but nobody has followed them since the system last changed.
The checklist is written from the receiving side and works with any supplier. It mirrors the deliverables ColdAI hands over at the end of a build, but every item is phrased as something your team can verify for itself.1
Four acceptance tests that prove a handover worked
Schedule these before the outgoing team leaves. Each exposes gaps a document review would miss.
| Test | What it proves | Passes when |
|---|---|---|
| Rebuild from scratch | Infrastructure code and pipelines are complete and yours | Your engineers create a working environment in a clean account from the repositories and documented secrets alone |
| Restore from backup | Data can be recovered within the agreed recovery targets | A timed restore into the rebuilt environment yields a consistent system, and the time is recorded |
| Rehearsed incident | Alerts, dashboards and runbooks work for people who did not write them | Your on-call engineer resolves a staged fault from the runbook while the outgoing team only observes |
| First unaided release | Your team can change the system safely | A real change goes from ticket to production through the pipeline, with a rollback plan, led by your engineers |
Code, infrastructure and delivery pipelines
Documentation a newcomer can actually work from
Quality and security evidence to inherit
Operations: runbooks, alerting and on-call
Access, secrets and account ownership
Intellectual property and open-source licences
From pairing period to the first unaided release
Shadow
Your engineers join stand-ups, reviews and releases, and read the design document and decision records with the outgoing team on hand.
Pair
Your engineers make changes with an outgoing engineer beside them, including a release and an on-call shift.
Reverse-shadow
Your team leads releases and incidents while the outgoing team watches and steps in only when asked.
Run the acceptance tests
Rebuild, restore and the rehearsed incident, with every gap logged and closed.
Release unaided and transfer the backlog
Ship a real change without help, then take over the deferred-work backlog and technical-debt register with each item's context.
Questions and answers
How long should a software handover from a vendor take?
Long enough to complete the pairing stages and pass the acceptance tests, which depends on the system's size, how many teams it touches and how familiar your engineers are with its stack. Plan the handover in the original contract rather than at the end, and tie completion to the first unaided release, not a calendar date. A handover that ends on schedule but fails that test has not finished.
What if the outgoing vendor will not cooperate with the handover?
Secure access first, using whatever contractual rights you have: repositories, cloud accounts, domains and secrets. Then learn from the system itself. Rebuild environments from the infrastructure code, read the pipeline definitions, study logs and incident history, and reconstruct the key decisions as records. Expect the first months to be slower and add monitoring, because undocumented behaviour will surface in production.
Who should sign off a software handover?
The person accountable for running the system, usually an engineering manager or product owner, with input from security and operations. Base sign-off on the acceptance tests, with any open items listed, owned and dated. If the outgoing team stays for a support period, define its scope and end date in the sign-off so nobody is unsure who answers the next incident.
Is it still a handover if the vendor keeps operating the system?
Not really. If the external team continues to run the system, you need an operating agreement with defined responsibilities and response times instead. The checklist still applies, because you should hold the code, accounts and documentation whoever operates. If operations are moving the other way, from your team to a provider, the operations transition plan covers that route.