Most bad handovers are not malicious, they are unscheduled. The work ends, the team moves, and the knowledge leaves in someone's head.
We treat it as a sprint
Handover gets planned time and a definition of done. The test is simple and we run it for real: someone who did not build the system takes it from zero to a deployed change.
What has to exist
- A README that gets a new machine running, verified by someone new that week.
- The deployment path, written down, including how to roll back.
- Environment variables listed with what each is for and who owns the account.
- A restore test: take the backup, restore it somewhere, prove it works.
- The three things most likely to break, and what to do about each.
Credentials are the smallest part
Access can be granted in ten minutes. The expensive knowledge is the decisions: why the queue is separate, why that table is denormalised, which integration lies about its rate limit.
If the only place a decision is recorded is a person, it isn't recorded.
The recurring gaps
In the audits we do of other teams' systems, the same four gaps appear: no tested restore, one person who is the only route to production, business rules duplicated between the app and the database, and a large test suite that does not fail when the product breaks.
None of those are reasons to panic. All of them are reasons to plan a week.