Migrating from Excel to a CRM: Step-by-Step Without Losing Contacts

The client spreadsheet started out tidy four years ago and today it has 22 columns, three tabs per salesperson, and color-coded cells only one person knows how to read. Migrating from Excel to a CRM takes 2 to 4 weeks for a typical SMB database (2,000-10,000 contacts) and happens in five steps: clean and normalize the spreadsheet, define how columns map to fields, deduplicate using a unique key, import in two passes (test and final), and run the cutover without stalling sales. This guide walks through each step with realistic timelines and ends with the complete checklist.

One clarification: this guide works the same whether you migrate to a SaaS tool or to a custom CRM. The difference is that with custom development the fields are designed around your spreadsheet — the mapping is almost natural — whereas with SaaS your spreadsheet has to bend to the fields that already exist.

Step 1: clean and normalize the spreadsheet (the week nobody wants to do)

70% of the migration effort lives here, and skipping it is the number one cause of CRMs that are born dirty. What that means concretely:

• One row = one contact or one company. If you have cells with "John and Mary (wife)" or three phone numbers split by slashes, separate them now.
• Normalize phone numbers to a single format with a country code (+54 9 11..., +598...). This is critical if you later plan to integrate WhatsApp into the CRM: a badly formatted number is a customer the system does not recognize when they message you.
• Unify the values in status columns. "client", "Client", "ACTIVE CLIENT", and "clt" must collapse into a single value. Same goes for industries, regions, and lead sources.
• Decide what to do with the color-coded cells. If yellow meant "in arrears" and green meant "VIP", turn that tacit knowledge into an explicit column before migrating, because colors do not travel.
• Fill in the owner column. Every contact needs an assigned salesperson; orphans cause territory fights in the first month.

Realistic time: 3 to 7 days of work by someone who knows the operation (it does not outsource well: a vendor can normalize formats, but cannot know whether "North Distributors" and "North Dist. LLC" are the same company).

Step 2: map columns to CRM fields

Build a three-column table: Excel field → CRM field → transformation rule. A real, simplified example from an accounting firm we migrated:

Excel column	CRM field	Transformation
"Client"	Company → Legal name	Direct
"Contact / email"	Person → Name + Email	Split into two fields
"Tel/cell"	Phone	Normalize to +54
"Status" (free text)	Pipeline stage	Equivalence table (9 values → 5 stages)
"Last invoice"	Does not migrate	Will come from the billing integration
"Notes"	Initial note with date	Copied as-is, tagged as "Excel history"

Two golden rules: every important CRM field must have a defined source, and every Excel column with no destination must have an explicit decision (migrates as a note, gets archived, or is dropped). If you are not sure what stages your pipeline should have, first read what a sales pipeline is.

Step 3: deduplicate before importing, never after

Duplicates are the cancer of commercial databases: two records for the same customer mean a split history, two salespeople calling the same person, and reports that lie.

1. Choose the unique key: tax ID / company registration number for businesses; normalized email or phone for people.
2. Deduplicate in the spreadsheet using that key. For databases under 10,000 rows, "remove duplicates" plus a manual review of the borderline cases is enough; for large or very messy databases, fuzzy-matching scripts are used (accents, abbreviations, typos).
3. When merging, keep the most complete record and copy over the notes from the other.
4. Configure the CRM to reject future duplicates using that same key: deduplicating once is pointless if the door stays open.

In real databases we find between 8% and 20% duplicates. If your spreadsheet has 5,000 contacts, expect to merge several hundred.

Is your spreadsheet already out of control and you don't know where to start? Book a 30-minute call and we'll review your case together — cleaning and import included.

Step 4: import in two passes

Never import everything at once. The procedure we use:

1. Test import: 50-100 representative rows (with edge cases included on purpose). Verify field by field how they turned out.
2. Fix the mapping based on what broke — something always breaks: dates read in reverse, leading zeros in phone numbers swallowed, accents mangled.
3. Full import over the already-validated database.
4. Cross-check: the total number of contacts, the sum of open opportunities, and 20 records picked at random must all match against the spreadsheet.

Step 5: the cutover, without stalling sales

The classic mistake is the endless hybrid period: "let's keep loading on both sides just in case." That doubles the work and guarantees the CRM loses. What works:

• Pick a cutover date (a Monday, ideally in low season) announced two weeks ahead.
• From that date, the spreadsheet becomes read-only. It stays available for looking up the past, but nobody writes in it anymore.
• The cultural rule is announced by management and enforced: if it is not in the CRM, it does not exist — it does not enter the sales meeting, it does not count toward commissions.
• For the first 10 days, someone (internal or from the vendor) supports the team, resolving questions on the spot. The friction of the first week determines the adoption for the year.

On adoption it's worth being blunt: the real risk of the project is not technical, it is human. The cleanest data migration fails if the CRM adds load to the salesperson instead of taking it away. That's why the tool should arrive with automations that are felt from day one — follow-ups, reminders, minimal data entry — like the ones we describe in sales automation with a CRM, or directly with AI-automated workflows that eliminate manual data entry.

What you should NOT migrate

The counterintuitive part of the guide: migrating less is usually migrating better.

• Contacts with no interaction in 18-24 months (except in long-repurchase industries). Archive them in a backup Excel.
• Columns nobody filled in seriously: if "Next contact date" is empty in 80% of the rows, that field never worked; don't drag it along.
• Dead leads with no valid data: rows with a first name and nothing else are not data, they are noise.
• History older than 2 years in most industries: keep it as a reference archive, not as live records.

The complete original Excel is always kept as a frozen backup. Selective migration is not losing information: it is choosing which information deserves to stay alive.

Excel-to-CRM migration checklist

• Backup of the original Excel, frozen and dated
• Normalized spreadsheet: one row per contact, phones in a single format, status values unified
• Colors and informal codes converted into explicit columns
• Mapping table column → field → transformation, approved by someone who knows the operation
• Unique key defined (tax ID / email / phone) and spreadsheet deduplicated
• Documented decision on what does NOT migrate
• Test import (50-100 rows) verified field by field
• Full import with cross-check of totals
• Anti-duplicate blocking enabled in the CRM
• Cutover date announced; old spreadsheet read-only
• Team support during the first 10 days
• Rule enforced by management: if it is not in the CRM, it does not exist

If you made it this far, it's because the spreadsheet has outgrown you — a good sign: it means the business grew. At Deepyze we handle this full process, from cleaning your Excel to a CRM running with your team on board, whether on top of an all-in-one management system or a CRM designed around your own spreadsheet. Fixed price closed before we start, a proposal in 24 hours, and a team that works in your same time zone: tell us what your database looks like today and we'll plan it together.