Prepare a handover properly
Prepare a handover as a transfer of capability and accountability, not just files and meetings. Make sure the receiving side can actually operate, decide, and recover safely.
- Situation
- Knowledge, ownership, or operational responsibility needs to transfer from one person or team to another.
- Goal
- Ensure continuity of operation and ownership when responsibility moves between people or teams.
- Do not use when
- the transfer is informal and low-risk enough that full handover would be overkill
- Primary owner
- sending owner and receiving owner jointly
- Roles involved
sending ownerreceiving ownerengineering manager or directoron-call respondersSRE or operations where relevant
Context
The situation
Deciding whether to reach for this playbook: when it fits, and when it doesn't.
Use when
Conditions where this playbook is the right tool.
- A service or system is changing owning team
- A key engineer is leaving or rotating off
- An acquisition, reorg, or project transition shifts operational load
- A vendor or platform handoff is happening
Stakes
Why this matters
What this playbook protects against, and why skipping or half-running it tends to be expensive.
Bad handovers create ghost ownership: the sender assumes it is over, the receiver is not ready, and the system becomes less safe in the exact period when confidence is most needed.
Quality bar
What good looks like
The observable qualities of a team or system that is actually doing this well. Not just going through the motions.
Signs of the playbook done well
- The receiving side can explain the system, common risks, and escalation paths
- Ownership artifacts, access, and operating routines are transferred
- Live shadowing or paired practice happens before the sender fully exits
- The sender’s hidden responsibilities become visible before they disappear
Preparation
Before you start
What you need available and true before running the procedure. Skipping this is the most common reason playbooks fail.
Inputs
Material you'll want to gather first.
- System overview
- Runbooks and service docs
- Incident history
- Release and rollback practices
- Ownership and dependency map
- Access and tooling inventory
Prerequisites
Conditions that should be true for this to work.
- A real receiving owner exists
- The sender can describe what they actually do beyond what docs claim
- Time is reserved for shadowing and transfer
Procedure
The procedure
Each step carries its purpose (why it exists), its actions (what you do), and its outputs (what you produce). Read the purpose. It's what keeps the step from degenerating into checklist theatre.
Map what is actually being handed over
Avoid transferring only the obvious parts.
Actions
- List systems, services, incident roles, review responsibilities, and release duties involved
- Capture hidden dependencies, critical contacts, and known traps
- Compare formal ownership with actual work performed
Outputs
- Handover scope map
Package operational memory
Move knowledge into durable forms before the sender leaves.
Actions
- Refresh runbooks, service maps, dashboards, and escalation notes
- Document why and when things are done, not only the commands
- Identify what is still missing or low trust
Outputs
- Handover knowledge pack
Transfer through live work
Build actual operating confidence.
Actions
- Shadow deployments, incidents, investigations, or support flows together
- Have the receiver lead with the sender observing where safe
- Practice common and high-risk scenarios
Outputs
- Live transfer log
Switch authority and routing explicitly
Make the operating system match the handover story.
Actions
- Change service catalog, on-call, escalation paths, review expectations, and support routes
- Communicate the new ownership model clearly
- Remove ambiguous fallback assumptions
Outputs
- Ownership cutover record
Review post-handover stability
Check that the transfer worked in practice.
Actions
- Review first incidents, deploys, and escalations after cutover
- Capture remaining gaps quickly
- Close the handover only when operational confidence is visible
Outputs
- Post-handover review
Judgment
Judgment calls and pitfalls
The places where execution actually diverges: decisions that need thought, questions worth asking, and mistakes that recur regardless of good intent.
Decision points
Moments where judgment and trade-offs matter more than procedure.
- What hidden responsibilities must be made visible before transfer?
- What must be practiced live versus documented?
- When is the receiver ready enough for full authority?
- What fallback support remains temporarily after cutover?
Questions worth asking
Prompts to use on yourself, the team, or an AI assistant while running the procedure.
- What does the sender actually do that is not visible in official ownership?
- What must the receiver practice live before cutover?
- What would expose a weak handover in the first week?
Common mistakes
Patterns that surface across teams running this playbook.
- Equating handover with document sharing
- Declaring transfer complete before the receiver has led live work
- Keeping old routing paths alive indefinitely
- Failing to make hidden dependencies explicit
Warning signs you are doing it wrong
Signals that the playbook is being executed but not landing.
- The receiver still relies on the sender for real-time reassurance in normal operations
- Ownership systems and org language diverge after cutover
- First post-handover incident reveals missing basics
- The sender still informally does the hard parts
Outcomes
Outcomes and signals
What should exist after the playbook runs, how you'll know it worked, and what to watch for over time.
Artifacts to produce
Durable outputs the playbook should leave behind.
- Handover scope map
- Handover knowledge pack
- Live transfer log
- Ownership cutover record
- Post-handover review
Success signals
Observable changes that mean the playbook landed.
- The receiving side handles normal operations independently
- First incidents and releases route correctly
- Handover gaps become visible early and shrink quickly
- The sender is no longer silently carrying the system
Follow-up actions
Moves that keep the playbook's effects compounding after it finishes.
- Update onboarding and runbook materials from handover lessons
- Review whether the new owner needs more authority or support
- Capture repeat handover patterns as team-level guidance
Metrics or signals to watch
Longer-horizon indicators that the underlying problem is receding.
- Post-handover escalation dependence on sender
- Time to resolve first operational events after transfer
- Handover gap count found in first month
- Owner-routing accuracy after cutover
AI impact
AI effects on this playbook
How AI-assisted and AI-driven workflows help execution, and the ways they can make it worse.
AI can help with
Where AI tooling genuinely reduces the cost of running this playbook well.
- Assembling docs, dashboards, and incident summaries into a first-pass pack
- Summarizing repeated operational patterns from history
- Extracting hidden tasks from chats and ticket trails
AI can make worse by
Distortions AI introduces that make the underlying problem harder to see.
- Making the handover pack look more complete than it is
- Creating polished summaries that the receiver trusts too quickly
- Obscuring which parts were never validated in live operation
Relationships
Connected playbooks
Failure modes this playbook tends to address, decisions behind the situation, red flags that motivate running it, and neighboring playbooks.