Data migration is the part of a CRM implementation that derails more projects than any other. Teams spend weeks evaluating and selecting a CRM, then rush the migration in the final days before launch—and end up with duplicate records, missing history, broken relationship links, and a database that takes months to clean up. None of that is inevitable if you treat migration as a project in its own right rather than an afterthought.

This guide walks you through every stage of a CRM data migration: auditing your data before you move it, mapping fields from your old system to your new one, cleaning duplicates, running a test migration, verifying the results, and avoiding the most common failure modes.

Why CRM Data Migration Is Harder Than It Looks

The technical act of exporting a CSV from one system and importing it into another is straightforward. What makes migration genuinely hard is everything that happens around that act:

• Your existing data is messy. Contacts have missing fields, outdated email addresses, duplicate records created by different reps over the years, and company names entered inconsistently.
• Your old CRM’s data structure does not match your new CRM’s data structure. Fields that existed in your old system may not exist in the new one. Relationship types may be modeled differently.
• Some data does not migrate cleanly. Activity history (call logs, email threads, meeting notes) is often the hardest thing to move because it is structured differently across platforms.
• Migration errors are not always visible immediately. A contact migrated with the wrong company association will not cause an obvious error in the system—it will just silently produce bad data that someone discovers months later.

The solution is a structured migration process that treats data quality as a prerequisite, not a cleanup task.

Step 1: Conduct a Data Audit Before Migration

Before you touch the new CRM, you need to know exactly what is in your old system. A data audit answers four questions:

What data do we have? List every object type you will migrate—contacts, companies/accounts, deals/opportunities, activities, notes, and any custom objects—and how many records of each type exist.

What is the quality of the data? For each object type, assess completeness (what percentage of records have the key fields populated), accuracy (how many records have obviously wrong or outdated data), and consistency (are field values formatted consistently—phone numbers, countries, company names).

What do we actually need? Not all data is worth migrating. Contacts who have not been touched in five years, deals closed before your current product existed, or activities from a sales process you no longer use may not be worth the effort to clean and migrate. Define a cutoff rule—for example, “we will migrate all contacts with activity in the last two years” or “we will migrate all open deals and deals closed in the last eighteen months.”

What relationships matter? In most CRMs, relationships between objects—a contact linked to a company, a deal linked to a contact, activities linked to a deal—are as important as the records themselves. Map out which relationships need to be preserved in the migration. If a deal is migrated but its associated contacts are not linked correctly, the deal history is effectively orphaned.

Create a data audit document that captures all of this before you begin any migration work. This document is the foundation for everything that follows.

Step 2: Clean the Data Before You Migrate

The single most effective thing you can do to improve your migration outcome is clean your data before you migrate, not after. Migrating dirty data into a new system just moves the problem. Cleaning it in the export stage—where you have context from your old system—is easier than cleaning it after migration.

Deduplicate Contacts and Accounts

Duplicate records are almost universal in CRM databases. A contact created twice by two different reps, a company listed under three slightly different name formats, a lead that was imported and also manually created. Run a deduplication pass before migration.

Most CRMs and spreadsheet tools have deduplication features. At minimum, identify duplicates based on email address (for contacts) and company name/domain (for accounts). Merge or delete duplicates before building your migration file.

Standardize Field Values

Inconsistent values in dropdown or list fields cause problems after migration. If your “Country” field has values like “US”, “USA”, “United States”, and “United States of America”, you need to standardize to one format before migrating—because your new CRM’s country field likely expects one specific format.

The same applies to phone number formats, deal stage names, contact status values, and industry classifications.

Fill or Flag Critical Missing Fields

For records missing critical fields—contacts with no email address, deals with no close date, accounts with no primary contact—decide before migration whether to fill those fields, flag the records for review, or exclude them from migration entirely. Missing required fields will cause import errors in the new CRM.

Step 3: Map Your Fields

Field mapping is the process of matching each field in your old CRM to the corresponding field in your new CRM. This is meticulous work, but it is essential.

Build a field mapping document that lists every field in your export and specifies:

• The source field name (in the old CRM)
• The destination field name (in the new CRM)
• The data type (text, number, date, dropdown, boolean)
• Any transformation needed (for example, converting a date format)
• Whether the field needs to be created in the new CRM (as a custom field)

Here is an example of how a field mapping document might look:

Source Field (Old CRM)	Destination Field (New CRM)	Data Type	Transformation Needed
First Name	First Name	Text	None
Last Name	Last Name	Text	None
Email	Email	Email	None
Phone	Phone (Mobile)	Phone	Strip country code prefix
Company	Account Name	Text	None
Lead Status	Contact Status	Dropdown	Map old values to new values
Created Date	Created Date	Date	Convert to ISO 8601 format
Custom: AE Owner	Deal Owner	Lookup	Map rep names to user IDs
Custom: Industry	Industry (custom field)	Dropdown	Must create field in new CRM first

Work through this document for every object type you are migrating. Pay special attention to lookup fields—fields that reference another record (like “Account Name” on a contact record, which links to the account record). These relationships need to be maintained in the migration, which usually requires importing accounts before contacts and contacts before deals.

Step 4: Run a Test Migration

Before importing your full dataset, run a test migration with a subset of records—typically one hundred to five hundred records per object type, selected to represent the range of your data (including records with unusual field values or complex relationship structures).

What to Check in the Test Migration

• Record count: Did the expected number of records import?
• Field values: Are the field values populated correctly, with no truncation, encoding issues, or formatting problems?
• Relationship integrity: Are contacts linked to the correct accounts? Are deals linked to the correct contacts?
• Activity history: If you are migrating activities, do they appear correctly on the associated records?
• Custom fields: Do custom field values appear in the right fields?
• Duplicates created: Did the import create any unexpected duplicates?

Document every issue you find in the test migration and resolve it before running the full migration.

Step 5: Run the Full Migration and Verify

Once the test migration is clean, run the full migration. Most CRM import tools will provide an error log—review it immediately after import and investigate every error.

After the full import, run a verification pass:

Record count verification: Compare the number of records in your export file to the number of records imported. If the counts do not match, investigate why.

Spot-check key records: Select a sample of twenty to thirty important records and verify each one manually. Check field values, relationship links, and activity history. Focus on records that represent different segments of your data—large deals, long-standing clients, records with unusual field combinations.

Run your key reports: Before launch, run the reports your team will use most—pipeline by stage, contacts by status, activities by rep. If the numbers look wrong, that is a signal to investigate the underlying data before users start working in the system.

Check for duplicates: Run a deduplication check in the new CRM after import. Even with pre-migration deduplication, some duplicates may be created if your import runs in batches or if matching logic differs between systems.

What Commonly Goes Wrong (And How to Prevent It)

Migrating Activity History Incompletely

Call logs, email threads, and meeting notes are often the hardest data to migrate. Many CRM export formats handle activity history poorly—call notes may be exported as plain text without context, email threads may not migrate at all, or activities may lose their associations with specific deals.

Prevention: Understand exactly what your current CRM can export about activities before assuming all of it will survive migration. For critical history that cannot migrate cleanly, consider exporting it to a document or notes file that lives in the new CRM, even if it is not in the native activity log format.

Losing Account-Contact Relationships

If you import contacts before accounts, or import them in a way that does not preserve the account association, contacts become orphaned—present in the system but not linked to any company. This is a common error that is tedious to fix manually.

Prevention: Import in the correct order—accounts first, then contacts with account associations, then deals with contact associations.

Custom Field Data Going to the Wrong Fields

If your custom field mapping is incorrect, data ends up in the wrong field in the new CRM. This is often not visible immediately—the record looks populated, but on closer inspection the values are wrong.

Prevention: Verify custom field mapping carefully in the test migration. Check the actual content of custom fields on a sample of records before signing off on the test.

Not Flagging the Migration Cutoff Date

If you continue using the old CRM during migration, new records created in the old system will not be in the new one unless you run a delta migration (migrating only new or changed records since the initial export). Failing to account for this creates a gap.

Prevention: Set a clear migration cutoff date. After that date, all new records go into the new CRM only. Brief your team clearly on the cutoff so no one creates new records in the old system expecting them to appear in the new one.

Frequently Asked Questions

How long does a CRM data migration typically take? For a small team with clean data, a migration can be completed in one to two weeks. For a larger organization with messy data, complex field mapping, and multiple object types, four to eight weeks is more realistic. Enterprise migrations with custom integrations, complex relationship structures, and strict data governance requirements can take longer. The data audit and cleanup phase is usually the longest part.

Do we need a consultant to handle our CRM data migration? Smaller teams with straightforward data and a modern CRM that has good import tooling can often handle migration internally. Larger organizations or those migrating from a heavily customized legacy CRM often benefit from bringing in someone experienced with data migration, either a CRM implementation partner or an independent consultant. The cost of a migration consultant is often less than the cost of fixing a failed migration after go-live.

What should we do with old data we do not migrate? Keep your old CRM accessible (even read-only) for at least six months after migration. You will occasionally need to look up historical information that did not make it into the new system. After six months, if you have not needed to reference it, consider archiving the data to a secure backup rather than maintaining a live CRM subscription.

Can we migrate data from a spreadsheet instead of a CRM? Yes. Many teams switching to their first CRM are migrating from a spreadsheet rather than an existing CRM. The process is similar: audit the spreadsheet data, clean and standardize it, map columns to CRM fields, and run a test import. Spreadsheet data is often easier to work with than a CRM export because it is already in a flat format, but the same cleanup steps—deduplication, standardization, relationship mapping—apply.