A software project is not finished when the last feature ships. It is finished when your own people, or the next vendor, can run it, change it and recover it without calling the team that built it. The handover pack is how that is proved, and it is the part of a project most often skipped, because by the time it is due everyone is thinking about the next thing.
This is the list we hand over at the end of every build and at the end of every retainer. Use it as a checklist for any vendor.
1. The repository, in your account
The source code lives in a repository your organisation owns, with the full history, from the first week of the engagement rather than the last. If the code has been in the vendor's account, a transfer at the end loses nothing technically but tells you something about the relationship. Check that every branch that matters is merged or documented, that tags mark each release, and that the vendor's access is what the contract says it should be after handover.
2. A build that works from a clean machine
Someone who has never seen the project should be able to clone it, follow the README and run it locally within an hour. That means the README states the runtime versions, the environment variables, the commands, and the test data setup. The best proof is a recording of a new engineer doing exactly that; the second best is a pipeline that builds from scratch on every commit, which most projects already have.
3. The infrastructure as code, and the accounts
Cloud resources defined in code, in the repository, and the cloud accounts in your name with the vendor as a member rather than the owner. Domain registrations, DNS, certificates, email sending domains and app store accounts all follow the same rule: your organisation owns them, the vendor has the access it needs. Moving these later is possible and always slower than expected.
4. The keys
Every secret the system uses, in a secrets manager you control: database credentials, API keys for third-party services, signing certificates, upload keys for the app stores, webhook secrets. Plus a list of which secret is used where, so a rotation does not become an archaeology project. Secrets pasted into a document are not a handover; they are a breach waiting to happen.
5. The runbook
A short document that answers the questions asked at two in the morning: how to deploy and roll back, how to see logs and metrics, what the alerts mean and who receives them, how to restore from a backup, and how to scale up under load. Each procedure should have been run at least once by someone other than its author.
6. The architecture note and the data model
One page that says how the system is put together and why, with a diagram, and a description of the main tables or collections and how they relate. Not a design document from the start of the project; the version that describes what was actually built, updated after the last change.
7. The test suite and how to run it
Automated tests that pass in the pipeline, with a note on coverage and on what is deliberately not tested. If there are manual test scripts for release checks, they belong here too. A suite that only the vendor knows how to run is not yet yours.
8. Third-party services and their bills
A list of every external service the system depends on: hosting, email, SMS, maps, payments, monitoring, analytics, AI providers. For each, the account owner, the plan, the monthly cost, the renewal date and what happens if it stops. This list is the one most often missing and the one that causes the first surprise invoice.
9. Open issues and known limits
The honest list of bugs not fixed, features not finished, performance limits and security items deferred, with the vendor's assessment of each. A project with an empty list has not been looked at closely.
10. Access review and offboarding
Confirmation that the vendor's access has been reduced to what the support arrangement needs, that shared accounts have been retired, and that every remaining account is a named person. Ask for the list of who still has access to what, and put a date on when it will be reviewed again.
11. The support arrangement
Who to call, for what, at which hours, and what it costs. Whether that is a retainer with an SLA, an hourly arrangement or nothing at all, it should be written down so that the first incident after handover is not also the first negotiation. Our maintenance, support and SRE page describes what a retainer covers.
If something is missing
Ask for it before the final invoice, because your position changes the day after. If the vendor cannot produce an item, ask why; the answer tells you what state the system is in. And if you are taking over a system from somewhere else, use this list as the audit: the gaps are the first month's work.
How long it takes
A handover pack is not a document written in the last week. Most of it accumulates through the build: the repository from week one, the runbook from the first deployment, the architecture note updated at each demo, the third-party list from the day each service was added. What remains at the end is a review, a recorded walkthrough for the people taking over, and the access changes. Budget two to three days of the team's time for that review on a typical build, and a day of your own people's time to receive it. A vendor that quotes weeks for handover at the end has been carrying the documentation as debt.
How it fits the process
Handover is the last artifact of the launch stage in our six-stage process, and the runbook and the access review are checked again at the end of every retainer period.
