# Software handover checklist

What you should have in your hands when a software project ends. Agree this
list in writing before the work starts, test it halfway through, and tick it
off before the final invoice.

From Averolt · https://averolt.com/handover-template/

---

## 1. The source code, with its history

- [ ] Full repository with commit history (not a zip or a final snapshot)
- [ ] Repository owned by our organisation, builder invited as a collaborator

## 2. Setup instructions someone else has followed

- [ ] Written steps from a clean machine to a running copy
- [ ] Followed successfully by someone outside the original team
- [ ] Environment variables and secrets listed (names, not values), with where each lives

## 3. The accounts, in our name

- [ ] Hosting
- [ ] Domain and DNS
- [ ] Database
- [ ] Payment processor
- [ ] Error tracking and monitoring
- [ ] App store listings (Apple, Google), if there is an app
- [ ] Every account created by us, with the builder invited rather than owning it

## 4. A runbook for how it runs

- [ ] What runs where
- [ ] What talks to what (integrations, third-party services)
- [ ] What happens when it breaks, and the first things to check
- [ ] Who to call

## 5. Tests on the journeys that matter

- [ ] Signing up or logging in
- [ ] Paying, if the product takes money
- [ ] The core thing the product does
- [ ] Tests run as part of every deploy

## 6. The decision record

- [ ] Why the main technologies were chosen
- [ ] Why each integration works the way it does
- [ ] What was tried and abandoned, and why

## 7. What happens next, in writing

- [ ] Either: a support arrangement with an agreed scope and response expectation
- [ ] Or: a clean exit, with everything above handed over
- [ ] A recorded handover session covering deploying, monitoring and the three things most likely to break
- [ ] Someone on our side has deployed the system successfully at least once

---

A fair test for any proposal: "If we parted ways the week after launch, what
exactly would we have?" A good answer is specific and slightly boring.