CRM Data Migration: The Complete Guide
CRM migration is where good software decisions go to die. The new platform is better, the team is willing, and then 40,000 records land in production with duplicated companies, deals owned by people who left in 2023, and a “stage” field containing eleven variations of “Negotiation.” This guide covers the migration sequence that avoids that outcome — what to clean, what to leave behind, the order to import in, and how to validate before anyone depends on the data.
Decide What Not to Migrate
The best migration decision is usually deletion. Before touching mapping spreadsheets, agree on exclusion rules:
- Contacts with no activity in 24+ months and no open deal
- Leads from campaigns that never converted, older than 18 months
- Deals lost more than three years ago (export to archive instead)
- Records with no email and no phone number
- Notes attached to deleted or merged records
- Any custom field populated on under 10% of records
For most companies this removes 30–50% of the database. Smaller, cleaner data migrates faster, imports more reliably, and produces reports people trust.
Step 1: Audit the Source System
Run a real inventory before planning anything:
| What to count | Why it matters |
|---|---|
| Total records per object | Sets import batch sizes and API cost |
| Custom fields and fill rate | Identifies what to drop |
| Picklist values in use | Reveals standardization work |
| Record owners, including inactive users | Prevents orphaned records |
| Attachments and total storage | Often the slowest part of migration |
| Automations and integrations | Each must be rebuilt, not migrated |
Export this to a spreadsheet. It becomes your migration scope document.
Step 2: Clean Before You Map
Cleanup happens in the source or in an intermediate spreadsheet — never in the destination after import.
- Deduplicate contacts on email first, then on name plus company
- Deduplicate companies on website domain, which is far more reliable than name
- Standardize picklists — one canonical value per stage, source, industry, and country
- Normalize formats — phone numbers to E.164, dates to ISO, consistent capitalization
- Reassign orphaned records from departed owners to a current person or a house account
- Fill required fields or exclude the records that can’t be fixed
Deduplication is the step teams most often defer, and it’s the one that permanently damages reporting if skipped.
Step 3: Build the Field Mapping Sheet
One row per source field. Columns: source field, source type, destination object, destination field, destination type, transformation rule, required?, sample value.
Watch for these mapping traps:
- Free text → picklist: requires a value translation table
- Multi-select fields: many platforms expect semicolon-delimited strings
- Currency: confirm the destination stores currency code, not just amount
- Dates: time zone handling silently shifts close dates by a day
- Lookup relationships: need external IDs, not display names
- Booleans: “Yes/No”, “TRUE/FALSE”, and 1/0 are not interchangeable
Have someone who didn’t build the sheet review it. Mapping errors are cheap to catch here and expensive to catch later.
Step 4: Import in the Right Order
Order matters because records reference each other.
| Batch | Object | Depends on |
|---|---|---|
| 1 | Users / owners | — |
| 2 | Companies / accounts | Users |
| 3 | Contacts | Companies, users |
| 4 | Open deals | Contacts, companies, users |
| 5 | Closed deals | Contacts, companies, users |
| 6 | Activity history (calls, emails, meetings) | All of the above |
| 7 | Notes and attachments | All of the above |
| 8 | Custom objects | Varies |
Always carry an external ID — the source system’s record ID — into a dedicated field on every object. It’s how you re-link records, detect duplicates on re-import, and roll back cleanly.
Step 5: Run a Test Migration First
Never go straight to production. Import 200 representative records into a sandbox or a test instance and check:
- Do relationships link correctly (contact → company → deal)?
- Are dates showing the same day they showed in the source?
- Did picklist values map, or did they silently create new options?
- Are owners assigned correctly?
- Do currency amounts match to the cent?
- Did special characters, accents, and emoji survive encoding?
Fix, re-export, re-import. Expect two or three test rounds. That’s normal, not a sign of failure.
Step 6: Validate the Production Import
After each production batch, validate before starting the next:
- Row counts: source rows in, destination rows created, plus a documented reason for any gap
- Random sampling: 20 records per batch, field by field, against the source
- Aggregate checks: total open pipeline value, deal count by stage, contacts per owner — these should match the source within rounding
- Duplicate scan: run the platform’s duplicate detection immediately after import
- Spot-check the extremes: the oldest record, the newest, the largest deal, the record with the most activity
Step 7: Rebuild What Doesn’t Migrate
These never transfer and must be rebuilt in the destination:
- Workflows, automations, and sequences
- Reports and dashboards
- Email templates
- Permission sets and role hierarchy
- Integrations and webhooks
- Scoring models and routing rules
Rebuild only what was actually used. Migration is the best opportunity you’ll ever get to delete the 40 reports nobody opened.
Step 8: Plan the Cutover
| Time | Action |
|---|---|
| T-7 days | Freeze structural changes in the source system |
| T-2 days | Final full export, final dedupe pass |
| T-1 day | Import batches 1–5, validate |
| Day 0 (morning) | Import activity history, notes, attachments |
| Day 0 (midday) | Full validation, duplicate scan |
| Day 0 (afternoon) | Switch source to read-only, announce go-live |
| T+1 to T+7 | Daily data-quality checks, fast fixes |
| T+90 | Decommission source after final archive |
Cut over on a Tuesday or Wednesday. Never on a Friday, never at quarter-end.
Have a Rollback Plan
Before go-live, be able to answer three questions: Where is the last full export of the source? How do we bulk-delete an incorrect import batch (using the external ID field)? Who decides to roll back, and by when? Most rollbacks are partial — one bad batch, not the whole migration — which is exactly why the external ID matters.
Common Migration Mistakes
- Migrating everything because deciding what to cut feels risky
- Skipping deduplication and permanently corrupting reporting
- No external ID field, making re-linking and rollback impossible
- Importing activity history first, which orphans records
- Testing with clean sample data instead of your real messy data
- Deleting the source system too early
- Announcing go-live before validation is complete
FAQ — CRM Data Migration
Q: How long does CRM migration take? A: For under 10,000 records with modest customization, 2–4 weeks including cleanup. Above 100,000 records with custom objects and attachments, 2–4 months.
Q: Should we use a migration tool or CSV import? A: Under roughly 50,000 records, CSV import plus careful mapping is fine and gives you full control. Above that, or with heavy attachments, a dedicated migration tool or partner saves real time.
Q: Can we migrate email history? A: Rarely in full. Most teams sync email going forward and migrate only emails attached to open deals. Historical email usually lives better in the mailbox than the CRM.
Q: What about attachments and documents? A: They migrate slowly and often hit API limits. Many teams leave documents in cloud storage and migrate links instead of files.
Q: How do we handle records owned by people who left? A: Reassign to a current owner or a house account before export. Importing records owned by inactive users creates records nobody can see.
Related Reading on CRMLYTIC
- CRM Implementation Guide: 10 Steps to Launch Without Chaos
- Best CRM Software in 2026: Complete Buyer’s Guide
- Customer Data Management Best Practices
- CRM User Adoption: Getting Your Team to Actually Use It
- CRM Metrics That Actually Matter
Bottom Line
Migration quality is decided before a single record moves. Cut aggressively, deduplicate on email and domain, carry an external ID on everything, import in dependency order, and validate each batch against the source. Do that and your new CRM starts trustworthy — which is the only condition under which people will use it.
This article is for informational purposes only.
By CRMLYTIC Editorial · Updated August 3, 2026
- crm migration
- data cleanup
- data quality