Migrating from Spreadsheets to a CRM Without Losing Data (or Your Mind)

Most small businesses start in spreadsheets. A Google Sheet with customer names, phone numbers, and deal stages gets you surprisingly far — until it does not. The spreadsheet breaks when two people edit it at once. Deals fall through because no one saw the follow-up column. A rep leaves and takes the "their" tab with them.

Moving to a CRM with easy import fixes all of this, but the migration itself is where businesses lose confidence. They worry about corrupted data, missing contacts, or importing a mess that makes the new system worse than the old one.

This guide gives you a step-by-step process to migrate from a spreadsheet to a CRM cleanly. If you want the full context on why spreadsheets break down for growing teams, read our small business CRM guide first.

Before You Touch the CRM: Pre-Migration Preparation

The most common migration mistake is importing first and cleaning up after. Bad data in a CRM is harder to fix than bad data in a spreadsheet. Do the cleanup work before you export anything.

Step 1: Audit Your Spreadsheet

Open your spreadsheet and work through these checks row by row — or column by column if your dataset is large.

Find and remove duplicates. Sort by email address or company name and look for rows that represent the same contact. Most spreadsheet tools have a "remove duplicates" function, but review the flagged rows manually before deleting. Two rows with the same name but different emails might be a parent company and a subsidiary, not a duplicate.

Standardize phone numbers. Pick one format and apply it everywhere. The format you choose does not matter much — what matters is consistency. "+1 (555) 123-4567" and "5551234567" represent the same number but will appear as two different entries in a CRM's deduplication check.

Standardize dates. If your spreadsheet has "close date" or "contract date" columns, make sure every entry uses the same format (YYYY-MM-DD works reliably across systems). Inconsistent date formats are one of the leading causes of import errors.

Fill in obvious blanks. CRM records without a first name, last name, or email are hard to work with. If a row has a company name but no contact person, either find the contact or decide whether that row is worth importing at all.

Fix capitalization. "JASON MCDONALD," "jason mcdonald," and "Jason McDonald" will import as three different contacts to most CRMs. Use your spreadsheet's PROPER() function to standardize name capitalization in bulk.

Step 2: Define Your Column Mapping

Your spreadsheet columns will not match the CRM's field names. Before importing, create a written mapping document — even a simple table in a separate tab.

Example mapping:

Spreadsheet Column	CRM Field
Name	First Name + Last Name (split on space)
Phone	Phone (Mobile)
Email	Email (Primary)
Company	Company Name
Stage	Deal Stage
Notes	Contact Notes
Last Contact	Last Activity Date

Pay attention to fields that need to be split (one "Full Name" column split into "First Name" and "Last Name") or merged (separate "City," "State," and "Zip" columns into a single "Address" field, or keep them separate if your CRM supports it).

Write this mapping down before import day. You will refer to it multiple times during the process.

Step 3: Decide What Not to Import

Not everything in your spreadsheet belongs in your CRM. Importing irrelevant records wastes time on deduplication and clutters your new customer database.

Exclude these record types:

Closed or lost deals older than two years. Historical context is useful, but a deal that went cold in 2022 is not worth polluting your active pipeline view. If you need historical data for reporting, keep it in the spreadsheet as an archive.

Bounced or invalid email addresses. If you have a "bounced" column or know certain emails are dead, do not import them. Your CRM's email tools will flag them anyway, and starting with known-bad data sets a bad precedent.

Duplicate contacts you have not reconciled. If you found duplicates in Step 1 and did not merge them cleanly, leave those rows out for now. Import the clean records first, then address the messy ones one at a time.

Internal contacts and vendors. Your spreadsheet probably has some internal email addresses, supplier contacts, or partner records mixed in. Your CRM is for managing customer relationships — separate those rows out.

---

Migration Day

Once your spreadsheet is clean and your column mapping is documented, the actual import is straightforward.

Step 4: Export as CSV

Export your spreadsheet as a CSV file, not XLSX or ODS. CSV is the universal import format and avoids encoding issues that sometimes affect Excel files when imported into web-based CRMs.

If your spreadsheet has multiple tabs, export each tab as a separate CSV file. Import them in a logical order — contacts first, then companies, then deals.

Before exporting, remove any formula columns that are not actual data. If you have a column that calculates a value from other columns, either paste it as values or delete it before export. Formulas do not export meaningfully to CSV.

Step 5: Import Using Your Column Mapping

Most CRMs walk you through an import wizard that lets you map your CSV columns to CRM fields. This is where your mapping document from Step 2 pays off — you are just executing a plan you already made, not making decisions under pressure.

During the mapping step:

• Map every column you intend to use. Skip columns you decided not to import.
• If your CRM asks how to handle duplicates, choose "skip" or "update existing" rather than "create new." Creating new records for duplicates defeats the purpose of your pre-migration audit.
• If your CRM allows it, do a test import with a small sample (25-50 rows) before importing the full file.

Step 6: Review the First 10 Records Manually

After import, find the first 10 records in your CRM and compare them directly against the corresponding rows in your spreadsheet. Check:

• Does the name appear correctly?
• Is the phone number in the expected format?
• Did the deal stage import correctly?
• Are the notes intact and readable?
• Are there any fields that are blank that should have data?

If you find errors in the first 10 records, stop. Go back to your CSV, fix the issue systematically, delete the imported records, and re-import. It is much faster to catch a systematic problem on 10 records than to discover it after 500 imports.

Step 7: Handle Duplicates the CRM Flags

Even after your pre-migration audit, the CRM may flag additional duplicates it detects based on email, phone, or name similarity. Go through the flagged duplicates and resolve each one:

• Merge if they are clearly the same contact with slightly different data.
• Keep both if they are different people at the same company with the same last name.
• Delete one if one record is clearly incomplete or outdated.

Do not bulk-dismiss duplicate warnings without reviewing them. A CRM that starts with clean data is dramatically easier to maintain than one you need to audit again in six months.

---

Post-Migration: First Week

The import is done. Now verify it actually worked.

Step 8: Verify Total Contact Count

Pull your spreadsheet row count (subtract header rows and excluded records). Pull your CRM contact count. They should match within a few records. A large discrepancy — say, you imported 400 contacts but only 350 appear in the CRM — means rows were skipped due to errors. Check the import log if your CRM provides one.

If your CRM does not show an import log, filter contacts by "created date" for today and sort by creation time to see what was imported in what order. Look for gaps.

Step 9: Test One Complete Workflow End-to-End

Do not just look at data — exercise the system. Pick one real contact and walk through a complete workflow:

1. Find the contact record
2. Log a call note
3. Create a deal linked to that contact and configure your pipeline setup
4. Move the deal through two stages
5. Schedule a follow-up task
6. Send one email from within the CRM

If anything breaks or feels wrong, fix it now before the rest of the team starts using the system. A problem you find on day one takes 10 minutes to fix. A problem the team discovers on day 14 takes two hours to untangle because it has affected real records.

Step 10: Archive the Original Spreadsheet

Do not delete the original spreadsheet. Rename it to something like "Contacts Archive - Pre-CRM Migration - [Date]" and move it to a shared drive folder labeled "Archive." Store it for at least 12 months.

You will likely refer to it within the first 30 days when someone says "I cannot find the old notes from the Johnson account." The archived spreadsheet is your fallback reference, not your active system. Make the distinction clear to the team.

Step 11: Team Training

Even a perfectly executed migration fails if the team reverts to the spreadsheet out of habit. Schedule a 30-minute training session within the first three days. Cover:

• Where to find contacts
• How to log a call, email, or meeting
• How to move a deal through the pipeline
• How to create a follow-up task
• What to do when something looks wrong (who to contact)

Keep the session short and practical. Show, do not tell. Have each team member find a real contact and log something during the session. Hands-on practice in the first week creates habits faster than watching a demonstration.

---

30-Day Post-Migration Checklist

One month after migration, verify these items:

Data integrity

• Total contact count still matches (no phantom deletions or unexpected imports)
• No orphaned deal records without associated contacts
• All deal stages map correctly to your actual sales process
• Custom fields that were important in the spreadsheet are populated in the CRM

Team adoption

• Every team member has logged at least one activity in the CRM
• No one is maintaining a "personal" spreadsheet copy as their real system
• New contacts added during the month were added to the CRM, not the old spreadsheet

Workflows functioning

• Follow-up tasks are being created and completed
• Deals are moving through stages
• Email integration is working (emails sent from CRM are logging to contact records)
• Any automation sequences you set up are triggering correctly

Cleanup

• Duplicates that surfaced in week one have been resolved
• Any contacts imported without email addresses have been updated or flagged
• Fields that were blank at import have been filled in where possible

If you hit the 30-day mark and the team is still updating the spreadsheet alongside the CRM, that is an adoption problem, not a data problem. The fix is removing access to the spreadsheet (or at minimum, making it read-only) and reinforcing that the CRM is the system of record.

---

Common Migration Problems and How to Handle Them

"My column did not map to anything in the CRM." The CRM may not have a native field for everything in your spreadsheet. For non-standard data (a "Lead Temperature" score you invented, a custom product category), use a custom field in the CRM if available, or add the data to the notes field temporarily until you decide how to handle it properly.

"The import said it completed but I can only see some of my contacts." Check the import log for row-level errors. Common culprits: email addresses without @ symbols, phone numbers with letters in them, or dates in an unrecognized format. Fix those rows in the CSV and re-import only the failed rows.

"Two team members imported the same file and now I have duplicates." Use the CRM's bulk merge or duplicate resolution tool if it has one. If not, filter contacts by "created date" to identify the second import batch and delete those records, then re-merge any that were legitimately modified during the duplicate period.

"A deal from the spreadsheet does not have the contact attached." This happens when the import created deals and contacts as separate records without linking them. Most CRMs require contacts to exist before deals can be linked. Import contacts first, then deals, and use the email address as the linking key.

---

The Right Time to Migrate Is Before You Think You Need To

Most teams delay CRM migration until the spreadsheet problem is severe — deals are falling through, data is missing, the team is losing trust in the numbers. By that point, the migration is urgent and stressful instead of methodical.

If your spreadsheet is working "well enough" but you have more than 200 contacts or more than three people accessing it, you are already past the point where a customer database with proper access controls and audit logs serves you better.

Migration done right takes one focused day of preparation and about an hour of actual import work. The payoff — a clean, shared record of every customer relationship — compounds over every quarter that follows.

Photo by RDNE Stock project on Pexels