DEV Community

Cover image for Salesforce Data Migration: A Practical Checklist Before You Hit Import
Rohan Mehta
Rohan Mehta

Posted on

Salesforce Data Migration: A Practical Checklist Before You Hit Import

Salesforce Data Migration: A Practical Checklist Before You Hit Import

Bad data doesn't just survive a migration — it multiplies. Here's a no-nonsense checklist for admins running imports, so the new org starts clean instead of inheriting every mess from the last one.

Byline: Rohan Mehta, Salesforce writer at Way2Force

1. Dedup before you touch the new org

Run duplicate detection on the source data first. Salesforce's matching rules can catch a lot, but they're only as good as your data standards. Normalize names (Ltd vs Limited), merge obvious duplicates, and decide which record wins before the import, not after. There's no import tool that fixes a "which John Smith is real" problem for you.

2. Map fields on paper, not in your head

Every legacy field needs a Salesforce destination or an explicit "drop it" decision. Watch for the classic traps: picklist values that don't exist in the target org, date formats your locale will read wrong, and text fields hiding in lookup territory. A one-page mapping sheet takes twenty minutes and saves hours of re-imports.

3. Cleanse at the source — that's what migration day is for

A migration is the cheapest data-cleaning window you'll ever get. This is exactly why data quality has to come before any AI or automation ambitions — garbage in really does mean garbage out. Trim stale records, fix casing, standardize addresses. If a record hasn't been touched in five years, ask whether it earns a seat in the new system.

4. Import in slices, validate each one

Don't throw 200,000 records at the Data Loader on a Friday afternoon. Import a pilot slice of a few hundred, run your reports, check your record types, triggers, and required-field behavior, then scale up. Validation rules and flows that didn't exist in the legacy system can fail imports in ways that only surface at volume.

5. Protect your automations from the import

Temporarily disable or scope your Flows, Process Builders (if any still linger), and assignment rules before a bulk load — or at least test them against the imported data shape first. Understanding who your automation runs as matters doubly during imports, because a context you didn't intend can stamp thousands of records with the wrong owner or sharing behavior.

6. Keep an audit trail

Log the source, the import date, and the tool for every batch. When someone finds a bad record in six months, "it came from the Q3 import, batch 4" is the difference between a surgical fix and a full re-audit.

Wrapping up

A clean migration is unglamorous work — deduplication, mapping, pilot batches — but it's the foundation every report, dashboard, and AI feature sits on later. Do it once, do it right, and your users will never have to know how much junk you quietly kept out of their org.


Originally published at Way2Force

Top comments (1)

Collapse
 
andrei_iunisov profile image
Andrei Iunisov •

Solid checklist, especially the pilot-slice and automation-scoping steps. One gap that often surfaces later is history and relationship fidelity. Field History and Opportunity/Case history are not part of a standard Data Export or Data Loader load of the parent records; they have separate retention limits and are not automatically carried over. If the business needs a point-in-time view or audit trail after go-live, plan an explicit export of the history objects (or a custom archive) before the source system is decommissioned, and document the mapping of External IDs so parent-child links can be reconstructed. Also log the original Salesforce IDs in a custom field or external table so support can trace a record back to the source org. That turns the migration from a one-time load into something still queryable six months later.

If the goal is also to keep that historical data queryable and restorable after the source system is gone, a continuous backup into customer-owned storage closes the gap that one-time exports leave. I work with GRAX on the product part. GRAX captures objects with a sortable audit date into the customer’s own cloud, preserves field history and deleted records, and supports later search or restore without relying on Salesforce’s limited Field History window or the 48-hour Data Export download window. Native Data Export + warehouse remains the no-extra-product baseline for a one-time archive.

⌂ 换网址