CRM Data Migration Guide: Move Records Between Platforms Without Data Loss

⏰ FAST FIX (5 Minutes — Minimum Viable Migration Path)

If you need to move a small set of contacts between CRMs today:

1. Export from source CRM — export Contacts (and Accounts separately) as CSV
2. Rename columns to the target CRM's expected field names using the CRM field mapping guide
3. Clean the data — normalize date formats to YYYY-MM-DD, standardize phone formats, deduplicate on email using Data Cleaner
4. Validate — run through Data Validator and confirm zero critical errors
5. Import a sample of 50 records first — check five records manually in the target CRM before importing the full set

For migrations over 10,000 records or involving custom fields, activity history, or relationships — the full workflow below is required.

---

TL;DR: CRM migrations fail in the data cleaning phase — not at export or import. The export is straightforward. The import tool is reliable. The gap between them (field mapping, format conversion, deduplication, relationship preservation) is where data loss happens. A five-phase workflow with a test import before full migration reduces that risk significantly. Data Cleaner →

---

Your company is moving from Salesforce to HubSpot — or from any CRM to any other CRM. The sales team has been told the migration is "seamless." The IT manager has been told it takes "a few hours." You are the person who has to make both of those statements true.

CRM migrations are not seamless. They involve exporting data in the source CRM's format, transforming it to match the target CRM's field structure, cleaning data quality issues that the source CRM never flagged, resolving relationship dependencies (contacts linked to accounts, deals linked to contacts), and validating the result before a single record lands in the new system.

Migrations that "lose" data don't lose it at export or import. They lose it in the transformation step — a custom field with no equivalent in the target CRM, a date format that the target importer silently skips, a contact linked to an account that hasn't been imported yet.

Most CRM migration services and data transformation tools upload your complete customer database to remote servers for processing. A full CRM export — including contact names, emails, phone numbers, deal values, and communication history — represents the most comprehensive PII dataset your organization holds. Uploading it to a third-party migration service may trigger GDPR Article 5(1)(c)'s data minimization requirement, GDPR Article 28 processor obligations, and depending on content, CCPA service provider contract requirements under California Civil Code §1798.100. SplitForge cleans, validates, and transforms your migration file entirely in Web Worker threads in your browser. Your customer database never reaches any server. Confirm in Chrome DevTools → Network tab — zero outbound file transfer.

This migration workflow was validated across Salesforce, HubSpot, Zoho CRM, and Pipedrive export and import cycles, March 2026.

For the complete CRM import failure taxonomy, see our CRM import failures complete guide.

---

📋 Table of Contents

• Why CRM Migrations Fail
• Phase 1: Export from the Source CRM
• Phase 2: Field Mapping
• Phase 3: Data Cleaning
• Phase 4: Validation and Test Import
• Phase 5: Full Import and Verification
• Migration Checklist
• Common Migration Failures
• Additional Resources
• FAQ

---

The Five-Phase Migration at a Glance

EXPORT → MAP → CLEAN → VALIDATE → TEST → IMPORT → VERIFY

Phase 1: Export        Phase 2: Map         Phase 3: Clean
Pull all objects       Field-by-field        Dates, phones,
in dependency          decision for          picklists, dedup,
order                  every column          company names

                Phase 4: Validate    Phase 5: Import
                Zero critical         Accounts first,
                errors before         then Contacts,
                proceeding            then Deals

This sequence is fixed. Skipping or reordering phases is the most common source of failed migrations — specifically, importing before cleaning (creates bad data in the new CRM) and importing Contacts before Accounts (orphans contacts from their company records).

Migration Failure Probability by Phase

Where migrations actually break — based on the 8,200-contact Zoho→HubSpot example and patterns across multiple migrations. The export phase is reliable. The cleaning phase is where most time and most errors occur.

The 80/20 rule of CRM migration: 80% of migration failures occur in two phases — field mapping and data cleaning — which together account for the planning and execution work. Export and import are reliable by comparison. Invest time in Phase 2 and Phase 3. Rushing them extends the overall timeline, not shortens it.

---

Why CRM Migrations Fail

CRM migrations fail for three recurring reasons: field mapping gaps (a field in the source CRM has no direct equivalent in the target), silent format rejection (the target CRM skips records with invalid date or phone formats without flagging them), and relationship dependency failure (contacts import before the accounts they're linked to, breaking the relationship).

❌ BROKEN — common migration data failures:
Field/Issue         Source value       Target result        Why
Date field          "03/20/2026"       Silently skipped     Target expects YYYY-MM-DD
Phone field         "(555) 555-0101"   Imported as text     Target expects +15555550101
Custom field        "Enterprise"       Not imported         No equivalent field configured
Account link        Contact #4521      Contact orphaned     Account #201 not imported yet
Lifecycle stage     "SQL"              Rejected             Not in target CRM's picklist
Owner field         "John Smith"       Owner blank          Target requires user email

FIXED — before migration:
- Dates converted to ISO 8601: "2026-03-20"
- Phones standardized to E.164: "+15555550101"
- Custom field mapped to nearest equivalent or archived separately
- Accounts imported before contacts (dependency order)
- Lifecycle stage values mapped to target CRM's accepted list
- Owner names resolved to active user email addresses

---

Phase 1: Export from the Source CRM

Every major CRM supports full data export as CSV. Export objects in this dependency order:

1. Accounts / Companies — export first; contacts depend on them
2. Contacts / Leads — export second; include the Account association field
3. Deals / Opportunities — export third; include Contact and Account associations
4. Activities — export last if your target CRM supports activity import (many don't)
5. Custom objects — export separately and assess target CRM compatibility before migrating

What to include in each export:

• All standard fields — include every column even if some fields will be unmapped; it's easier to remove columns than to re-export
• All custom fields — some will need manual mapping or archiving
• Record IDs — keep source CRM IDs in a separate column; you'll need them to reconstruct relationships
• Owner information — export as both name and email if available

What most CRMs don't export automatically:

• Email communication history (usually not exportable via CSV)
• File attachments
• Field-level audit history
• Integration data from connected apps

Document what can't be exported before communicating the migration scope to stakeholders. "Seamless migration" means contacts, accounts, and deals — not email history or attachments in most cases.

---

Phase 2: Field Mapping

Field mapping is the highest-risk phase of any CRM migration. Every field in the source export needs a decision: map to an existing target field, create a custom field in the target CRM, or archive the data outside the CRM.

Use the CRM field mapping guide for standard field mapping across Salesforce, HubSpot, Zoho, and Pipedrive.

For the migration-specific mapping decisions:

Owner field mapping is the highest-failure-rate step. Source CRM owners are identified by name, user ID, or email. Target CRM owners must be identified by an active user email in the target system. Build a source-to-target owner mapping table before running any imports.

---

Phase 3: Data Cleaning

Data cleaning resolves quality issues that the source CRM accumulated over time. Every CRM contains data quality debt — partial records, inconsistent formats, values that were valid in the old system but won't pass the new system's validation.

The six cleaning operations required in most migrations:

3a. Date Format Conversion

Convert all date fields to ISO 8601 (YYYY-MM-DD). Most CRMs export dates in locale-specific formats (MM/DD/YYYY for US exports, DD/MM/YYYY for European exports). The target CRM's importer may silently skip records with unexpected date formats.

See our date format guide for CSV imports for conversion methods.

3b. Phone Number Standardization

Standardize all phone numbers to E.164 format (+15555550101) if the target CRM validates against that standard. Remove formatting characters — parentheses, dashes, spaces, extensions — before import. See our international phone number cleaning guide for country-specific guidance.

3c. Company Name Normalization

Normalize company name variations before importing Accounts — particularly critical if accounts are being deduped in the target CRM. See our company name normalization guide for the complete normalization workflow.

3d. Email Validation

Validate all contact email addresses for format correctness. Contacts with invalid email addresses import successfully in most CRMs but create records that can never be used for outreach. Invalid format patterns: missing @ symbol, invalid domain, role-based addresses the target platform blocks.

3e. Picklist Value Remapping

Source CRM picklist values (Lead Status, Industry, Lifecycle Stage) rarely match target CRM values exactly. Build a value mapping table: source value → target value → handling for unmappable values (map to closest equivalent, archive in a notes field, or leave blank).

3f. Deduplication

Deduplicate the export before import. Source CRM dedup tools may have been underused. Run dedup on email for contacts and on normalized company name for accounts. See our CRM deduplication guide for the full workflow.

---

Phase 4: Validation and Test Import

Test before migrating at full scale. This is the step most migrations skip — and the step most migrations regret skipping.

Test import sequence:

1. Select a representative sample of 100-200 records that includes edge cases (blank fields, special characters in names, non-US phone formats, custom field values)
2. Import the sample to the target CRM
3. Manually spot-check five records: open the CRM record and compare field by field against the source export row
4. Check relationship integrity: do contacts link correctly to their Account records?
5. Check owner assignment: are records assigned to the correct owner?
6. Confirm custom fields populated correctly
7. Fix any issues identified, re-export the corrected sample, and re-test before proceeding

---

Phase 5: Full Import and Verification

Once the test import is clean, run the full migration in dependency order:

1. Import Accounts / Companies first — contacts will link to these by name or ID
2. Import Contacts — after accounts are confirmed in the target CRM
3. Import Deals / Opportunities — after contacts and accounts are confirmed
4. Import custom objects — if the target CRM supports them

After each phase, confirm the record count in the target CRM matches the expected post-dedup count from your export.

Post-migration verification checklist:

• Record counts match source export (accounting for intentional dedup)
• Random spot-check of 10 records: field by field comparison
• Owner assignment confirmation for all imported records
• Relationship integrity check: contacts linked to correct accounts
• At least one Deal linked to correct Contact and Account

---

Migration Timeline by Record Volume and Complexity

Realistic timelines vary more by data quality than record volume. A 50,000-record export from a well-maintained CRM migrates faster than an 8,000-record export from five years of inconsistent manual entry. These estimates assume the five-phase workflow above.

"Messy" indicators: inconsistent date formats across rows, owner names not resolvable to user emails, picklist values that don't exist in the source CRM's current settings, duplicate rates above 5%, blank required fields in more than 10% of records.

When to consider the API over CSV: migrations above 200,000 records with tight data integrity requirements are often better served by a middleware tool or direct API integration. CSV migration works at this scale but requires more batching and verification cycles.

---

Real-World Example: 8,200-Contact Zoho → HubSpot Migration

A SaaS company migrated from Zoho CRM to HubSpot after two years on Zoho. Contact count: 8,200. Custom fields: 14. Timeline expectation: three days. Actual timeline: nine days. Here's what broke.

Phase 1 — Export: Zoho exported cleanly. Row count matched. All 14 custom fields were included. No issues at export.

Phase 2 — Field mapping: 11 of 14 custom fields mapped to HubSpot equivalents. Three had no direct match — a "Sales Region" dropdown, a "Contract Tier" text field, and a "Last Demo Date" datetime. The Sales Region values also didn't match HubSpot's territory conventions. Two days spent creating new HubSpot custom properties and remapping 400 rows with non-standard Sales Region values.

Phase 3 — Cleaning: Zoho exported dates as DD-MMM-YYYY (e.g., 20-Mar-2026). HubSpot expected YYYY-MM-DD. Every date field across 8,200 rows required format conversion — approximately 65,000 individual date values across 8 date columns. Owner names required lookup against HubSpot user emails; two former employees needed reassignment to a current rep.

Phase 4 — Test import: 150-record sample revealed that the Contract Tier text field was exceeding HubSpot's 65,536-character limit on five records (very long notes had been stored in this field). Those five records required manual truncation.

Phase 5 — Full import: Ran cleanly after fixes. Final record count: 7,948. The 252 difference was intentional deduplication (3.1% duplicate rate in the original export).

Total time lost to preventable issues: 6 of the 9 days were spent on date format conversion and custom field remapping — both predictable from a pre-migration audit. The lesson: the field mapping phase (Phase 2) is where the timeline is determined, not at import.

---

Migration Checklist

---

Common Migration Failures

Contacts imported before Accounts. When contacts import before their associated accounts exist in the target CRM, the contact-account relationship breaks — the contact imports but is orphaned. Always import Accounts first, confirm they've landed, then import Contacts.

Picklist values not remapped. Source CRM Lead Status values (SQL, MQL, Hot Lead, Cold) don't exist in the target CRM's picklist. The import silently skips the field or rejects the record. Remap all picklist values before import.

Owner assignment fails silently. The owner field contains a name or a source CRM user ID. The target CRM requires an active user email. Records import with no owner — assigned to the default queue or left blank. Build the owner mapping table before cleaning.

Custom fields not created in target CRM before import. If custom fields don't exist in the target CRM when the import runs, the data in those columns is silently dropped. Create all custom fields in the target CRM before the first import attempt.

---

Additional Resources

CRM Export and Import Documentation:

• Salesforce: Export CRM Data — Data Export Service and report export options
• HubSpot: Export CRM Data — Export all objects including custom properties
• Pipedrive: Import/Export Data — Import and export documentation

Data Standards:

• ISO 8601: Date and Time Formats — Date format standard used across CRM importers
• RFC 4180: CSV Format Specification — CSV structure standard for migration files

Privacy:

• GDPR Article 5: Data Minimization — Limiting third-party processing of customer data during migration
• GDPR Article 28: Processor Obligations — When migration services become data processors
• CCPA: California Consumer Privacy Act — Service provider obligations for customer data processing

---

FAQ