Most advice about moving off a spreadsheet stops at the decision. Say you have made it. What nobody mentions is that the import itself is the easy part - and that almost everything which goes wrong in a migration went wrong in the sheet, months before anyone opened a CRM.
This is the mechanical version: what to do to your file, in what order, and what the switch actually looks like on the day. If you are still deciding whether to move at all, that is a different question and we wrote about it separately.
Clean the sheet first - the CRM will not do it for you
An import is a copy, not a filter. Duplicate rows arrive as duplicate records. Dead leads arrive as dead records. Empty rows arrive as contacts with a name and nothing else, and you will be scrolling past them for the next two years.
Three passes, in this order, before you export anything:
- Duplicates. Usually the same company spelled three ways - with and without LLC, with and without the branch name. Sort by company, read down the column, merge by hand. This is slower than it sounds and there is no shortcut worth trusting.
- Dead rows. Anyone you would not call again. Do not import them "just in case" - keep the old file, that is what the old file is for.
- Blanks. A row with a name and no way to reach the person is not a contact. It is a reminder to find a phone number, and it belongs in a task, not in a database.
On a two-thousand-row sheet, budget an afternoon. It will take longer than the import by a wide margin, and it is the only part of this that genuinely determines whether the new system feels better than the old one.
Decide what one row actually is
Almost every sales spreadsheet quietly holds three different things in one row: a person, a company, and a deal. A CRM keeps those separate, on purpose, because a person can change company and a company can have five deals running.
There is a quick test. If the same customer appears in three rows because they bought three times, your rows are deals. If a company appears once even though four people there talk to you, your rows are companies. If both are true in different parts of the sheet - and they usually are - the sheet has been holding two structures at once and nobody noticed, because a human was reading it.
Decide this on paper before you export. In practice it means splitting one file into two or three: contacts, companies, and open deals. Getting it wrong is the single most common reason a freshly migrated CRM feels worse than the spreadsheet it replaced.
What maps across, and what has nowhere to land
Names, companies, phone numbers, emails and free-text notes move without drama. ONE CRM's own answer on this is that contacts import from Excel or CSV in minutes, and for data in that shape it is accurate.
The columns that need thought are the ones carrying meaning rather than facts:
- Status or stage. Write the mapping out explicitly, one line per old value: what does "waiting" become? What about the four rows that say "waiting - see Ahmed"? Decide before the import, not during it.
- Owner. Owner names have to match real user accounts, so create the team first. Most systems let you set permissions per person, and it is much easier to do that on an empty system than on a full one.
- Dates. Export in one unambiguous format. A cell reading 03/04/2026 is two different days depending on who typed it, and an import will not ask.
- Amounts. Numbers, not text. Strip the currency symbols and the thousands separators in the sheet, where you can see what you are changing.
The columns that will not migrate
Some of what your sheet knows is not in any column. Colour fills, cell comments, the bold rows, the tab everyone understands to mean urgent, formulas pulling from three other tabs. None of it survives an export, and pretending otherwise is how teams end up feeling that the CRM "lost" things.
Handle it deliberately. Write down what each colour means, then turn each meaning into a real field, a stage, or a tag - something the system can filter on. If nobody in the room can say what yellow means, it was never information and you have just saved yourself a field. Export formulas as values, not formulas. Documents and proposals living in folders and chat threads migrate by hand or not at all, so decide which ones actually need to be attached to a record and accept that the rest stay where they are.
One case is worth naming honestly: if a column encodes a process that no product has a field for, and you cannot map it to anything, that is not a migration problem. It is the signal that your process may genuinely be yours, which is a different conversation and a more expensive one. It is also rare. Most columns that look unique are a stage with an unusual name.
Import in the right order
Each layer references the one before it, so the order is not arbitrary: users first, then your pipeline stages, then companies, then contacts, then open deals. Import deals before contacts and you get orphaned records you have to link by hand.
Run a sample first - twenty rows, not the whole file. Open them in the interface and look at them as a user would: is the phone number in the phone field, did the stage land where you expected, is the owner right? Fix the mapping, delete the twenty, then run the full file. A free trial period is the sensible place to do this, because a failed sample import costs nothing but the afternoon.
Then reconcile the counts. Rows exported against records created. If 2,140 rows became 2,096 records, find the 44 before you go any further - it is almost always a formatting problem in one column, and it is far cheaper to find on day one than in month three.
The cutover is one day, not a phase
The most reliable way to fail is to run both systems "for a while." Half the team updates the sheet, half updates the CRM, neither is complete, and within three weeks everyone has quietly gone back to the sheet because at least the sheet is not missing anything.
Pick a date instead. Freeze the sheet at the end of that day and make it read-only. Take the final export that evening and import it. Everyone starts in the new system the next morning, including the person who does not want to.
Expect the first week to be slower. That is adoption cost, not evidence that the migration failed, and it is worth saying out loud to the team beforehand so nobody reads normal friction as a broken system. Ruwad Al Khdmat made this move on the financing side - applications tracked by hand, going stale, with clients left wondering where they stood - and what changed afterwards was not the data. It was that a structured pipeline made status something the system reported rather than something someone had to ask about.
What to do with the old sheet
Keep it. Export a dated copy, put it somewhere safe, and leave it there. You will want it in month two, once, and then never again.
But make it useless for daily work. Rename it with ARCHIVE at the front and remove edit access for everyone. A live spreadsheet still open in one person's browser tab is the most common way a migration quietly reverses itself, and it takes about six weeks to notice.
Then check the exit while you are still paying attention: can you export everything back out of the new system, in a format you could read without it? If migration is the real test of a vendor, the export button is the second half of that test, and the moment you have just finished migrating is the cheapest possible moment to find out the answer.
A migration is not really a technical project. The import takes minutes. The work is the three days before it - deciding what a row is, agreeing on what the colours meant, and being willing to leave things behind. Do that part properly and the switch itself is uneventful, which is exactly what you want it to be.