The record counts matched. Every object exported clean, imported clean, and the totals reconciled row for row. Three weeks later, a rep opened a six-figure opportunity and found it stripped bare: no call log, no email thread, no meeting notes. A CRM data migration can pass every count check and still hollow out the context your pipeline runs on, because the numbers that reconcile are rarely the numbers that break.
This is a playbook for the person who owns that risk. It does not tell you which CRM to buy. It tells you, by data type, exactly what breaks during a move and how to stop it before the first record leaves the source system. The stakes are real: a 2025 Validity survey of 602 CRM users found 37% had lost revenue directly from poor CRM data quality, and 76% said less than half of their data was accurate and complete before anyone touched a migration. Moving that data without a plan does not clean it. It launders the mess into a new system where it is harder to trace.
What a clean migration actually protects
Three things the counts never see: correct field values, intact relationships between records, and the full activity history behind every deal. Most failures cluster into three modes.
Field mapping mismatches corrupt values silently. A source picklist value with no destination equivalent does not throw an error; the record drops or the field lands blank.
Relationship and association breaks orphan records from each other. A contact arrives and its deal arrives, but the link between them does not, so the rep sees a name with no pipeline attached.
Activity history truncation quietly shortens the record. Calls, emails, and meetings get flattened, capped by date, or dropped, and nobody notices until someone needs the history.
Hold that trio in mind. Every step below exists to defuse one of them.
Why dirty data costs more to move than to clean
Every duplicate you carry across doubles in the new system the moment two integrations re-sync it. Every unmapped picklist value becomes a reconciliation ticket. Email lists decay on their own: ZeroBounce 2026 data puts the rate at least 23% a year, so roughly one in four addresses goes invalid within twelve months even without a migration. Move without pruning and you pay to import records that were already dead.
Prerequisites to finish before you export a record
Three artifacts have to exist before export. Skip them and you are improvising during cutover, which is the worst possible time.
Build a full field inventory from the source
Document every field in the source CRM: name, data type, and population rate. The population rate is the one people skip and the one that saves them. Fields populated in under 5% of records are archival candidates, not migration cargo; dragging a mostly empty required field into the destination schema just propagates a hole.
Deduplicate with survivorship rules, not a blunt merge
Run deduplication in three passes: exact email match first, fuzzy name-plus-domain second, phone normalization third. Before merging anything, write survivorship rules that decide which record wins each field and how the losing record's history folds in. Merge without those rules and you lose the very context that made the duplicate worth keeping: the older notes, the first-touch date, the early-stage activity the winning record never had.
Map every field, and normalize every picklist value
A field mapping document lists source field, destination field, and the transformation each pair needs. Direct fields copy across. Picklists almost never do. Here is the pattern that trips teams:
Source: Lead Status | Destination: Contact Stage |
|---|---|
Hot | Qualified |
Warm | Nurturing |
Cold | Unqualified |
Every source value needs an explicit destination target. Leave "Cold" unmapped and the destination does not warn you: it drops the value, and often the record, without an error. That gap is the difference that defines the whole project.
Step 1: Audit and clean the source data
"Clean" needs a definition you can test, not a reassurance. For migration purposes, clean means: no duplicate email addresses, every required destination field populated, every picklist value mapped one-to-one, phone numbers in E.164 format, and no sub-5%-populated field riding along unless the destination requires it.
Which records to migrate and which to archive
Not everything earns a seat. Records tied to closed-lost deals older than your reporting window, contacts with no activity in years, and accounts that never converted are archive candidates. Export them to cold storage so they exist if you need them, but keep them out of the live import. A smaller, cleaner set imports faster and reconciles more honestly.
Duplicates attached to open deals
The dangerous duplicates are the ones with open pipeline. Merging two contact records that each own an active deal can reassign or sever the deal association. Resolve these by hand: pick the surviving contact, reattach both deals to it, and confirm the association before the record enters the export.
Step 2: Export in the format the destination needs
CSV export works for straightforward moves; an API-based migration preserves associations and field types a flat file cannot carry. The choice hinges on relationship complexity, not just volume.
CSV versus API export
CSV is fine for a single object with few associations. It falls apart on relationship-heavy data, because a flat file has no native way to express that this activity belongs to that deal, which belongs to that contact. API-based tools carry those references. Two CSV traps to check before you trust the file: character encoding and leading zeros. UTF-8 opened as Windows-1251 garbles diacritics and special characters in name fields, and Excel and Google Sheets strip leading zeros from phone numbers and record IDs by default, corrupting the exact keys you deduplicate on.
What silently gets left behind
Exports drop what the format cannot hold. File attachments over the destination's per-file size limit, activity types the destination cannot represent, and custom-object links with no matching field all vanish without a flag. Inventory these before export so you know what you are choosing to lose.
Step 3: Run a test migration on 5 to 10% of records
Never commit the full database first. Move 5 to 10% of records as a test, and design the sample instead of grabbing the first thousand rows.
Choosing a representative sample
The sample must include at least one instance of every custom object type, plus deliberate edge cases: a record with a blank required field, the longest text value you can find, a file attachment, and a record owned by a deactivated user. Edge cases are where mapping gaps surface. A random slice of typical contacts tells you nothing.
Silent drops are why reconciliation is mandatory
Some failures shout and some whisper. A file over the upload limit throws a visible error. A blank required field or an unmapped picklist value produces a silent skip: no error, no flag, just a missing record. Loud errors get fixed because you see them. Silent drops surface only through active reconciliation, which is why the go/no-go check counts records rather than trusting the import summary. The test passes when counts match within 1% per object type, custom fields are populated across a 20-record spot-check, you verify ten deal-to-contact associations by hand, and one workflow re-triggers successfully.
Step 4: Migrate in dependency order and freeze the source
Parent records first, always
Migrate in dependency order because associations reference parent IDs. Companies go before contacts, since a contact record points to a company ID. Contacts go before deals, since a deal points to a contact. Deals go before activities and notes, since an activity points to a deal. Load a child before its parent exists and the association link references nothing, so it breaks silently and the record lands orphaned.
Pause integrations before you freeze, not after
Setting the source CRM to read-only is not enough. Marketing automation, enrichment tools, and workflow integrations keep writing to the source during the freeze window. Every record they create or update after the snapshot was taken lands nowhere: absent from the destination, invisible to count reconciliation, because it never existed at export time. This is integration creep, a cutover failure mode that read-only mode alone cannot prevent. Pause every inbound integration before the freeze window opens. Read-only stops your reps. It does not stop the machines.
Step 5: Validate and reconcile after cutover
Post-migration reconciliation is where the project proves out, and it is not a glance at the dashboard. Count records by object type and compare with the source, one object at a time; a global total can hide a shortfall in one object behind a surplus in another.
Go deeper from there. Spot-check 50 random contacts field by field against the source. Verify custom field values are actually populated rather than arriving blank. Confirm activity history is attached to the correct parent records. Re-trigger one active workflow and watch it fire end to end, because a workflow that migrated as a definition but lost its trigger condition looks fine until it silently stops running your automation.
Migration risk by data type: a two-axis matrix
Most guides rank migration risk on a single axis and leave you to guess where to spend remediation hours. Kudos CRM built the matrix below from public migration documentation and reported failure patterns, rating each data type on two axes: how likely it is to break, and how hard it is to recover once it does.
Data type | Loss probability | Recovery difficulty |
|---|---|---|
Contacts | Medium | Low |
Companies | Medium | Low |
Deals | High | High |
High | Medium | |
High | High | |
High | Medium | |
File attachments | Medium | High |
Read the top-right corner first. Deals and activity history sit at high probability and high recovery difficulty, making them your priority: likely to break, painful to rebuild, and directly tied to revenue. Contacts and companies break often but rebuild easily, so they deserve less anxiety than their volume suggests. File attachments rarely fail wholesale, but when they do there is often no clean way to recover the originals, so verify them before you decommission the source.
Contacts and companies: ownership gaps and deduplication failures in the destination
The contact failures that are hardest to catch are not missing records but misassigned ones. When a rep leaves and their user account is deactivated before migration, every record they owned can land in the destination without an owner or reassigned to a default user, which breaks round-robin routing and territory logic built on ownership. Audit deactivated users in the source before export and reassign their records deliberately. Deduplication failures compound this: contacts that looked distinct in the source (one email, one phone number) can resolve to the same person once the destination applies its own matching rules, merging records you intended to keep separate. Run a post-migration dedup scan in the destination before reps start writing data.
Deals and pipeline: value-mapping mismatches
Deals break at stage and value mapping. A pipeline stage with no destination equivalent strands the deal in a default stage, distorting every forecast built on it. Map stages explicitly, the same way you mapped picklists, and reconcile deal values by stage after load.
Activity history: the three truncation mechanisms
"Activities may be lost" appears on every migration guide. The mechanisms rarely do, so here they are. API-based tools apply a date cap that silently drops history older than a cutoff, often defaulting to 12 to 24 months. Attachments over the destination's per-file limit are skipped without an error. Native activity types (call, email, meeting) get flattened into plain-text notes when the tool has no destination-side activity-type mapping. Activity records are the richest and most fragile part of a CRM dataset. Check the date cap setting, the attachment limit, and the activity-type mapping before you run, not after.
Tools, manual CSV, or managed service: what fits your volume
Pick the method by record volume and complexity, not by price. Under 5,000 clean records with simple associations, a native CSV import handles the job; Pipedrive's spreadsheet import, for instance, accepts up to 50,000 rows and 50 MB and lets you revert within 48 hours if validation surfaces problems. Between 5,000 and 50,000 records, a dedicated migration tool such as Trujay or Data2CRM preserves associations and activity types that CSV cannot, and tools like Import2 handle up to 100,000 records on a free tier for some destinations. Above 50,000 records, or with complex custom objects and heavy activity history, a managed migration service reduces both risk and total hours: the mapping and reconciliation work that eats a solo ops manager's month is what a managed team runs on rails.