A transition runbook for moving from one delivery vendor to another without losing context, quality, or release momentum.
Vendor transitions are the highest-risk operation in enterprise IT short of an acquisition. The outgoing vendor knows things that aren't written down anywhere, the incoming team is on a learning curve, and the business expects zero degradation in release velocity. This runbook is what we use when we are the incoming vendor on a transition — either replacing another agency or absorbing work from an internal team that is being wound down.
The transition pipeline
Six phases, typically 10–16 weeks total. Skipping or shortening any phase produces measurable cost in the next one.
Phase 1 — Discovery (weeks 1–2)
Goal: understand what exists. Outputs: stakeholder map (who decides what), business-criticality ranking per system, incumbent's pain points (these are also yours after cutover), and a list of every contract, license, and credential involved.
The pain points conversation is the most important. Incumbent teams are often relieved to hand over and will tell you exactly what's broken. Listen.
Phase 2 — Asset inventory (weeks 2–4)
Goal: enumerate everything that could be in-scope. Source repositories (don't trust the README — grep the org for relevant strings). Cloud accounts and what runs in them. Databases and their backup configuration. Integrations — outbound and inbound, with credentials and contract owners. Monitoring dashboards and alert routing. Runbooks (collect every doc, even if outdated).
The asset inventory is a spreadsheet with one row per asset, owner column, criticality column, and a "questions outstanding" column. The outstanding-questions list drives phase 3.
Phase 3 — Knowledge capture (weeks 3–6)
This is where most transitions fail — not because knowledge isn't shared but because it isn't *captured* in a form the new team can use after the incumbent is gone.
What works:
- Recorded screen-share walkthroughs of every critical workflow, indexed with timestamps. ("How a hotfix gets to prod", "What the nightly batch does", "How we onboard a new tenant".)
- Runbooks rewritten by the incoming team based on the walkthrough, then validated by the incumbent. The act of rewriting forces understanding.
- A decision log of every "why is it like this" question with the answer. Future engineers will ask the same questions — give them somewhere to find the answers.
What doesn't work: handing over the existing Confluence space and assuming people will read it. They won't, and most of it is wrong.
Phase 4 — Shadow operations (weeks 6–10)
Incoming team operates with incumbent shadowing. Every incident is co-handled. Every release is co-deployed. We aim for at least 3 production releases and 2 real incidents in shadow mode before considering cutover — simulated incidents don't count, real pressure surfaces real gaps.
Daily 15-minute sync to log surprises, missing knowledge, and follow-ups.
Phase 5 — Cutover (week 10–11)
Cutover is a date with a checklist, not a milestone. Checklist includes: all credentials rotated to new team's ownership; monitoring alert routing updated; on-call rotation switched; incumbent on standby for 2 weeks with a clear, paid SLA for questions.
Don't cut commercial ties on the cutover date — always have a 30-day support contract with the incumbent at a meaningful retainer.
Phase 6 — Stabilization (weeks 11–16)
First 6 weeks post-cutover are higher-incident by definition. Plan extra capacity. Run a weekly retrospective on "what did we discover this week that wasn't in the handover?" and add it to the runbooks. After 6 weeks, the system is yours.
What we'd do differently
On one transition we let the incumbent lead the knowledge capture documents. They produced beautiful, accurate docs that nobody on our team had internalized. We now insist the incoming team writes every runbook, with the incumbent reviewing — the cost is the same but retention is dramatically higher.
Closing
Vendor transitions are 80% knowledge transfer and 20% logistics. Get the knowledge capture phase right and the rest follows. Skimp on it and you'll be paying for it in incidents for 6 months.
