CRM Data Migration Checklist: 10 Steps for a Clean, Risk-Free Move

1. Audit Your Source Data

Before anything else, understand what you are working with. Run a full profile of the source system: count total records per object type, identify blank mandatory fields, quantify duplicates, and flag records with conflicting values. This step regularly surfaces surprises - data volumes that are double the estimate, or fields that have not been populated for years.

Document your findings in a data quality report and share it with the project sponsor before any migration planning begins. Surprises discovered during a pilot migration are manageable; surprises discovered on go-live day are not.

2. Define Migration Scope

Not everything in your old system needs to come across. Define clear rules for what migrates and what does not:

• Which object types are in scope (Accounts, Contacts, Opportunities, Cases, Activities, etc.)
• Date range filters - e.g., only records created or modified in the past 3 years
• Status filters - e.g., only active accounts, open or closed-won opportunities
• What happens to records that fall outside scope - archive, delete, or migrate to a separate archive object

Scope decisions should be made by business owners, not the migration team. A named business stakeholder must sign off on these rules in writing before migration begins.

3. Map Fields Between Systems

Produce a field mapping document that covers every object in scope. For each field in the source system, specify the target field in the destination CRM, the data type transformation required (e.g., a text field becoming a picklist), and any default values to apply where the source is blank.

Pay particular attention to relationship fields - foreign keys between objects (e.g., an Opportunity's Account ID) must be re-established correctly in the target system. A broken parent-child relationship is one of the most common post-migration complaints.

4. Set Deduplication Rules

Define how duplicates are identified and resolved before you touch the data. Common matching criteria include email address, phone number, company name, or a combination. For each match scenario, specify:

• Which record is the "master" and which is the duplicate
• How conflicting field values are resolved (most recent, most complete, or manual review)
• What happens to activity history attached to merged records

Deduplication decisions are business decisions. Do not let the migration team make them unilaterally.

5. Cleanse the Source Data

Apply your deduplication rules, correct known data errors, standardise formats (phone numbers, country codes, postal addresses), and fill mandatory fields where possible before extraction. The cleaner the source data, the fewer issues you will encounter during the pilot migration.

Do not migrate dirty data with the intention of cleaning it in the new system. It rarely happens. Users arrive on day one, see inconsistent data, and lose confidence in the platform immediately.

6. Build Your ETL Process

Extract, Transform, Load. Your ETL process should be repeatable and scripted - not a series of manual exports and imports. For Salesforce migrations, tools such as Salesforce Data Loader, Data Import Wizard (for smaller volumes), or purpose-built tools like Jitterbit and Informatica Cloud are common choices.

Build idempotency into your process: if you run the migration twice, you should not end up with duplicate records. Use upsert operations keyed on a unique external ID wherever possible.

7. Run a Pilot Migration in Sandbox

Migrate a representative sample - typically 10-20% of total volume, covering all object types - into a full copy sandbox of the target system. The pilot surfaces issues with field mappings, relationship integrity, validation rule conflicts, and trigger failures that are impossible to anticipate purely from a mapping document.

Run at least two pilot iterations: one to expose issues, and one to validate the fixes. Only proceed to production migration once a pilot iteration completes with an acceptable error rate.

8. Validate with Business Users

After the pilot, have named business users - not just the project team - validate the migrated data in sandbox against the source system. Provide them with a structured validation checklist: spot-check 20 accounts, verify 10 contacts, review 5 opportunities in detail.

User validation catches issues that technical testing misses: a picklist value that mapped incorrectly, a date field in the wrong format, or a relationship that looks right in the data but feels wrong to the business user who knows the account.

9. Execute the Production Migration

With a validated ETL process, run the production migration during a planned maintenance window. The key steps:

• Freeze the source system (read-only or locked) during migration to prevent new data being added mid-run
• Execute migration in dependency order - Accounts before Contacts, Contacts before Opportunities
• Log every record loaded, every error encountered, and every record skipped
• Monitor progress against expected record counts in real time
• Have a rollback plan ready: know exactly what you will do if a critical error occurs mid-migration

10. Post-Migration Audit and Sign-Off

After the production migration completes, run a reconciliation report comparing source record counts to target record counts by object type. Every discrepancy needs an explanation - either a record was intentionally excluded by scope rules, or there is an error to investigate.

Have the business owner sign off on the reconciliation report before the old system is decommissioned. This sign-off is your protection against post-launch disputes about missing data.