How we hand over knowledge so you are never locked in
The practices that keep a client independent of us from week one: documentation updated with every change, decisions recorded with reasons, an internal owner.
The short answer
Knowledge is not handed over at exit; it is handed over continuously, or it is not handed over at all. From the first week we keep the setup document current with every change that affects it, record every significant decision with its reasons, keep the runbook honest, and make sure the client’s internal owner understands the estate well enough to brief a new partner from the document and memory. The test that proves it is the takeover rehearsal: someone who did not build the system tries to set it up, change it and deploy it from the documents alone, and every question they have to ask is a gap to close. A partner who transfers knowledge as they go is easy to leave, and that is precisely why clients stay: they are kept by the work, not by the keys.
What is transferred and how
| Knowledge | Where it lives | When it is updated | Who holds it on the client side |
|---|---|---|---|
| What runs where | The setup document | With every change to the setup | The internal owner |
| Why decisions were made | Short entries in the repository, dated, with the reason | When a significant decision is made | The internal owner, in outline |
| How to operate it | The runbook: monitoring, alerts, backups, restore, incidents | With every operational change | The internal owner, and IT where relevant |
| How a change ships | The pipeline description and the preview process | When the process changes | Anyone who requests changes |
| What was done and why | The monthly report and the repository history | Monthly and continuously | The internal owner |
| Where the accounts are and who has access | The access list in the setup document | Quarterly review and on every change | The internal owner and the business’s administrators |
| What the numbers mean | The monthly report’s plain-language section | Monthly | The internal owner |
The practices
- Documentation as part of done: a change that affects setup, decisions, operations or process updates the relevant document in the same change, reviewed with the code.
- Decisions recorded with reasons at the time, in short entries.
- An internal owner briefed at onboarding and kept current through the quarterly review.
- Previews that explain: each change’s preview comes with a plain-language note of what and why, so the history is readable.
- The monthly report in the client’s language, tying activity to the estate.
- A takeover rehearsal when the documentation changes materially, with the gaps it finds fixed.
- Everything in the client’s storage and accounts, so none of it depends on us.
What the client can do to help
Appoint the internal owner and protect their time for the quarterly review. Store the documents in the business’s own storage, not only ours. Ask questions when something in the report is unclear; the answers become documentation. Run the stranger test yourself once, or have someone technical do it, and tell us what they could not answer. Knowledge transfer is a habit on both sides.
What this means for you
Expect knowledge to be transferred continuously: documents updated with every change, decisions recorded with reasons, an internal owner who understands the estate, a readable history, and a rehearsal that puts the documentation to the test with someone who did not build the system. It makes the partner easy to leave, and a partner who works to be easy to leave is one worth keeping.
Frequently asked questions
Why would a partner make themselves easy to replace?
Because being kept for the work is better than being kept for the keys, and because a client who could leave is a client who chooses to stay. Knowledge handed over as we go also makes our own work better: documented decisions are better decisions, and a runbook we wrote is one we follow. The convenience of being indispensable is not worth the relationship it produces.
What does the internal owner need to know?
Not the code. What runs where, why the main decisions were made, how a change gets from request to live, what is monitored and who is alerted, where the accounts are and who has access, what the monthly report means, and who to call. The setup document holds it; the quarterly review keeps it current; the owner should be able to brief a new partner from memory and the document.
How do we know the documentation is good enough to take over from?
By having someone who did not build it try. A colleague or an external reviewer takes the documentation alone and attempts to set the project up, make a change and deploy it, and every question they have to ask is a gap to close. It is the only honest test of documentation, and it is worth asking any partner when they last ran it and what it produced. Ours is a practice we are putting in place rather than a yearly cycle we can point back at to ask. The questions are gaps; we fix them. It is the same stranger test a client should run on any supplier, applied to ourselves.