A hosting handover runbook should let another authorised operator understand the service, perform routine checks and escalate an incident without relying on the original administrator's memory.
IN THIS ARTICLE
01 Write the service record
- Identify the customer or service group, billing service IDs, provider account and technical resources. Record production and test environments separately.
- Describe normal operation: expected availability checks, scheduled jobs, renewal dates, resource limits and the dashboards that show them.
- Record access methods and secret-store references. Include who can approve emergency access, but keep passwords and recovery codes in the approved protected system.
- Document the common tasks with their prerequisites, exact target, expected result and verification. Link to the current platform guide rather than copying a long command sequence that may become stale.
- Describe failure recovery: backup locations, restore scope, recovery dependencies and the point at which provider assistance is required.
- List active exceptions, customisations and upcoming commitments. Include temporary billing overrides, unusual DNS arrangements and customer-approved maintenance windows.
- Give the recipient the runbook and ask them to complete a safe representative task, such as tracing a service's latest successful backup or locating a failed provisioning log.
02 Close the handover
Record the recipient, review date and unresolved gaps. Confirm that the operator can reach the necessary provider and billing interfaces with their own authorised account. A runbook is incomplete if it depends on a former employee's mailbox or phone for recovery.
Update ownership when a service changes teams. Retire temporary access and transfer open tickets, alerts and renewal reminders to the new owner. Keep the change history so future operators can understand why an unusual setting exists.
Common questions
Should the handover include every server setting?
Include the information required to operate and recover the service, with links to authoritative configuration records. A large unreviewed dump can obscure the few details an operator urgently needs.
How do I know the runbook is usable?
Have a different authorised operator follow a representative procedure and record missing assumptions. Their ability to complete and verify the task is better evidence than the document's length.