---
title: "The Ultimate CRM Data Migration Checklist: A 10-Point Plan for a Zero-Loss Transition"
slug: the-ultimate-crm-data-migration-checklist-a-10-point-plan-for-a-zero-loss-transition
date: 2026-05-05
author: Raaj
categories: [CRM, Checklist]
excerpt: "A 10-point CRM data migration checklist covering API rate limits, relational data integrity, compliance, and the exact load order to prevent orphaned records."
tldr: "CRM data migration fails when you treat it as a CSV upload. Follow this 10-point execution plan — in order — to protect pipeline data, consent records, and deal history."
canonical: https://clonepartner.com/blog/the-ultimate-crm-data-migration-checklist-a-10-point-plan-for-a-zero-loss-transition/
---

# 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](https://clonepartner.com/blog/blog/pipedrive-to-hubspot-migration-data-mapping-apis-rate-limits/) or [Salesforce to HubSpot Migration: Pipeline, Tickets & Attachments](https://clonepartner.com/blog/blog/salesforce-to-hubspot-migration-pipeline-tickets-attachments/).

## 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

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**: Most organizations discover 10–30% duplicate records once they run a proper deduplication process. If your rate exceeds 10%, your data quality is actively 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.

> [!WARNING]
> Clean before you migrate, not after. Post-migration cleanup costs 3–10x more because you've lost context from the source system and introduced transfer errors. Use the migration as a forcing function to purge dead leads, deprecate unused custom fields, and merge duplicate accounts.

For guidance on using AI to assist with data cleanup and field mapping, see [Using Generative AI in SaaS Data Migration](https://clonepartner.com/blog/blog/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](https://clonepartner.com/blog/blog/why-ai-migration-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](https://knowledge.hubspot.com/object-settings/create-custom-objects?_hsmi=251993839&utm_source=openai))
- **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](https://developer.salesforce.com/blogs/engineering/2012/02/cascade-insert-with-external-id-fields?utm_source=openai))

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](https://knowledge.hubspot.com/import-and-export/import-objects))

For a reusable template approach, see [How to Create a Data Migration Checklist](https://clonepartner.com/blog/blog/data-migration-checklist-template/).

> [!TIP]
> Create a stable source key on every target object before migration day. If a retry runs twice, that key turns a duplicate-risk event into a safe upsert.

## 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

| Platform | Daily API Limit | Burst / Concurrency Limit | Bulk Capability |
|---|---|---|---|
| **Salesforce** | 100,000 + per-license allocations (rolling 24h) | 25 concurrent requests running 20s+ | Bulk API 2.0: 15,000 batches/day; up to 150M records/24h for ingest |
| **HubSpot** | 625K (Pro) / 1M (Enterprise) | 190 requests per 10 seconds (private apps) | Batch endpoints: 100 records/request; Import: 10M rows/day |
| **Pipedrive** | Token-based: 30,000 base × plan multiplier × seats | Burst on 2-second rolling window (20–120 req/2s by plan) | No native bulk API |
| **Zoho CRM** | Credit-based: ~50,000 base + 250/user (Standard) | 15–25 concurrent requests (edition-dependent) | 100 records per insert/update call |
| **Dynamics 365** | 40,000/user/day (D365 Sales Enterprise) | Service protection limits (per-user) | 1,000-operation batch caps |

([resources.docs.salesforce.com](https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/salesforce_app_limits_cheatsheet.pdf)) ([developers.hubspot.com](https://developers.hubspot.com/docs/api/usage-details?utm_source=openai)) ([pipedrive.readme.io](https://pipedrive.readme.io/docs/core-api-concepts-rate-limiting))

> [!NOTE]
> **Pipedrive's rate limiting has changed.** The legacy 10,000 POST/PUT daily cap per user is being replaced by a token-based system. Each API endpoint now has a token cost based on complexity, and the daily budget is calculated as 30,000 base tokens × plan multiplier × seat count. Pipedrive still exposes `x-daily-requests-left` for POST/PUT tracking, and its documented fair-usage limit for POST/PUT traffic remains 10,000 requests per user per 24 hours. Use API v2 endpoints where possible — they consume fewer tokens than v1.

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](https://developers.hubspot.com/docs/api/usage-details?utm_source=openai)) 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.

### 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](https://resources.docs.salesforce.com/latest/latest/en-us/sfdc/pdf/salesforce_app_limits_cheatsheet.pdf))
- **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.

> [!CAUTION]
> Never run a bulk migration script without exponential backoff and retry logic. If the target API throttles your connection and your script drops the payload, you create gaps in historical data that are nearly impossible to identify and patch later.

## 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](https://help.salesforce.com/s/articleView?id=xcloud.availability_back_up_data_for_recovery.htm&language=en_US&type=5&utm_source=openai))
- **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.

### 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](https://developer.salesforce.com/blogs/engineering/2012/02/cascade-insert-with-external-id-fields?utm_source=openai)) 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

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](https://developers.hubspot.com/docs/api-reference/latest/crm/associations/associate-records/guide?utm_source=openai))

```text
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

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. 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

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

```sql
-- General post-migration QA checks
SELECT COUNT(*) FROM deals WHERE primary_company_id IS NULL;
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;
```

> [!WARNING]
> A row-count match does **not** prove success. If associations, owners, stage values, or consent flags drift, the new CRM can look full and still be operationally broken.

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](https://knowledge.hubspot.com/import-and-export/import-objects))

> [!TIP]
> Prioritize migrating the last 24 months of activity history. Older data can be archived. Sales reps rarely reference activities from 5+ years ago, and migrating them significantly increases both migration time and API consumption.

### 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, freeze the legacy system (set it to read-only) and execute the final delta sync to capture the last days of active sales work.

### 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.

For a deeper dive on activity and attachment migration for Salesforce-to-HubSpot specifically, read [Salesforce to HubSpot Migration: Pipeline, Tickets & Attachments](https://clonepartner.com/blog/blog/salesforce-to-hubspot-migration-pipeline-tickets-attachments/).

## DIY vs. Automated Tools vs. Managed Migration Services

Not every migration needs the same approach. Here's an honest comparison:

| Approach | Best For | Breaks At |
|---|---|---|
| **Salesforce Data Loader / CSV Import** | <5,000 records, flat data, no custom objects. Data Import Wizard tops out at 50,000 records; Data Loader handles up to 5M with Bulk API. ([help.salesforce.com](https://help.salesforce.com/s/articleView?id=sf.data_import_wizard.htm&language=en_US&type=5&utm_source=openai)) | Relational data. Requires manual VLOOKUP chains to link Contacts to Accounts via newly generated IDs — that's where orphaned records are born at scale. |
| **Zapier / Make** | Ongoing syncs, <1,000 records. | Bulk historical loads. Single-record processing hits API limits fast. Zapier counts each successful action as a task; Make fan-out means one trigger returning 10 records can produce 30+ operations across downstream steps. Wrong shape for a six-year activity backfill. ([help.zapier.com](https://help.zapier.com/hc/en-us/articles/8496196837261-How-is-task-usage-measured-in-Zapier?utm_source=openai)) |
| **Self-service tools (Import2, Trujay)** | Standard objects, simple schemas. Import2 auto-maps standard fields and supports 80+ app pairs. | Highly customized architectures, nested custom objects, large attachment volumes. Import2 does not migrate configuration (users, reports, lists, templates, automations). Often require paid upgrades when the automated script fails. ([partners.import2.com](https://partners.import2.com/?utm_source=openai)) |
| **Engineer-led migration service** | Complex schemas, high-volume, compliance-sensitive data, zero-downtime requirements. | Cost ceiling. Overkill for a 500-contact CRM with no custom objects. |

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](https://clonepartner.com/blog/blog/top-5-best-crm-migration-solutions/).

## 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.

> If your CRM migration includes custom objects, messy relationship graphs, or a cutover window your sales team cannot miss, our engineers will help you plan and execute it without data loss or downtime.
>
> [Talk to us](https://cal.com/clonepartner/meet?duration=30)

## Frequently asked questions

### What is the correct order to migrate CRM data?

Load records in strict hierarchical order: Users/Owners first, then Accounts/Companies, then Contacts, then Deals/Opportunities, then Activities and Notes, then Attachments, and finally Custom Objects. Each step depends on capturing new target-system IDs from the previous step to maintain relational integrity.

### How do API rate limits affect CRM data migration?

API rate limits determine how fast your migration runs and whether scripts fail silently. Salesforce caps Bulk API at 15,000 batches per 24 hours. HubSpot limits burst requests to 190 per 10 seconds on Pro/Enterprise private apps, with the Associations API stricter at 150 per 10 seconds. Pipedrive uses a token-based daily budget. Migration scripts need exponential backoff and batching logic to stay within these limits.

### How do I avoid duplicate contacts during a CRM migration?

Deduplicate before migration, not after. Store source-system IDs as immutable legacy keys on every target object to enable safe upserts. Never dedupe on names alone. Most CRM databases contain 10–30% duplicate records. Cleaning after migration costs 3–10x more because duplicates have already triggered automations and inflated reports.

### Do I need to migrate GDPR consent records when switching CRMs?

Yes. GDPR requires you to demonstrate that valid consent was obtained, including timestamps, the lawful basis for processing, and withdrawal records. Dropping these fields during migration creates a compliance violation. Verify that consent field granularity matches between source and target CRM.

### How long does a CRM data migration take?

It depends on data volume, complexity, and cleanliness. A well-prepared migration of 50,000–200,000 records across standard and custom objects typically takes 3–10 days of execution time, with 2–4 weeks of pre-migration data auditing, mapping, and testing. Poor data quality is the primary cause of timeline overruns.