What an exit-ready handover actually contains

“You’ll get full documentation at handover” is a promise every vendor makes and almost none can demonstrate. So here is the concrete version: what an exit-ready handover package actually contains, and the question we use to test it — could your team run this system without us, starting Monday? Not answered with a nod in a steering meeting. Rehearsed, like a fire drill.

The contents, concretely

An exit-ready package is not a wiki dump. It is a specific set of artefacts, each answering a question your team will ask in our absence:

  • Architecture decision records — not just what the system is, but why. Each ADR captures the decision, the alternatives that were rejected, and the constraints that drove the choice. The “why” is what evaporates when a vendor leaves; ADRs are how it stays.
  • Runbooks — deploy, roll back, restore from backup, rotate credentials, scale under load. Written as commands a competent engineer can follow at 2am, not as prose about the general approach.
  • On-call notes — what actually pages, which alerts are noise and why they have not been fixed yet, the known sharp edges, the folklore that normally lives in one engineer’s head. This is the document teams most often discover they needed after it is too late to write.
  • Environments and infrastructure as code, in your accounts — your repos, your cloud, from day one. Every environment reproducible from code you own, no snowflake servers, no credential that only we hold. If the infrastructure lives in the vendor’s account, you do not have a handover problem, you have a hostage problem.
  • An access and dependency inventory — every third-party service, every key, every scheduled job, and who owns each one after we step back.

The drill: a practiced exercise, not a promise

Documentation is a hypothesis until someone else follows it. So the package includes rehearsals: your engineers deploy a change to production using only the runbook, respond to a staged incident, restore a backup — while our team watches, forbidden from helping, taking notes on every point where someone got stuck. Each stuck point becomes a ticket against the documentation, and the drill repeats until it passes clean. “Could your team run this without us?” stops being a comfort phrase and becomes a test with a result.

Why it’s in the definition of done, not a paid extra

Most vendors price handover as an exit service, which quietly inverts the incentive: the harder you are to leave, the better their retention. We put documentation, ADRs and handover drills inside the definition of done instead, because the incentive should run the other way. If leaving is expensive, every future conversation between us is a negotiation under duress — you are not choosing to stay, you are failing to escape. A partner whose retention depends on lock-in has a bad product. Ours has to depend on the work being good, which is only true if leaving is always cheap. That is the standing rule across our dedicated teams, and it is written into how we describe ourselves because clients should be able to hold us to it.

How it changes month one

The unexpected effect is not at the exit — it is at the start. Exit-readiness is not a document sprint in the final month; it is a constraint that shapes every early decision, mostly for the better:

  • ADRs from the first week mean decisions get made explicitly. A choice you have to write down and defend is a choice someone actually thought about.
  • IaC in your accounts from day one forbids the quick manual fix that becomes a permanent mystery. Environments stay reproducible because they were never anything else.
  • Boring infrastructure wins by default — a clever bespoke setup that only its author can operate fails the Monday question automatically, so it does not get built.

Teams that must always be replaceable end up building systems that are simply easier to run — for us, and eventually for you. The handover package is not paperwork about the system. It is pressure that makes the system better.

If you want to see what an exit-ready engagement looks like from the first month, talk to us — an hour with a tech lead, a technical call, not a sales call.