CRM Data Migration from Spreadsheets: Step-by-Step Playbook

Sales teams that run on spreadsheets do it for a reason. The sheet bends to the rep's workflow. The CRM rep hires impose a schema that the sales team did not design. Most CRM rollouts fail not because the CRM is bad but because the migration loses the team's trust.

This playbook is what we ship at QUANT LAB USA when we migrate sales teams onto a custom CRM or onto HubSpot/Pipedrive/Close. The mechanics are the same regardless of destination. See also our Salesforce migration checklist.

1. Inventory every spreadsheet and identify owners
2. Design the target schema
3. Profile the source data
4. Build the ETL with a sales-side migration lead
5. Three-pass dedup with rep validation
6. Stage in a test environment
7. Parallel run for 2 to 4 weeks
8. Train reps with group sessions plus 1:1s
9. Cutover with rollback plan

Most sales teams have 3 to 30 spreadsheets in active use. Find them all. Talk to every rep, every sales ops person, every marketing lead. Ask: 'What spreadsheet do you open at the start of each day?' and 'What sheet do you use to pull weekly reports?' The answers will surprise you.

Catalog: owner, purpose, row count, last modified, columns, who else has access. Identify which sheets are canonical and which are derived. The derived ones can be auto-generated post-migration; the canonical ones are the migration source.

The CRM schema is the model your team will live in for years. Get it right. Standard objects for B2B sales:

• Account / Company: the buying organization
• Contact: individual people at the account
• Opportunity / Deal: the active sales process
• Activity: calls, emails, meetings, notes
• Owner: the rep responsible

Add custom fields only when they earn their place. Each custom field costs cognitive load. We commonly start with 10 to 15 custom fields per object and grow from there. See our Custom CRM Development Guide for deeper schema patterns.

Before you transform anything, profile the source. Questions to answer per spreadsheet:

• Total row count and unique-row count after trivial dedup
• Column-level null rate
• Date column formats (one column will have 5 different formats)
• Status column values (one column will have 20 free-text variants)
• Email validity (regex check)
• Phone normalizable rate
• Cross-sheet collisions (same email in 3 sheets, different status in each)

Output a 1-page profile per sheet. Share with the migration lead. Decisions about data treatment must be explicit, not implicit.

Build an ETL pipeline that is rerunnable. Migrations are not one-shot. Expect to run the ETL 5 to 15 times during validation. Each run should reset the staging environment.

Stack we use:

• Python or TypeScript scripts for transformation
• Source: gspread or pandas for Sheets/Excel
• Destination: CRM API (HubSpot, Pipedrive) or direct Postgres for custom CRMs
• Logging at every transformation step
• Reject queue for rows that fail validation
• Idempotent imports keyed on a stable external_id

Dedup is where automated migrations fail. The three-pass approach:

1. Pass 1 (high confidence): Exact email match. Auto-merge with the most-recent record winning on conflicting fields.
2. Pass 2 (medium confidence): Fuzzy email match (whitespace, case), name match within company. Flag for review.
3. Pass 3 (low confidence): Phone normalization match, name + company match. Always flag for review.

For passes 2 and 3, the migration lead reviews flagged matches. Approve, reject, or merge with custom field selection. Budget 2 to 8 hours of migration lead time per 10K records.

Never migrate directly to production. Stage in a copy environment that the migration lead and 1 to 2 reps can validate. Look for:

• Record counts match expected (source minus dedups)
• Sample contacts open correctly (5 random per rep)
• Sample deals show correct stage
• Activity history attached to correct contacts
• Reports run without errors
• Search returns expected results
• Permissions enforce correctly

Iterate the ETL until the staging environment passes rep validation. Most migrations run staging through 3 to 8 cycles.

Once staging passes, promote to production but keep spreadsheets in read-write mode. Reps use both systems for 2 to 4 weeks. Daily sync from spreadsheets to CRM during this period catches any data the team enters into the sheet that did not get into the CRM.

Track usage. If reps are still entering data in spreadsheets after 2 weeks, something is missing in the CRM and you need to fix it. If usage is shifting to the CRM, schedule the cutover.

Two-format training:

• Group walkthrough (60 minutes): daily workflow, key features, where to find things. Record it.
• Per-rep 1:1 (30 minutes each): sit with each rep, open their pipeline, walk them through their first hour in the new system.

Group-only training fails for 30 to 50% of reps. The 1:1s catch the workflow-specific issues. Pay your time for the 1:1s — it is the cheapest insurance on adoption.

Cutover on Friday afternoon. Team pauses entering new data into spreadsheets. ETL runs the final sync. Validation checks fire. Migration lead spot-checks 10 records per rep.

Spreadsheets go read-only Friday evening. Saturday morning: validate again. Monday morning: soft launch — team starts using the CRM as their primary system. Spreadsheets remain read-only for 30 days as a rollback option.

If a rollback is needed: revert CRM to read-only, return spreadsheets to read-write, debug the issue, replan the cutover. Never delete the source data during the rollback window.

Migration is not the end. Data quality decays within 3 to 6 months without active hygiene. Build in:

• Field validation rules (required, format, dropdown)
• Monthly dedup review by sales ops
• Auto-archive of contacts with no activity in 12+ months
• Quarterly schema audit (are fields still earning their place?)
• CRM adoption metrics (records updated per rep per week)

For ROI math on a clean CRM rollout, use our CRM ROI calculator.