Field notes
The CRM demo is simple because it’s empty.
Moving off spreadsheets is not a data problem. The spreadsheet worked because someone held the rules in their head, and a CRM makes you write them down.
A CRM demo is simple because it is empty. A spreadsheet that has been running for years is not simple, it is a pile of exceptions that make sense to whoever built it. The pain of switching is the cost of writing down rules nobody ever had to write down, and it lands hardest on the person you most need on side. Plan for that, not for the import.
On this page
The demo goes well. Someone clicks through a pipeline, drags a deal, shows a dashboard building itself. It looks like less work than the spreadsheet. Everyone agrees it looks simple.
Then the switch takes four months and half the team is still keeping a private copy of the sheet.
This is one of the most common questions I see asked in public, and the answers usually blame the software or the people. It is neither.
The demo is simple because it is empty
Simplicity is a property of an empty system. Every CRM is simple with four fake records in it. So is a spreadsheet.
Yours is not simple. It has been running for years. It has a tab nobody opens, a column that meant one thing in 2023 and another now, six rows that are really the same customer, and a colour code that two people understand.
You are not comparing a spreadsheet to a CRM. You are comparing your spreadsheet, with all of that in it, to an empty CRM. Of course the empty one looks easier.
The rules were never written down
Here is the part that does the damage. The spreadsheet worked, and it worked on rules that were never written anywhere.
Which rows count as real. When to stop chasing one. What the yellow means. Whether a name in the notes column is a contact or the person who made the introduction. Somebody knew. They did not need to say it, because they were the only one filling it in.
A CRM cannot run on that. It needs the rule stated, because it is going to apply the rule to everybody, every day, in public. So the switch drags every one of those quiet decisions out at once and asks you to settle it now, in a meeting, with people who turn out to disagree.
That is the pain. It is decision work wearing the costume of a data project. And it feels disproportionate to the software because it has almost nothing to do with the software.
| In the spreadsheet | What the CRM makes you decide | |
|---|---|---|
| A blank cell | Meant whatever you remembered it meant | Unknown, not applicable, or nobody has asked yet |
| A column | Held anything you typed into it | A type, and the list of allowed values |
| One row | Company, person and deal, together | Which one the record is, and how the three link |
| Ownership | Whoever had the file open | One named owner, and what happens when they leave |
| A deal that feels alive | Stayed open | A stage, and the evidence that moves it |
| A correction | Overwrote the old value | Nothing. It keeps both, and who changed it |
The middle column is not a list of bad habits. It is what a spreadsheet is for. The pain of the switch is that every line on the right used to be a judgement call somebody made silently, and now it has to be a decision the whole team can read.
One row is not one thing
This is the single hardest part, and it is where most spreadsheet moves come apart.
A spreadsheet row is happy to be several things at once. Company name, the person you talk to, the thing you are trying to sell them, the last time you spoke, the amount. One row, five different kinds of information, and it never caused a problem because a human read it.
A CRM splits those apart on purpose. The company is one record, the person is another, the deal is a third, and the conversation hangs off all of them. That split is the whole reason a CRM can answer questions a spreadsheet cannot, like how many times you have sold to this group of companies, or what happened the last three times this person changed jobs.
It also means one row does not become one record. It becomes three, and you have to decide how they join. Do that badly and you get the duplicate problem everyone blames on the import. Related: how a stage differs from a status, which is the same confusion one level down.
A column is not a field
The instinct is to recreate the sheet. Same columns, same order, so it feels familiar on day one.
It is the most expensive shortcut available. A column costs nothing to leave lying around. A field costs somebody something forever, because every field is a thing a person has to fill in, ignore, or explain to the next hire.
One audit I ran found 722 custom properties, 203 of them empty. Nobody set out to build that. It grows one reasonable request at a time, and recreating a spreadsheet column-for-column is the fastest way to start.
Half the columns in a working sheet are not fields at all. They are notes, or a workaround for something the sheet could not do, or a flag that should be a stage. Sort them before you map anything.
Nobody owned a row
Spreadsheets have no concept of an owner. Whoever has it open owns it, for as long as it is open.
A CRM insists. Every record gets a name against it, and that name decides who gets the reminder, who shows up in the report, and whose number it is at the end of the quarter. For a team that has been sharing one sheet, that is not a settings change. It is the first time the split of the work has been written down, and it can surface a disagreement that has been comfortably vague for years.
The related loss is history. A spreadsheet holds the current state of a row and nothing else - no record of who changed the number, when, or why. You are not moving your history across. You are starting to keep it. Say that out loud early, because the first few weeks will feel like the new system knows less than the old one, and it will be true.
The person doing the work is the one who loses
A spreadsheet is fast for the person who built it and slow for everyone else. A CRM is the other way round.
Which means the person you most need on side, the one who has been holding the whole thing together, is the one the change costs the most. They are giving up a tool they can fly, in exchange for one that is slower for them and better for the company. Everyone else gets a visible upgrade. They get homework.
Almost nobody plans for this, and then reads the result as resistance. It is not resistance. It is an accurate reading of who is paying. Name it, and give them something back - the reporting they were building by hand, an admin job they can stop doing, or simply the credit for having run the thing this long.
None of this is a failure of the sheet, either. It got the company here. It is being asked to do a job it was never built for, which is a sign the company grew, and reads as trouble only because nobody budgeted for the handover.
What actually helps
Decide what the system is for before you map a single column. Not what the sheet had - what decisions this thing has to support. Everything else follows from that answer, and skipping it is why so many builds get redone.
Clean it where it stands. Fixing a duplicate in the sheet costs minutes. Fixing it after it has become a record with an owner, a timeline and three automations pointing at it costs an afternoon and somebody’s goodwill.
Move in slices rather than all at once, and keep the sheet open alongside for two or three weeks with an agreed end date. An overlap with a date on it is a safety net. An open-ended one means the sheet becomes the real system again and the CRM turns into an expensive copy of it.
Write the rules down as you settle them, in plain words, somewhere people can find. That is the whole artifact. A short page of what counts as what beats a long field list, and it is the thing that stops the argument being reopened every quarter. Data governance for teams too small to have a data team is the version of this for a company that cannot staff it.
The full sequence, in order, with the parts that get skipped, is in CRM migration phases. And if the CRM you are moving into has been sitting there half-built for a while, start with cleaning that up instead, because importing into a mess makes two messes. If you would rather not run it alone, that is what our CRM migration work is for.
The software really is simple. It is the first time anyone has had to say out loud how the company actually works, and that was always going to take a while.
Common questions
Why is moving from spreadsheets to a CRM so hard?
Because the spreadsheet was never the whole system. The rules that made it work - what counts as a real deal, which rows are dead, what a half-filled cell means - lived in the head of whoever maintained it. A CRM cannot run on rules nobody wrote down, so the switch forces every one of those decisions into the open at once. That is the work, and it is decision work rather than data work.
Should I clean the spreadsheet before importing it?
Clean it where it stands, before it moves. It is far cheaper to fix a duplicate or an ambiguous status in the sheet than to fix it after it has become a record with an owner, a timeline, and three automations pointing at it. Decide what you are deliberately not bringing across, too - a column nobody has filled in since last year does not need to become a field somebody maintains forever.
How long should we keep the spreadsheet running alongside the CRM?
A short, dated overlap is sensible; an open-ended one is not. Give it two or three weeks with an agreed end date, so people can check the new system against something they trust while they learn it. Without an end date the sheet drifts back into being the real system and the CRM turns into an expensive copy of it.
Do we lose our history when we move off spreadsheets?
Mostly, yes, and it helps to say so out loud. A spreadsheet records the current state of a row, not what happened to it - no record of who changed a value, when, or why. You are not migrating history so much as starting to keep it. Expect the CRM to be less informative than the sheet for the first few weeks and more informative than it could ever be after a couple of quarters.