Salesforce data migration checklist: what to scan before you move

Data migration isn't about moving data—it's about moving *usable* data. I've overseen 12 enterprise migrations across healthcare, finance, and retail, and the single biggest failure point is skipping pre-migration scans. You can't fix bad data after it's in Salesforce. Here’s what you *must* scan before hitting "migrate."

1. Duplicate & Inconsistent Identifiers

Legacy systems often use non-unique IDs (e.g., "Customer_ID" with duplicates). In a recent healthcare migration, we found 14,200 duplicate patient records because the legacy system used "Last_Name + DOB" as a key. When Salesforce tried to merge them, it created 2,800 new accounts instead of deduplicating. Run this SOQL *before* migration to find gaps:

SELECT COUNT(), Name 
FROM Account 
WHERE Name IN (
    SELECT Name 
    FROM Account 
    GROUP BY Name 
    HAVING COUNT() > 1
)

Don’t rely on "clean" legacy data. Scrub IDs in the source first—use a tool like Data Loader to flag duplicates *before* export.

2. Broken Integration Dependencies

Legacy data often contains invalid references. At a financial services client, their "Opp_Stage" field had values like "Won (Closed)" instead of Salesforce’s standard "Closed Won." When migrated, these deals broke pipeline reports and automated workflows. Check for:

• Custom picklist values not in Salesforce (e.g., "Pending Approval" vs. "In Review")
• External IDs referencing non-existent objects (e.g., "Contract_External_ID" pointing to a deleted custom object)
• URLs in text fields pointing to decommissioned systems

Run a dependency scan using the Metadata API to map all references. If you skip this, your "fixed" migration will cause chaos in the new org.

3. Data Type & Format Mismatches

Finance data migration example: Legacy system stored currency as text ("$1,000.00") instead of numeric. Salesforce converted it to 1000.00, breaking financial reports. Always validate:

• Phone numbers: Standardize to E.164 format (e.g., "+14155552671")
• Date fields: Confirm ISO 8601 format (YYYY-MM-DD) to avoid timezone errors
• Numbers: Ensure no commas or currency symbols (use `REPLACE(Phone, ',', '')` in SQL)

Run a quick test migration on a sandbox. If a "Total_Amount" field shows as "$5,000" instead of 5000, fix the source data *now*—not after the live move.

4. Security & Sharing Violations

In a retail migration, we imported 200,000 customer records with "Public" sharing settings on a custom object. This exposed sensitive purchase history to all users. Scan for:

• Records with "All Users" or "Public" sharing settings
• Profile permissions missing for migrated objects (e.g., custom "Loyalty_Tier__c" not visible to Sales Reps)
• External IDs referencing deleted users (e.g., "Owner_ID" = user not in Salesforce)

Use this SOQL to find orphaned records:

SELECT Id, OwnerId 
FROM Account 
WHERE OwnerId NOT IN (
    SELECT Id FROM User
)

The Bottom Line

Skipping these scans guarantees post-migration firefighting. I’ve seen teams spend 300+ hours cleaning data *after* migration instead of 5 hours *before*. Your migration budget isn’t for fixing broken data—it’s for verifying it.

Stop guessing. Run these checks. Then, if you’re short on time or need a second pair of eyes, get a free Salesforce org health scan. I’ve used OrgScanner to catch hidden issues in 90% of migrations I’ve managed—no fluff, just actionable reports. Scan your org today before your next migration. Your future self will thank you.