A handover has worked when the receiving team can break the system and fix it without calling anyone. That's the bar, and almost every handover that gets called complete falls short of it — which is why companies end up rebuilding a working system rather than inheriting it.
We've written about the pattern this creates in Vendor Roulette: each engagement ends leaving nothing behind, so each new team starts from a blank page. That piece names what should survive. This one is how to actually collect it.
The inventory
Everything below should be in *your* accounts and *your* repository before the outgoing team's last day — not shared from theirs, not promised at handover.
| Asset | Why it's the one that matters |
|---|---|
| Application code | Table stakes. Rarely the thing that's missing |
| Prompts, versioned | The accumulated tuning. Often lives outside the repo |
| Eval suite + test data | Without it the new team can't tell if they've made things worse |
| Data pipelines | The unglamorous majority of the real work |
| Infrastructure config | As code, not as someone's console clicks |
| Credentials and accounts | In your name, with your billing, before the last day |
| Decision log | Why this approach, what was tried and abandoned |
| Runbook | So somebody can be on call from day one |
The two that go missing most often are the eval suite and the decision log, and they're the two that cost the most. Without evals, the incoming team has no way to know whether their first change improved or degraded the system — so they either freeze it or break it. Without a decision log, they re-derive the same choices, frequently re-making an option the last team tried and abandoned for a reason nobody wrote down.
The acceptance test
Don't accept a handover on a walkthrough. Accept it on a demonstration, with the outgoing team present but silent:
- Reproduce the baseline. The new team runs the eval suite from a clean checkout and gets the documented score. If they can't, the environment isn't actually transferred.
- Ship a trivial change. A prompt tweak, through the full pipeline to production, and roll it back. This proves the deploy path, the versioning, and the rollback are real rather than described.
- Diagnose a seeded failure. The outgoing team breaks something deliberately; the new team finds it from traces alone. This is the one that exposes missing observability.
- Answer three "why" questions. Why this model, why that human checkpoint, why this workflow was scoped the way it was — from the decision log, not from memory in the room.
Pass all four and the handover is real. Anything less and you have a document transfer.
Build in an overlap, and make it work
Two weeks of paid overlap where the new team operates and the old team advises — not the reverse. If the outgoing team is still driving, nothing has transferred; you've just extended the engagement.
The most valuable thing to spend that overlap on is a real incident. If one doesn't occur naturally, seed one. Nothing surfaces an incomplete handover faster than something genuinely being wrong while the people who built it are still reachable.
Taking it in-house instead
Same inventory, one extra question: who is on call? Teams routinely underestimate this because the build looks like the hard part. It isn't — the build ends, and operations don't. Before committing, confirm someone owns the eval baseline, someone watches model deprecations, and someone is genuinely reachable when quality drops, because it will.
In-house makes clear sense when AI is core to your product and you can hire senior AI engineers — we lay out the tradeoff in build vs. buy. It makes less sense when you're absorbing one production system into a team with no capacity to operate it, which is how systems quietly stop being maintained without anyone deciding to stop maintaining them.
Ask for this before you sign, not at the end
Every item above is dramatically cheaper to obtain as a contractual condition at kickoff than as a request during offboarding, when goodwill is lowest and the team is already reassigned. Put the inventory and the four-part acceptance test in the agreement — it's one of the nine questions worth asking any vendor, and the answer tells you a lot about the engagement you're about to enter.
If the answer is that you'd rather not hold the pager at all, Managed AI Operations is the alternative — but even then, insist the inventory lands in your accounts. Being able to leave is what makes staying a decision rather than a condition.
