The short answer
Require the handover to be demonstrated rather than delivered. Your developer makes a real change, deploys it, and resolves a simulated failure, with the supplier only answering questions.
Everything else on the list below is preparation for that. If it cannot be done, the handover is not finished regardless of what was delivered.
What to require
- All code in repositories you own, with full history
- Infrastructure defined as code, not clicked into a console
- Every credential in company accounts rather than personal ones
- Documented build, test and deploy steps that someone has followed
- An architecture overview with the reasoning, not just the diagram
- Known issues, unfinished work and the things they would fix next
The third item is the one that bites later. Domains, certificates, cloud accounts and third-party services registered to an individual become a problem at renewal, not at handover.
Things that quietly stay behind
| Item | How it gets missed |
|---|---|
| Scheduled jobs | Run somewhere nobody documented |
| Monitoring and alerts | Go to the supplier's address |
| Third-party accounts | In a developer's name |
| DNS and certificates | Managed by the supplier's registrar |
| Environment variables | Set by hand, not in code |
Go through this list explicitly. Each one is invisible until it fails, and each one fails eventually.
Test the handover
- Your developer sets up locally from the documentation alone.
- They make a small real change and get it to production.
- They resolve a simulated failure using the runbooks.
- They restore from a backup into a test environment.
- Anything that needed help goes back into the documentation.
Step four is skipped almost universally and is the one that matters most when it matters at all. A backup that has never been restored is a hope.
Budget for the dip
Your team will be slower on this system than the people who built it, for months. That is not a handover failure, it is unfamiliarity, and planning for it avoids treating a normal ramp-up as a crisis.
Keep a small retainer with the original supplier for questions if you can. It is cheap relative to the alternative and it shortens the dip considerably.
Keep the documentation alive
Handover documentation is accurate on the day it is written and decays from then. Make updating it part of changing the system rather than a separate task nobody does.
The practical test is the same one as before: could a new person set this up and deploy a change from what is written? Ask it every few months.