Projects end; relationships change; vendors get acquired or disappear. The handover checklist is how you make sure that what you paid for is actually yours — runnable, changeable, and safe — before the last invoice clears. Run it at every engagement end, and ideally quarterly during long engagements.
Code and repositories
- Repository in your organization account (GitHub/GitLab) — should have been true from day one; verify admin rights now.
- All branches merged or documented; no critical code living only on someone's laptop.
- Build runs from a fresh clone following written setup steps — have someone not from the vendor prove it.
- Dependency manifest current; no private packages you cannot access.
Credentials and services (the hostage list)
- Domain registrar, DNS, hosting, database, email/SMS/WhatsApp providers, payment gateways, cloud consoles, analytics, app store accounts — each in accounts you own, with vendor access removable per the offboarding discipline.
- Secrets/environment variables documented and transferred securely (a secrets manager, not a WhatsApp message).
- Billing on your cards — vendor-paid services are silent time bombs that detonate on relationship end.
Documentation minimum
Architecture overview (one page suffices), setup/deploy runbook, third-party service list with purposes, API documentation if applicable, and known-issues/debt register (the honest ledger). Ask for the "bus-factor document": what would a new team need to know first?
Operational continuity
- Backups running to your storage, restore rehearsed once during handover.
- Monitoring/alerts pointed at your contacts.
- Maintenance arrangement decided — new retainer, new vendor, or documented in-house plan — before the old one ends, not after the first incident.
The ownership test (run it, literally)
A competent developer who has never seen the project can: clone, install, run locally, make a trivial change, and deploy it — using only the handover materials. If that test passes, you own your software. If it fails, the gap list is your remaining handover scope; do not sign off until it passes.
Inheriting a project mid-flight, or exiting a vendor relationship? We run handover audits — one week, fixed price, and the test above performed by us so you know exactly where you stand.
Frequently asked questions
What should a software handover include?
Repositories in your organization with admin rights, every service credential in accounts you own with billing on your cards, secrets transferred securely, a documentation minimum (architecture, runbook, service list, debt register), and backups plus monitoring pointed at you.
How do I verify I actually own my software?
The ownership test: a competent developer who has never seen the project clones, installs, runs, makes a trivial change, and deploys — using only handover materials. Pass means ownership; the failure gaps are your remaining handover scope.
What are the most commonly missed handover items?
Vendor-paid services that expire silently after the relationship ends, secrets shared informally instead of transferred, app store and DNS accounts in vendor names, and no rehearsed backup restore. Each is a future emergency scheduled quietly.
When should handover happen?
Structurally from day one — repos and accounts in your name throughout — with the full checklist run at engagement end and ideally quarterly during long engagements. Handover discovered at relationship breakdown is negotiation, not handover.