Data migration is the single highest-risk activity in any Salesforce project. A missed deduplication step or an ignored validation rule can corrupt months of sales history. This checklist is what I run through on every migration, no exceptions.

Discovery & Planning (Steps 1–5)

  1. Audit the source data. Export everything. Count rows per object. Identify null rates, duplicate rates, and encoding issues before writing a single mapping.
  2. Define the migration scope. Which objects? Which date range? Historical data often needs to be trimmed to what's actually useful in Salesforce.
  3. Build the field mapping document. Source field → Target field → transformation rule → default value. Every unmapped source field is a decision, not an oversight.
  4. Identify record relationships. Parent-child relationships (Account → Contact → Opportunity) must load in dependency order. Map how legacy IDs translate to Salesforce IDs — keep an External_Id__c field for each object.
  5. Agree on a deduplification strategy. Will you deduplicate before migration, after, or both? Define the match criteria (email, name + company, phone). Get sign-off from business stakeholders.

Sandbox Testing (Steps 6–12)

  1. Disable validation rules and workflow rules. In a Full Sandbox, disable automations before loading. Re-enable after. Legacy data rarely satisfies rules written for future-state processes.
  2. Disable duplicate rules. Or set to Alert-only. Your legacy data will have duplicates — handle them deliberately, not via load failures.
  3. Load a 10% sample. Use Data Loader or the Bulk API. Validate row counts, spot-check 20+ records manually.
  4. Run data quality reports. SOQL queries to find nulls in required fields, orphaned child records, date values outside expected ranges.
  5. Test relationships end-to-end. Open a migrated Account — are its Contacts there? Open a Contact — is the related Opportunity there? Spot-check the full parent-child chain.
  6. Load the full dataset to sandbox. Fix all errors from the sample load. Rerun until errors = 0.
  7. UAT with key users. Have 2–3 business stakeholders validate their records in sandbox. Never skip this step — they will find things you missed.

Pre-Migration Production (Steps 13–17)

  1. Agree on a cutover window. Nights and weekends. Communicate to all users. The longer the migration, the longer the freeze on source system updates.
  2. Export fresh production data. The closer to cutover, the better. Delta load strategy if the migration window is short.
  3. Document the rollback plan. If migration fails at step 18, what do you delete? Have a written, tested rollback script ready.
  4. Re-disable automations in production. Same as sandbox: validation rules, workflows, triggers. Have a checklist of exactly which ones to re-enable after load.
  5. Notify users of the maintenance window. Email, Slack, calendar invite. Include expected downtime and go-live time.

Migration Day (Steps 18–20)

  1. Load in dependency order. Accounts → Contacts → Opportunities → Activities. Monitor Bulk API job status. Don't start the next object until the previous one is error-free.
  2. Post-load reconciliation. Row count in source = row count in Salesforce (minus intentionally excluded records). Check totals: sum of Opportunity amounts in source vs. Salesforce.
  3. Re-enable automations and open access. Re-enable validation rules, duplicate rules, and workflows. Announce go-live.
SK

Sumit Kumar Singh

Independent Salesforce Consultant

I've run data migrations ranging from 10,000 to 5 million records. The checklist is always the same — the mistakes happen when you skip a step.

About the Author