The Ultimate CRM Data Migration Checklist: A 10-Point Plan for a Zero-Loss Transition

A CRM data migration checklist that works needs to account for relational data integrity, API rate limits, compliance constraints, and the specific failure modes that corrupt revenue data. Most guides treat migrating between Salesforce, HubSpot, or Pipedrive like a CSV upload — export rows, import columns, done. They skip the part where a single misordered import orphans every deal in your pipeline.

CRM data migration is a schema-translation problem. Your historical deal data, multi-object associations, custom fields, and attribution data are held together by relational links. A CSV export flattens those relationships into rows and columns, silently destroying the associations that make your data useful. If you rely on basic spreadsheet imports, you will orphan activity logs, break pipeline stages, duplicate contacts, and permanently lose the historical context your sales team needs to close deals.

This guide gives you the 10-point execution plan covering the exact order of operations, technical constraints per platform, and failure modes that catch teams mid-quarter.

For platform-specific guides, see Pipedrive to HubSpot Migration: Data Mapping, APIs & Rate Limits or Salesforce to HubSpot Migration: Pipeline, Tickets & Attachments.

How Long Does a CRM Migration Take?

CRM migration duration depends on integration count and custom object complexity far more than raw record volume. Loading data is not the bottleneck. Planning, data prep, and validation are.

Published timelines disagree with each other, so treat any single number with suspicion. The right sizing input is your integration count and custom object count, not your database size. A migration moving 100,000 standard contacts takes less time than one moving 10,000 contacts with complex custom objects, polymorphic relationships, and terabytes of file attachments.

Which phase takes the longest?

Data preparation — cleansing, deduplication, and field mapping — is the largest single block of project time. This is also the phase most teams compress. That compression does not save time — it shifts it into post-migration cleanup, which costs considerably more than cleaning records before the move, because duplicates, bad associations, and merge conflicts compound once replicated.

What actually drives the timeline?

The timeline expands when record identity, associations, and business rules are unclear. Five factors dominate the schedule:

1. Identifier quality: If you do not have a stable migration key for each object, every rerun becomes a duplicate-generation event.
2. Association complexity: A CRM is a relational database. You must migrate data in a strict hierarchical order to preserve links.
3. Polymorphic relationships: When a single field on an object can reference multiple different types of parent objects (like Salesforce's WhoId and WhatId), your migration script must dynamically check the target object type before assigning the ID.
4. Unsupported activity behavior: Activity history is not uniformly portable. Some platforms limit what can be updated after import, making activity preservation a staged process.
5. Automation and permission parity: The new CRM must enforce the same required fields, stages, permissions, and workflow side effects the old one did.

Why Generic CRM Migration Checklists Fail

The catastrophic failure modes in CRM migrations aren't missing records. They're structural:

• Orphaned deals — Opportunities imported without valid Account or Contact associations, invisible to pipeline reports
• Broken attribution — Activity history detached from parent records, destroying the timeline sales reps rely on
• Duplicate contacts — Pre-existing duplicates multiplied during import because the migration tool doesn't deduplicate
• Lost consent records — GDPR opt-in timestamps and CCPA opt-out flags silently dropped, creating compliance exposure
• Corrupted forecasting — Pipeline stages mapped incorrectly between source and target, inflating or deflating revenue projections
• Multi-currency mismatches — Exchange rates, currency codes, or currency field mappings lost in translation, silently converting deal values to the wrong currency or collapsing multi-currency pipelines into a single denomination
• Multi-language field corruption — Non-Latin characters, right-to-left text, or locale-specific date/number formats mangled during export-import, breaking contact names, addresses, and notes across international records

Every one of these has happened in real migrations. The checklist below is designed to prevent them.

Phase 1: Pre-Migration Data Audit and Mapping Strategy

Before you extract a single record, you must understand the structural mismatch between your source CRM and your target system.

Audit Data Quality Before You Touch a Migration Tool

Data quality is the single biggest variable in migration success. Clean data migrates fast. Dirty data creates compounding problems that surface weeks after go-live.

Run these checks against your source CRM before doing anything else:

• Duplicate rate: Measure your duplicate rate with a proper deduplication process before you migrate. A high rate means data quality is already degrading sales operations, regardless of which CRM you're on.
• Completeness: How many contacts lack email addresses? How many accounts have no associated deals? How many deals have no owner?
• Stale records: Records with no activity in 18+ months are candidates for archival, not migration.
• Consent integrity: Verify that GDPR consent timestamps, lawful basis tags, and CCPA opt-out flags exist as structured fields — not buried in notes or free-text.
• Multi-currency consistency: If your source CRM tracks deals in multiple currencies, verify that currency codes are populated on every deal record, exchange rates are current, and no records have ambiguous or missing currency designations. Migrating a deal with an amount but no currency code means you're guessing — and guessing wrong corrupts pipeline reporting.

For guidance on using AI to assist with data cleanup and field mapping, see Using Generative AI in SaaS Data Migration. For a hard look at why scripting your own cleanup is riskier than it seems, read Why DIY AI Scripts Fail.

Map Relational Dependencies and Custom Objects

Before mapping individual fields, map the object graph. CRM data has a strict hierarchy, and your migration must respect it:

Accounts/Organizations (parent)
  └── Contacts/Persons
        └── Deals/Opportunities
              └── Activities (calls, meetings, tasks)
              └── Notes
              └── Attachments/Files
              └── Email logs

Every downstream object depends on its parent's ID in the target system. If you import Deals before their associated Accounts exist, those Deals become orphans — unlinked, invisible to reports, and effectively lost.

Custom objects and fields are the second mapping challenge. Every CRM handles architecture differently:

• Pipedrive supports custom fields but not custom objects. Its architecture is highly sales-pipeline-centric.
• HubSpot supports custom objects only on Enterprise tier (default limit of 10 definitions). Association label imports require Professional or Enterprise. (knowledge.hubspot.com)
• Salesforce supports both custom fields and objects extensively, with a highly configurable schema.
• Dynamics 365 uses Dataverse entities.
• Zoho CRM uses credit-based API access with concurrency limits.

Create a mapping sheet with columns for source object, source ID, target object, target field, data type, transform, required, default, dedupe key, and parent key. On every target object, add a legacy_id or equivalent immutable source key. In Salesforce, external IDs support both upsert and relationship resolution. In HubSpot, Record ID supersedes other identifiers during import, and custom properties can serve as unique keys for contacts, companies, deals, tickets, and custom objects. (developer.salesforce.com)

Two HubSpot edge cases worth calling out: Company Domain Name only accepts values up to the top-level domain, so subdomain-heavy source data needs normalization or a different unique key. And if you import contacts with both Record ID and a secondary email, the secondary email can replace the primary email. Those sound small until they create duplicate companies or bad email identity data at scale. (knowledge.hubspot.com)

For a reusable template approach, see How to Create a Data Migration Checklist.

Phase 2: API Limits and Export Constraints by Platform

API rate limits are the hard constraint that determines how long your migration takes and whether your scripts fail silently. High-volume extractions and imports must be architected around these constraints, or you'll hit HTTP 429 errors, partial data loads, and stalled migrations.

Platform Rate Limits

(resources.docs.salesforce.com) (developers.hubspot.com) (pipedrive.readme.io)

These limits are not theoretical. A Salesforce org with 50 Enterprise users gets roughly 150,000 daily API calls on the standard REST API — sounds generous until you realize your existing integrations (marketing automation, support tools, BI dashboards) are already consuming 60–80% of that allocation. Your migration competes with production traffic.

HubSpot's burst limit is the one that bites hardest during migrations. At 190 requests per 10 seconds, a migration script without proper throttling triggers 429 errors within seconds. The Associations API is stricter — capped at 150 requests per 10 seconds and 500,000 per day, with batch create limited to 2,000 associations. (developers.hubspot.com) The CRM Search API is limited to 5 requests per second per token and caps results at 200 records per page — and search responses don't include the normal rate-limit headers. If your script uses search for deduplication checks during import (which it should), search becomes your primary bottleneck.

Dynamics 365 / Dataverse evaluates service protection limits in five-minute sliding windows and returns 429 Too Many Requests when request volume, concurrency, or execution time exceeds platform thresholds. Client applications must implement retry patterns rather than assume linear throughput.

Zoho CRM uses edition-based daily API credits, limits insert/update/upsert calls to 100 records per API call, and enforces both general concurrency limits and a sub-concurrency limit of 10 on heavier APIs such as Query, Composite, and larger upsert operations.

File attachments deserve separate planning

Migrating files (PDFs, contracts, images) takes significantly longer than migrating text data. Most CRM APIs require files to be converted into Base64 encoded strings before transmission over JSON, increasing file size by approximately 33%. If you are moving 500 GB of contracts, you are actually transmitting over 660 GB of payload data.

Many CRMs enforce strict payload size limits per API call (often 10–50 MB). Large files must be broken into chunks, transmitted sequentially, and reassembled in the target system. If your legacy CRM holds years of email attachments, this phase alone can consume an entire week of processing time.

Design Your Extraction Architecture

For any source CRM with more than ~50,000 records, direct REST API extraction is too slow and too expensive against your API quota. Use bulk extraction where available:

• Salesforce: Use Bulk API 2.0 for extraction. Query jobs don't consume batch allocations — only ingest jobs do. Extract all objects via SOQL queries, stage the data locally, transform, then load. Salesforce recommends Bulk API for loads over 2,000 records. Keep uploads under roughly 100 MB of raw CSV even though the job cap is 150 MB, because base64 expansion can push the payload over the limit. (resources.docs.salesforce.com)
• HubSpot: Use the CRM API with pagination (after cursor). Batch read endpoints retrieve up to 100 records per call. For large datasets, export via the native UI first, then use the API for delta updates.
• Pipedrive: Paginate GET endpoints (limit 500 items per page). Since Pipedrive has no bulk export API, extraction from large instances requires careful pagination and rate management.

The 10-Point CRM Data Migration Checklist

This is the execution sequence. Order matters — steps build on each other.

1. Freeze Schema Changes, Not the Sales Floor

Lock field creation, pipeline stage edits, validation-rule changes, dedupe jobs, and automation modifications in both systems. Let reps keep working. What you're freezing is model drift, not revenue activity. Mid-migration stage changes or new required fields are how correct loads start failing halfway through.

If a full data freeze isn't possible mid-quarter, define a "soft freeze" where reps continue working but all changes are tracked for later reconciliation via delta sync.

2. Export a Full Restorable Backup

Before any transformation or loading, take a complete backup of the source system. This is your rollback safety net and your post-migration source of truth.

• Salesforce: Use Data Export Service or Bulk API 2.0 query jobs. Data Loader supports up to 5,000,000 records with Bulk API. (help.salesforce.com)
• HubSpot: Use native export per object type (Contacts, Companies, Deals, Tickets)
• Pipedrive: Export via Settings → Data Export → select all objects

Store backups in a versioned, access-controlled location (like a PostgreSQL database or a secure AWS S3 bucket). Restore a small slice before cutover day so the backup is proven, not assumed.

What does a rollback plan need?

A rollback plan is a documented procedure for reverting to the old CRM if the migration produces unacceptable results. It is not optional. A credible rollback plan includes maintaining the legacy system in a read-only state for a defined period, documenting the process for reverting integrations and automation, establishing clear criteria that trigger a rollback decision, and assigning ownership for that decision to a named individual.

Rollback triggers should be quantitative, not political (e.g., data corruption detected in more than 1% of records, record count discrepancy exceeding 5%, critical integrations failing post-cutover). Define rollback criteria before cutover, not during it. Keep the legacy CRM read-only — not deleted — for at least 30–60 days post-go-live.

3. Create Immutable Legacy IDs and Explicit Dedupe Rules

Store the source primary key on every imported object and make it unique where the target allows. In Salesforce, external IDs support both upsert and relationship resolution — this is the cleanest way to maintain parent-child links across load passes. (developer.salesforce.com) In HubSpot, Record ID supersedes other identifiers during import, so be explicit about whether a load is creating or updating.

Do not dedupe on names alone. This one control prevents most duplicate-contact and orphaned-deal disasters.

4. Map Custom Fields and Execute Schema Translation

Create a field-level mapping document covering:

• Field name in source → field name in target
• Data type transformations (e.g., Pipedrive multi-option custom fields → HubSpot multi-select dropdowns)
• Picklist value alignment (stage names, lead sources, industry codes)
• Required fields in the target that don't exist in the source (these need default values or enrichment)
• Fields to drop — not everything deserves migration
• Currency fields — verify the currency code travels with the amount. If the source stores currency as a record-level property and the target expects it as a field-level attribute (or vice versa), write the transform explicitly. Migrating a €50,000 deal into a USD-default pipeline without the currency code turns it into $50,000 — a silent data corruption that inflates or deflates forecasts.

Watch for name-splitting issues: HubSpot stores full name as a single field; Salesforce splits it into First Name and Last Name. This mismatch is a top duplicate generator.

Identify data type mismatches early. A "Status" field in the legacy system might be a free-text string, while the target requires a strict picklist. Write transformation logic to normalize these values before ingestion.

5. Define the Hierarchical Load Order

This is the step most DIY migrations get wrong. Records must be created in the target system in strict hierarchical order:

1. Users / Owners — so records can be assigned correctly
2. Accounts / Companies / Organizations — the top-level parent objects
3. Contacts / Persons — linked to their parent Accounts
4. Deals / Opportunities — linked to Contacts and Accounts
5. Activities, Notes, Emails — linked to Deals, Contacts, or Accounts
6. Attachments / Files — linked to their parent records
7. Custom Objects — dependent on all standard objects above

Each step requires capturing the new target-system IDs for every created record, then using those IDs to establish associations in subsequent steps. Self-referencing hierarchies (like parent accounts) need a second pass. Many-to-many relationships should be loaded only after both sides exist. In HubSpot, you can associate during record creation only when the related record already exists; otherwise use the Associations API afterward. (developers.hubspot.com)

Pass 1: users, pipelines, custom fields, custom objects
Pass 2: accounts / companies
Pass 3: contacts / people
Pass 4: opportunities / deals
Pass 5: activities, notes, emails, meetings
Pass 6: files, labels, junctions, parent hierarchies

Build the destination schema before the first production row lands: pipelines, stages, owners, currencies, picklists, custom fields, custom objects, and association labels. If the target CRM cannot store a custom object or rejects stage values, the problem is your target setup, not your migration script.

6. Run a Full Sandbox Test Migration

Never push data directly into production. Use a sandbox (Salesforce), a test portal (HubSpot), or a developer environment.

Run a 100% data volume test, not a sample. A 10% sample is insufficient because edge cases, deep nested relationships, and API rate limits only reveal themselves under full load. Your pilot set should include:

• Records with the maximum number of associations
• Records with custom field values across all picklist options
• Records with attachments and activity history
• Records with non-ASCII characters in names or addresses
• Edge cases: contacts linked to multiple deals, deals with no associated contact, null owners, closed-lost deals, long notes
• Records with non-default currencies, if your CRM tracks deals in multiple currencies

On Salesforce, that rehearsal should use Bulk API 2.0 if you expect more than 2,000 records, because that's where timeout, retry, and batch behavior shows up.

Validate every relationship, not just record counts.

7. Validate Relationship Integrity

After the test migration, run programmatic validation. Do not rely on spot-checking. The most valuable validation tests catch structural breakage, not just row-count drift.

-- 1) Count parity by object
SELECT 'companies' AS object_name, COUNT(*) AS source_count FROM src_companies
UNION ALL
SELECT 'companies_loaded', COUNT(*) FROM tgt_companies;
 
-- 2) Orphaned deals/opportunities
SELECT d.legacy_id
FROM staged_deals d
LEFT JOIN tgt_companies c
  ON d.target_company_key = c.external_key
WHERE d.target_company_key IS NOT NULL
  AND c.external_key IS NULL;
 
-- 3) Invalid pipeline-stage mappings
SELECT legacy_deal_id, target_pipeline, target_stage
FROM staged_deals
WHERE (target_pipeline, target_stage) NOT IN (
  SELECT pipeline_id, stage_id FROM allowed_pipeline_stages
);

Write scripts to verify:

• Every Contact has a valid parent Account/Company
• Every Deal is linked to at least one Contact and one Account
• Activity counts per record match source-to-target
• Pipeline stage values mapped correctly (no "null" or "unmapped" stages)
• Owner/assignee fields resolved to valid users in the target
• Revenue totals by month match between systems
• Currency codes on deal records match the source (no silent conversion to default currency)

-- Salesforce SOQL: find orphaned Contacts created during migration
SELECT Id, FirstName, LastName
FROM Contact
WHERE AccountId = null
AND CreatedDate >= 2026-01-01T00:00:00Z

-- General post-migration QA checks
SELECT stage, COUNT(*) FROM opportunities GROUP BY stage;
SELECT owner_id, COUNT(*) FROM contacts GROUP BY owner_id;
SELECT DATE_TRUNC('month', close_date) AS month, SUM(amount) FROM opportunities GROUP BY 1;
SELECT COUNT(*) FROM activities WHERE parent_record_id IS NULL;
SELECT currency_code, COUNT(*) FROM deals GROUP BY currency_code;

If any check fails, fix the mapping and rerun. Do not proceed to production with known relationship errors.

8. Execute the Baseline Load with Activities, Attachments, and Compliance Data

Load the historical data into production following the hierarchical load order validated in your sandbox. This includes the core objects — Accounts, Contacts, Deals — but also the data types that teams most commonly drop: activities, attachments, and compliance records.

Attachments are expensive to migrate. They're stored as binary blobs, often behind separate API endpoints, and each file requires its own download-upload cycle. Salesforce stores them as ContentDocument/ContentVersion objects; HubSpot uses the Engagements API. Budget separately for attachment throughput.

Activity history (calls, emails, meetings, notes) must be linked to the correct parent record with accurate timestamps. If you fail to explicitly preserve the CreatedDate, every historical email looks like it was sent on the day of the migration. The deal timeline becomes useless.

Compliance records are not optional. If you operate under GDPR, CCPA, or CAN-SPAM, consent data must transfer intact:

• Opt-in/opt-out timestamps with timezone information
• Lawful basis for processing (consent, legitimate interest, contractual necessity)
• Communication channel preferences (email, phone, SMS)
• Consent withdrawal records

GDPR requires you to prove consent was obtained — the original timestamp and context must survive the migration. Dropping a consent field doesn't just create a data gap; it creates a compliance violation. HubSpot has built-in GDPR consent fields and supports setting a legal basis during import. Salesforce requires custom fields or a consent management package. (knowledge.hubspot.com)

9. Run the Final Delta Sync

You cannot tell your sales team to stop working for two weeks while you move data. A delta sync captures every record created, updated, or deleted after your initial export.

The delta process must be idempotent — rerunning the same batch should update the same records, not create new ones. This requires:

• Querying source records modified since the last export timestamp
• Matching them to existing target records via your legacy IDs (upsert logic)
• Handling conflicts with defined rules (which version wins?)

This is where tools like Zapier and Make fail completely. They're designed for event-based, one-record-at-a-time workflows — not bulk reconciliation.

Once the systems are aligned, schedule the final delta for the go-live Monday, before the working day starts: freeze the legacy system (set it to read-only) and execute the final delta sync to capture the last days of active sales work. Because it moves only what changed since the previous sync, it typically takes about 30 minutes.

10. Go Live with QA and Staged Cutover

Post-migration validation is not "check a few records manually." It's a systematic comparison:

• Record counts: Total Accounts, Contacts, Deals, Activities per object type (source vs. target)
• Relationship integrity: Spot-check 100+ records across object types — verify parent-child links
• Field-level accuracy: Compare 50+ records field-by-field, including custom fields
• Pipeline accuracy: Compare total pipeline value and stage distribution
• Attachment accessibility: Open 20+ random attachments — confirm they render correctly
• Report parity: Run your top 5 revenue reports in both systems — results should match
• Consent parity: Verify unsubscribe flags, legal basis, and suppression lists match the source
• Automation health: Trigger key workflows and verify they fire correctly on migrated data

Only after all checks pass should you cut over users. Route integrations, webhooks, and lead-capture forms to the new CRM. Re-enable automations in stages — not all at once. Maintain read-only access to the source CRM for 30–60 days as a safety net.

Big bang, phased, or parallel cutover?

A cutover strategy determines how you transition users from the old CRM to the new one:

• Big bang moves everything in one window. It works for smaller, cleaner datasets where a short freeze is acceptable.
• Phased migration moves data by object type, business unit, or region over multiple windows. Slower, but it lets you learn and adjust between phases.
• Parallel run keeps both systems live for a validation window. The source system remains fully operational for a defined parallel-run period, typically 2–4 weeks.

Phased rollouts reduce risk because each wave is smaller and lessons carry forward. That said, big bang is valid when your dataset is small, your integration count is low, and your team can absorb a short freeze. For the parallel-run approach in depth, see why running two CRMs in parallel beats a hard cutover.

When should you NOT schedule a CRM migration?

Timing kills more migrations than technology does.

• Never go live during quarter-end. Sales teams close a disproportionate share of quarterly revenue in the last weeks of the quarter. A cutover during that window risks pipeline visibility, deal attribution, and your relationship with the sales org.
• Never go live during peak season. The golden rule of timing is to never schedule a go-live for peak business periods (Black Friday, high season, quarter close).
• Never go live without a tested rollback plan. If you cannot describe how to reverse the migration, you are not ready to start it.

The best time to go live is a Monday early in a new quarter. Run the bulk historical load in the days before, while reps keep working in the old CRM. Then, before the working day starts on Monday, freeze the legacy system and run the final delta migration. Because it only moves records created or changed since the last sync, it typically takes about 30 minutes, so reps log in on Monday morning to the new CRM with nothing missing. Keep the hypercare team on standby through that first week.

For a deeper dive on activity and attachment migration for Salesforce-to-HubSpot specifically, read Salesforce to HubSpot Migration: Pipeline, Tickets & Attachments.

What Are the Best CRM Data Migration Services in 2026?

The best CRM data migration service in 2026 depends on your data complexity, not on a vendor ranking. Not every migration needs the same approach. Here's an honest comparison:

The decision framework is straightforward: if your CRM has custom objects, more than 50,000 records, multi-object associations that must be preserved, or compliance data that can't be dropped, a managed approach pays for itself in avoided rework.

For a detailed comparison of tools, see Top 5 Best CRM Migration Solutions.

Why Do CRM Migrations Fail?

The data usually gets there. The people don't.

Many CRM implementations fall short of their stated objectives, and technical failure is rarely the main cause. Most fall short because of adoption.

The recurring root causes are poor user adoption, bad data quality, and insufficient training. Clean data migration is consistently named as a success factor — yet it is the phase most often compressed.

Training should start 4–6 weeks before go-live, not after. A few hours of onboarding is not proficiency; reps need sustained, supported usage before the new CRM feels faster than the old one. Plan accordingly.

What Zero-Loss Actually Means

A zero-loss CRM migration doesn't mean the import finished without errors. It means the new CRM produces the same operational truth as the old one: the same pipeline, the same relationships, the same owner accountability, the same history, and the same consent posture.

A CRM migration is a revenue infrastructure project. It touches pipeline data, sales forecasting, attribution, and the trust your reps have in the system. A failed migration doesn't just create data cleanup work — it disrupts revenue operations at the worst possible time.

The 10-point plan above is the sequence we execute on every engagement at ClonePartner — adapted to the specific source, target, and data complexity of each client's environment. We handle the hierarchical load ordering, the API rate-limit management with automatic backoff and batching, the delta syncs that let your team keep selling during the migration, and the post-migration validation that proves every record landed where it should.

If you're planning a CRM migration and want to avoid broken pipelines, lost deal history, or a compliance gap, we should talk.