Salesforce Data Migration Failed? Here’s What to Check First (2026)

You spent the weekend running a Salesforce data migration. Monday morning, the team is filing tickets: duplicate accounts everywhere, missing contacts on key opportunities, validation rules blocking record creation, formula fields showing #ERROR. Or maybe you’re about to run the migration this weekend and you’re trying to figure out — should you use Data Import Wizard or Data Loader for Salesforce, and what are the mistakes you don’t know to avoid? Either way, here’s the honest admin’s guide to what breaks Salesforce migrations and how to either prevent it or recover fast.

Data Import Wizard vs Data Loader: The Honest Use Case Split

Both tools migrate data into Salesforce. The differences that actually matter for picking the right one:

For most one-time migrations of 50k+ records, Data Loader is the answer. For ongoing small imports (weekly contact list refresh, monthly territory updates), Data Import Wizard is faster to set up and easier for non-technical admins to run. Salesforce’s official Data Loader documentation covers the technical setup; the strategic question is just which tool to reach for given your scenario.

Beyond Both: When You Actually Need Bulk API 2.0

For very large migrations (millions of records), neither Data Import Wizard nor Data Loader is the right tool. Bulk API 2.0 is what you reach for when:

• You’re migrating 5M+ records. Data Loader works but slowly; Bulk API 2.0 is faster.
• You need parallel processing. Bulk API 2.0 handles multi-job parallel execution natively.
• You’re building a repeatable scripted migration. Bulk API integrates cleanly into Python/Java/Node migration scripts.
• You need fine-grained error handling. Bulk API 2.0 returns detailed per-record error reporting that’s easier to consume programmatically.

The trade-off: Bulk API 2.0 requires developer effort to use. It’s not an admin tool. For migrations where complexity justifies the engineering investment, it’s the right tool. Otherwise, Data Loader handles 95% of mid-market migration needs.

The Duplicate Account Problem (3 Prevention Strategies)

The single most common post-migration ticket: “I have 4 accounts for the same company.” Prevention strategies, in order of effectiveness:

• Match on a stable external ID, not on Name. Account Name is messy (“Acme Corp” vs “Acme Corporation” vs “Acme, Inc”). External ID (your source system’s account ID, properly mapped to an External ID custom field in Salesforce) gives clean 1:1 matching every time.
• Set up Salesforce duplicate matching rules BEFORE migration. Salesforce can block duplicate creation in real-time during the import if matching rules are configured. Set them up first, run the import second.
• Pre-dedupe in staging. Before importing, run a deduplication pass on your source data. Fix the duplicates BEFORE they hit Salesforce, not after.

Doing all three is overkill for most migrations. Doing none of them is the #1 cause of post-migration cleanup work. If duplicates already made it through despite these safeguards, our guide on how to mass merge duplicate Accounts and Contacts in Salesforce without breaking data covers the cleanup process.

Validation Rules: Which to Disable, Which to Keep, How to Restage

Validation rules will block your migration if you don’t plan for them. The pattern that works:

1. Audit ALL active validation rules on every object you’re migrating into. There will be more than you expect.
2. Identify the rules that will fire on legacy data. Field requirements that didn’t exist when the historical data was created. Format rules tighter than the source system enforced.
3. For each blocker, decide: disable temporarily, modify to exclude migration users, or fix the data before import.
4. Disable cleanly (don’t delete). Deactivate validation rules via metadata. Keep the rule definition so you can re-enable post-migration.
5. Set up a “migration user” exception if you’ll need to run multiple cleanup batches. Rules check user — migration user bypasses, other users still blocked.
6. Re-enable in stages post-migration. Don’t flip everything back on at once. Re-enable rule-by-rule and verify each one doesn’t surface unexpected legacy data violations.

For broader context on the Salesforce admin work that prevents data migrations from going sideways, our Salesforce optimization work includes a pre-migration audit of validation rules, automation, and sharing model as a standard scope item.

The 12 Mistakes That Break Salesforce Migrations

The complete checklist. Each of these has burned mid-market admins we’ve worked with at Cloud Nexus.

1. Skipping the sandbox dry run

Test migrations in sandbox first. Every time. Production is not a testing environment, and “we’ll fix issues as they come up” turns into a week of unplanned cleanup.

2. Leaving automation active

Workflows, Process Builder, Flows, Apex triggers will fire on every imported record. 50k account imports trigger 50k flow runs. Disable during migration, re-enable after.

3. Active validation rules

Rules tighter than your source system will block valid historical data. Audit and selectively disable.

4. Ignoring duplicate matching rules

Salesforce can prevent duplicate creation during import — but only if matching rules are configured first. Set them up, then import.

5. No external ID staged

Matching on Name causes duplicate hell. Always map a stable external ID from your source system.

6. Batch sizes too large

200-2,000 record batches handle most cases. Larger batches risk timeout. Smaller is slower but more reliable.

7. No rollback plan

If the migration goes wrong, can you undo it? Take a full export immediately before migration. Tag imported records with a unique batch ID for easy filtering.

8. No field mapping document

“What goes where” needs to be a document, not a memory. Source field → Salesforce field → transformation rule → who owns it.

9. Mixed-case picklist values

“Customer” and “customer” and “CUSTOMER” become three different picklist values. Standardize source data before import.

10. Time zone confusion

Salesforce stores datetimes in UTC and displays in user time zone. Source data in local time without time zone metadata = dates shift unpredictably.

11. Broken parent-child relationships

Import Accounts before Contacts. Contacts before Opportunities. Migration order matters, and getting it wrong leaves orphan records.

12. Inadequate post-migration QA

Count records imported, sample-test relationships, validate against source-of-truth, spot-check user access. Skip this and you ship problems into production.

The most common mistake on this list is starting the migration before you understand the source-system shape you’re working from. Before you map a single field, start with a free 90-minute audit of your current org — even if you’re already on Salesforce, the audit surfaces the data model quirks and existing customizations that shape every migration decision downstream.

Migration Order Matters (the dependency chain)

Salesforce data has implicit dependencies. Importing in the wrong order creates orphan records that take days to clean up. The correct order for typical B2B migrations:

1. Users + Profiles + Permission Sets — record ownership lives here
2. Custom Picklists — anything you reference must exist first
3. Accounts — parent of most relationships
4. Contacts — children of Accounts
5. Products + Price Books — referenced by Opportunities
6. Opportunities — reference Accounts, Contacts, Products
7. OpportunityLineItems — children of Opportunities
8. Cases — reference Accounts, Contacts
9. Activities (Tasks, Events) — reference everything above
10. Attachments / Files — last (they reference records that must already exist)

Get the order wrong, and you’ll have Opportunities pointing at Accounts that don’t exist yet, or Contacts orphaned from their Account parent.

Post-Migration QA Checklist

The 60-minute checklist that catches 90% of migration problems before users do:

• Record count match. Source X records → Destination X records (per object).
• Relationship integrity. Sample 50 random child records. Each must have its parent populated correctly.
• Field population. Sample 100 random records per object. Verify all critical fields populated, no unexpected #N/A or NULL.
• Audit field accuracy. If you preserved CreatedDate/CreatedById, sample 20 records to verify the source values made it through.
• Picklist values. Pull distinct picklist values per object. Look for unexpected values (case variations, typos) that snuck through.
• Validation rule re-enablement. Re-enable each rule. Watch for unexpected fires.
• Automation re-enablement. Re-enable workflows/flows/triggers. Spot-check that recently-modified records process correctly.
• User access spot check. Log in as 3-5 different user profiles. Confirm they see what they should see.
• Reports running. Open 10 commonly-used reports. Confirm they return reasonable numbers. If a report suddenly shows what looks like duplicate rows for the same record, that’s not necessarily a leftover duplicate — see our diagnostic guide on why Salesforce reports show duplicate rows before assuming the migration itself failed.
• Search working. Search for 10 known records by name. Should appear in results.

Frequently Asked Questions

Should I use Data Import Wizard or Data Loader for Salesforce?

Use Data Import Wizard when the migration is under 50,000 records per object, only touches standard objects (Accounts, Contacts, Leads, Solutions, Custom Objects), and you don’t need to preserve system audit fields like CreatedDate. Use Data Loader for any migration above 50,000 records, when you need to touch objects Data Import Wizard doesn’t support (Opportunities, Cases, Assets, etc.), when CreatedDate or other audit fields must be preserved, or when scheduling automated recurring imports. For very large migrations (5M+ records), neither is the right tool — Bulk API 2.0 with developer effort is the answer. For most mid-market one-time migrations, Data Loader handles 95% of needs.

How do I prevent duplicate accounts during a Salesforce data migration?

Three prevention strategies in order of effectiveness: (1) Match on a stable external ID from your source system, not on Account Name — names are messy (“Acme Corp” vs “Acme Corporation” vs “Acme, Inc”), external IDs give clean 1:1 matching; (2) Set up Salesforce duplicate matching rules BEFORE migration so Salesforce can block duplicate creation in real-time during the import; (3) Pre-dedupe in staging — fix duplicates in your source data BEFORE importing, not after. The single biggest cause of post-migration “I have 4 accounts for the same company” tickets is matching on Name instead of using a stable external ID. Pick that one strategy if you only do one.

Which validation rules should I disable during a Salesforce data migration?

Audit every active validation rule on every object you’re migrating into, then identify which would fire on legacy data — usually field requirements that didn’t exist when the historical data was created, or format rules tighter than the source system enforced. For each blocker, decide: disable temporarily, modify to add a migration user exception, or fix the source data before import. Best practice: deactivate cleanly (don’t delete) so you can re-enable post-migration; set up a “migration user” exception if you’ll run multiple cleanup batches so the rules still check other users; re-enable in stages post-migration, rule-by-rule, watching for unexpected legacy data violations. Don’t flip everything back on at once.

What’s the difference between Bulk API 2.0 and Data Loader?

Data Loader is a desktop application that uses Bulk API under the hood, with a UI that lets admins run migrations without coding. Bulk API 2.0 is the underlying REST API that handles large-scale data operations, accessed directly via developer code (Python/Java/Node) or via integration platforms. Use Data Loader when an admin can drive the migration through its UI and the migration is one-time or simple recurring. Use Bulk API 2.0 directly when you’re building a repeatable scripted migration, need parallel processing across multiple jobs, need fine-grained programmatic error handling, or are migrating volumes (5M+ records) where Data Loader’s overhead becomes meaningful. The trade-off: Bulk API requires developer effort; Data Loader doesn’t.

What order should I import data into Salesforce?

Order matters because Salesforce has implicit dependencies — child records can’t reference parents that don’t exist yet. The correct sequence for typical B2B migrations: Users + Profiles + Permission Sets first (record ownership lives here), then Custom Picklist values, then Accounts (parent of most relationships), then Contacts (children of Accounts), then Products + Price Books (referenced by Opportunities), then Opportunities (reference Accounts, Contacts, Products), then OpportunityLineItems (children of Opportunities), then Cases (reference Accounts, Contacts), then Activities like Tasks and Events (reference everything above), then Attachments and Files last (reference records that must already exist). Get the order wrong and you’ll have Opportunities pointing at Accounts that don’t exist yet, or Contacts orphaned from their Account parent.