Kesey · When one person holds it all
The only person who understands your CRM is leaving.
They built it, they have run it for years, and everything anyone knows about how it works is a question you ask them. You have two weeks. Here is what actually leaves with them, and the order to do things in.
Code can be read. What a record means cannot. Somebody new can open the repository and work out what the scripts do. Nobody can open the database and work out that status 4 has meant renewal at risk since 2019 because one person decided it did. That meaning has no file. It is leaving with them, and a wiki page written in a notice period does not hold it.
So do not spend the notice period on documentation. Spend it getting the record out, verified, into something that maintains its own meaning. You have roughly 20 usable hours against a system that takes about 256 hours a year to keep trustworthy. Those two numbers are the whole situation, and the arithmetic behind both is printed below.
The advice you are about to get
Knowledge transfer is right for a tool and wrong for a record
Search this and you get the same five steps everywhere: run knowledge transfer sessions, have them write a runbook, shadow them for a fortnight, record the walkthroughs, build a succession plan. That advice is not wrong. It is advice about tools, and it works on tools, because a tool has an input, an output and a job you can describe in a paragraph.
A record is different in one specific way. What it is worth is not what it does, it is whether people believe it, and that belief sits in somebody's head rather than in a document. A runbook can tell the next engineer how to restart the nightly sync. It cannot tell them that three fields in the deals table stopped being kept up in 2022, that the amount column excludes tax except on the accounts brought over from the old system, or which of two disagreeing numbers to believe on a Tuesday. The person leaving does not know that they know those things, so they do not write them down, and you do not know to ask.
Code can be read. What a record means cannot. Nothing about that is a failure on their part. It is just how records work, and it is why the handover you are planning will not do what you are hoping it will.
The wider argument, which this page assumes rather than repeats: build the tools, never the record. Tools are cheap to build, safe to throw away and genuinely worth building yourself. The record has to hold up for people who did not build it, and a homemade one rarely does.
Should you build your own CRM makes that case in full, with the annual cost model this page borrows its 256 hour figure from. This page is about the week you find out.
What actually leaves
Four things that are not in the repository
-
What the fields mean
Every homegrown record collects fields whose meaning is a decision somebody made once and everybody else absorbed. A status code that means one thing for new business and another for renewals. A column that is only right for half the accounts. A flag that was a workaround for a bug that got fixed years ago. The database tells you what type a field is. What it MEANS is in somebody's head.
"Oh, ignore stage 6. We stopped using it when we split the pipeline."
-
Which system to believe when two disagree
Your CRM says one number and your billing system says another. Somebody knows which one is right, in which situation, and why. It is almost never written down, because the person who knows it has never once had to say it out loud. They just settle it, correctly, every time it comes up. This is the most expensive thing you are about to lose and the least likely to come up in a handover.
"If the invoice and the deal disagree, the invoice is right, unless it is one of the annual accounts."
-
The jobs nobody wrote down
The script that runs on their laptop. The Monday morning fix that has become a habit rather than a ticket. The thing they check before the board pack goes out. Automated work leaves a trace you can find; habitual work leaves none at all, and you discover it by the third week of it not happening.
"I usually just re-run the import if the totals look off."
-
Everything the record never had to hold
They never wrote up the history of the difficult account, because they sat in every meeting about it. A bought record picks that up on its own, out of the work happening. A homemade one holds whatever its author thought to build a field for, which is always less, because the author was in the room and did not need a field for it.
"That account is fine, it always renews late."
Nobody has to resign for this to matter. The same gap opens the moment an outsider asks where a number came from.
The window
What a two week notice actually buys you
Every plan made in the first day of a notice period assumes the notice period is available. It is not. Here is the same fortnight with the assumption printed under each line, so you can overrule any of them and see what is left.
- A two week notice, in working hours 80 hours Ten working days at eight hours. A longer notice scales this line and every line under it.
- What they still owe on the job they were already doing less 50 The work in flight does not stop because somebody resigned, and a leaver who drops it burns the reference they are leaving for.
- Exit admin, the goodbye lunch, and the last afternoon less 10 Handover is not the only thing on a calendar in a notice period, and the final day is not a working day in any company.
- What is genuinely left for handover 20 hours The remainder, and it is the optimistic reading. It assumes they are willing, available and not already checked out.
That is the gap. Twenty hours of somebody's attention to transfer a system that takes about 256 hours a year to keep trustworthy, on the model set out in the build versus buy argument. You are not short of time to document it. You are short by an order of magnitude.
Which settles what the twenty hours are for. They are not for explaining the system. They are for getting the data out and proving it came out whole. Explanation is the thing you cannot finish. Extraction is the thing you can.
The order
Five moves, and the order is the point
-
Stop changing the fields today
No new fields, no renames, no helpful tidying, from this afternoon. Everything below assumes the thing you are documenting is holding still, and a system that changes shape during a handover turns every note written about it into a note about something else. Costs nothing, and it is the only move here with a deadline of today.
Day one -
Get the rules out of their head, in writing
Not how it is built. The rules. Which system to believe when two disagree, which fields are dead, which accounts are exceptions and why. Sit with them and ask about specific disagreements you have actually had, rather than asking them to write up the system. Nobody can list everything they know, and anybody can answer a question about a real case.
First week, two or three sessions -
Export everything, including history, and open the file
Every table, every relationship, and whatever change history exists. Then have somebody who is not them open it, load it somewhere, and count the rows against the live system. An export nobody has opened is not a backup, it is a file. This is the move that most often fails while they are still here, which is exactly why it goes before they leave rather than after.
First week, in parallel -
Spend their last sessions verifying, never explaining
Put the export in front of them and ask what is wrong with it. They will spot in ten minutes what a new engineer would not find in a month: the table that exported empty, the column that lost its encoding, the join that silently dropped the accounts from the old system. Their value in the last week is as a reviewer of your extract, not as a narrator of their design.
Second week -
Move the record. Keep the tools.
The scripts, the dashboards, the enrichment, the integrations they wrote: keep all of it, it is genuinely yours and genuinely good. The record goes onto something that holds its own meaning, so the next person to ask what a field means gets an answer from the system rather than from whoever has been here longest. That migration does not have to finish inside the notice period, and it usually does not. It has to start while the answers are still in the building.
Starts now, finishes later
Fit
When this is you, and when to do nothing
- One person built it and one person runs it. Every question about it has the same answer, and that answer is a name.
- The notice is already in. The cheapest version of this conversation was a year ago. The second cheapest is this week.
- Nobody else has ever opened the backup. If one person has ever restored it and that person is leaving, you do not have a backup, you have a hope.
- The business runs on it. Invoicing, renewals or the board pack read from it. If it stopped today, you would know by Thursday.
- A second person has run it for a full quarter. Without asking them anything. That is a maintainer, not a dependency, and you have no key person risk to solve.
- Somebody else has opened the export. Loaded it, counted it, and used it. The thing this page worries about has already been done.
- It is small, boring and stable. A record that has not needed a schema change in two years and fits in one head can survive the change of head.
- They are staying on properly. Not "available for questions". Contracted, with hours, for long enough to matter. Then you have bought time and should use it on the migration rather than on documentation.
Where Kesey comes in
We do the extraction while you keep the business running
We are a revenue operations practice and a Day.ai Solutions Partner. In a notice period the useful thing an outsider does is take the data and the questioning off your team, who are already absorbing the leaver's actual job. We sit in the sessions, ask the questions in the form people can answer, take the export and prove nothing is missing from it, and move the record onto something that holds its own meaning. The tools they built stay yours and stay running.
What this page does not claim. There is no case study here and no percentage. The numbers above are a model with its inputs printed, not a survey: substitute your own notice period and your own split, and if the arithmetic comes out differently for you then it comes out differently.
And if the answer is that your build is fine and two people can genuinely run it, we will say so on the call. Cheaper for both of us than a migration nobody needed.
Questions
Frequently asked
The person who built our CRM is leaving. What do we do first?
Freeze the fields today, before anything else. No new ones, no renames, no tidying. Then spend the notice period getting the data out and checked rather than getting the system explained, because explaining it is the job you cannot finish in the time you have and getting the data out is the job you can.
Can we just document the system before they go?
Not usefully, and not because they are unwilling. Code can be read. What a record means cannot. Somebody new can open the repository and work out what the scripts do. Nobody can open the database and work out that one status code has meant renewal at risk for six years because one person decided it did. People also cannot list everything they know, so asking somebody to write up their system gets you a document about how it is built, which was never the part at risk.
How long does a CRM handover actually take?
A two week notice is 80 working hours. Roughly 50 go on the work they were already doing and 10 on exit admin and the last afternoon, which leaves about 20 hours, and that is the optimistic reading. The job you are handing over takes about 256 hours a year to do. You are not short by a few days, you are short by an order of magnitude, so plan against 20 hours and pick carefully what to spend them on.
Should we migrate during the notice period or after?
Start during, finish after. The move itself rarely fits in a notice period and does not need to. What has to happen while they are still there is getting the data out and checking nothing is missing, because those are the only two things that get harder the day they leave. A migration run three months later against an export you checked in week one is an ordinary project. The same migration against an export nobody opened is a dig.
What if they will stay on as a contractor?
Good, if it is real. Contracted hours for a set period is time you have genuinely bought, and the right thing to spend it on is the move rather than more documentation. Available for questions is not that. It fades within weeks, nothing forces it to happen, and it lets everybody put the decision off until the person has a new job and stops replying.
Is somebody leaving a reason to move off a homegrown CRM?
It is the moment the cost becomes visible rather than a new cost. The record was always going to have to be trusted by people who did not build it. A resignation is just the first time that happens with a date on it. Should you build your own CRM sets out the underlying argument: build the tools, never the record.
What if there is no export and no documentation at all?
Then the first twenty hours go entirely on getting a complete copy of every table with its relationships intact, and somebody other than the author opening it and counting the rows. Nothing else matters until that exists. It is also the only task here that is genuinely bounded: you know when it is finished, which is not true of anything else you could spend the fortnight on.
Code can be read. What a record means cannot.
Twenty usable hours is not enough to explain a system and is plenty to get the record out whole. If somebody has just resigned, the useful call is this week rather than after their last day.
Book a callThe hour figures on this page are a model with its inputs printed rather than a survey of any particular company, and the 256 hour annual figure is carried from the cost model on Should you build your own CRM. Substitute your own numbers; if yours come out differently, the conclusion may too.
Kesey is an independent revenue operations practice and a Day.ai Solutions Partner. It is not Day AI, Inc., and it is not affiliated with Clarify, Attio or HubSpot.