The first handover walkthrough failed. Here is the format we use now

The first version was thorough. Two hours, screen shared, the architecture explained from the data layer up, every service named, every deployment step demonstrated live. The client’s operations lead took notes throughout and said it was clear.

Three weeks later a small change was needed and nobody moved. Not because they had forgotten — because we had explained the system rather than handed over the ability to act on it. Those are different deliverables, and we had confidently shipped the wrong one.

Reading back our own notes, three mistakes, all of them ours:

• We taught the architecture, not the tasks. An owner does not need to know how the queue works. They need to know what to do when an order does not appear, who to call, and what they can safely change themselves.
• We demonstrated instead of watching. Every step went right because we were the ones doing it. Nothing was proven about whether anyone else could.
• We treated documentation as an artifact rather than a test. We wrote a good runbook. Nobody had ever followed it cold.

The second version is longer in calendar time and shorter in each sitting. It is organised around jobs rather than systems, and everything is verified by someone on their side doing it while we stay quiet.

• Day one — the ten questions. We write the ten things most likely to be asked in the first six months, in the owner’s words, and answer each in a page or less. "An order is missing." "We need to add a user." "The site is slow." These become the top of the runbook, ahead of any architecture.
• Day two — they drive. Their person deploys a real change while we watch and say nothing unless asked. Every place they hesitate is a defect in the documentation, not in them, and gets fixed that afternoon.
• Day three — the failure drill. We restore a backup into a test environment together, and we deliberately break something so the recovery path is walked rather than described.
• Day four — the ledger. Accounts, access, costs, renewal dates, who holds what. Signed off line by line by an owner or director, not by an engineer.
• Week four — the silent week. We answer nothing that is not an emergency. Anything they cannot resolve from the runbook is a gap we close before the engagement is called done.

The measurable difference is in the month after. On the old format we averaged eleven support requests in the first month; on the new one it is closer to two, and both are usually questions rather than incidents.

The more useful difference is harder to count. When their person deploys the first change themselves, in front of us, the relationship stops being dependency and becomes choice. They call us afterwards because they want to, not because they must.

A handover you have not watched someone else complete is a hope, not a handover.

There is nothing proprietary here and you do not need us to run it. If you are inheriting a system from an agency, a contractor or a departing employee, ask for exactly this: the ten questions answered, a change deployed by your own person while they watch, a restore performed rather than described, and the account ledger signed off by an owner.

If they cannot do those four things, you are not receiving a handover. You are receiving a login.