Issue 13PlaybookNo. 006
Off the spreadsheet: a 30-day CRM migration plan.
Your pipeline outgrew the spreadsheet a year ago. A week-by-week plan to move into a real CRM without losing data, deals or the team's goodwill.
Arjun Kapoor
Founder · Strategy
- Published
- Updated
- Read time
- 7 minutes

In this article
Every growing sales team has the same spreadsheet: one tab per year, colour-coded rows only one person understands, and a notes column that holds the real history of every deal. It works until it doesn't — usually when the person who maintains it goes on holiday.
Moving into a CRM sounds like a big project. It doesn't need to be. We run most spreadsheet-to-CRM migrations in 30 days, whether the destination is HubSpot, Pipedrive or a custom CRM we've built. The platform matters less than the order you do things in.
Before day one: decide what “done” means
Agree three things with whoever signs off the project: which team moves first (usually sales, not everyone at once), which spreadsheets and inboxes will be retired, and the date the old sheet becomes read-only. That last date is the most important line in the plan. Without it, teams keep both systems running and trust neither.
| Week | Focus | Done when |
|---|---|---|
| 1 | Process and pipeline design | Stages, fields, owners and reports are agreed |
| 2 | Data clean-up and mapping | Data is deduplicated and the field map is signed off |
| 3 | Import, integrations, automations | The test import is approved and tools are connected |
| 4 | Training and cut-over | The spreadsheet is read-only and the pipeline meeting runs from the CRM |
Week 1: map the process, not the spreadsheet
Resist the urge to recreate the spreadsheet's columns as CRM fields. Instead, sit with two or three people who sell every day and map how a deal really moves.
- Define pipeline stages by what the buyer has done, not what the rep hopes. “Proposal sent” is a stage; “Hot” is not.
- List the fields each stage genuinely needs. Most teams need far fewer than their spreadsheet has.
- Agree ownership rules: who owns a lead, when it's reassigned and what happens to deals that go quiet.
- Write down the five reports leadership actually reads. They define which data you must capture.
Week 2: clean and map the data
This is where migrations go wrong, so give it the whole week.
Export everything.
Spreadsheets, email contacts, the old tool nobody uses and the business cards someone typed up. Keep untouched copies of the originals.
Deduplicate.
Merge duplicate contacts and companies, using email address and website domain as the keys. Decide which record wins when two disagree.
Standardise.
One format for phone numbers, countries, dates and deal values. Use pick-lists instead of free text wherever the CRM will filter or report on a field.
Map columns to fields.
A simple two-column sheet: old column, new field. Anything without a home is either kept as a note or dropped on purpose.
Decide what not to migrate.
Contacts with no activity in years and long-dead deals can stay in the archive. A smaller, cleaner CRM beats a complete, cluttered one.
Field note · The notes column
Free-text notes are where the real deal history lives. Import them as dated notes on each record's timeline, rather than squeezing them into a custom field nobody will ever open.
Bring consent with you, too. If you email your contacts, migrate each person's marketing consent status and where it came from, not just their address. A CRM full of contacts with unknown consent is a compliance problem waiting to happen, particularly in the UK and EU.
Week 3: import, connect and automate
Run a test import of a few hundred records first, check them with the sales team, fix the mapping, then import the rest. Import companies before contacts and contacts before deals, so the associations land in the right place.
Then connect the tools the team already lives in: email and calendar sync, website forms, the booking link and any quoting or invoicing system. Add only the automations that remove obvious manual work — a task when a deal stalls, an alert when a hot lead fills in a form, a welcome sequence for new customers. Everything else can wait until the team has used the CRM for a month.
Week 4: train, run in parallel, cut over
Training works best in short, role-based sessions using the team's own deals, not demo data. We record each session and write a one-page “how we use the CRM” guide covering stages, required fields and the daily routine.
Name a CRM owner at the same time: one person who approves new fields, stages and automations. Without one, every team adds its own fields and the CRM turns back into the spreadsheet within a year.
For the final few days, reps work in the CRM while the spreadsheet stays available as a reference. On the agreed date, the spreadsheet becomes read-only. From then on, if it isn't in the CRM, it didn't happen. Pipeline reviews run from CRM reports from that first week — that's what makes the habit stick.
“The migration isn't finished when the data is imported. It's finished when the Monday pipeline meeting runs from the CRM.”
After day 30
Book a review for day 60. Look at which fields are actually filled in, which stages deals get stuck in and which reports people open. Remove what isn't used and add the automations people have asked for. A CRM that keeps changing with the team stays useful; one frozen at launch drifts back towards the spreadsheet.
If you're still deciding between an off-the-shelf platform and something built around your process, read when a custom CRM makes sense, or talk to our CRM development team about running the migration with you.
Key takeaways
If you only remember three things
Map how deals really move before you design a single field.
Spend a full week cleaning data. Migrate less, but migrate it well.
Set a read-only date for the spreadsheet and run pipeline meetings from the CRM.

Written by
Arjun Kapoor
Founder · Strategy · Founded Performative Web in 2016
Arjun founded Performative Web in London in 2016 and still leads strategy on our largest engagements. He writes here about the commercial side of technology decisions — what things really cost, and when they pay back.


