A handover is complete when the next team can operate the system safely. Repositories alone are not enough if deployment, access, data recovery and third-party ownership remain in someone else’s memory.
Access and ownership
List repositories, cloud accounts, DNS, email delivery, payment providers, app stores, monitoring and analytics. For each one, record the business owner, technical owner and recovery contact.
Environments and secrets
Document how development, staging and production differ. Keep secrets out of documentation, but record their purpose, rotation owner and where they are managed. Rotate credentials held by departed staff.
Build and deployment
Write the current runtime, dependency, build and deployment steps. Include background jobs, schedulers, queues, storage and rollback behaviour. A deployment that cannot be rehearsed is not a handover.
Data and external dependencies
Identify databases, backup schedules, restore tests, key data flows and integration contracts. Capture sanitised fixtures for important APIs so the next team can test without relying on production.
Critical workflows
Describe the flows that affect money, access, customer communication and inventory. Include expected outcomes, operational signals and the first place to look when each flow fails.
Common failure mode
Do not treat a folder of credentials or a screen recording as documentation. A handover needs named owners and a tested recovery path.
Related services
For a controlled handover and recovery review, see Existing Project Rescue & Stabilisation.