Salesforce data cleanup and migration checklist for 2026
Salesforce data cleanup is the work you do before a migration so you do not move your problems with you: deduplicating accounts and contacts, standardizing fields, pruning dead records and mapping every legacy field to a destination before the first load. A migration without a cleanup phase is the fastest way to pay twice for the same mess — once to move it, once to fix it. This checklist walks the phases in order, with the failure points that bite teams that skip them.
TL;DR
- Clean the source org before migration — dedupe, standardize, archive — or you migrate the mess.
- Map every legacy object and field to a destination in writing before the first test load.
- Run at least one full dry load and validate counts before cutover.
- Freeze data entry during cutover and reconcile record counts the same day.
Why cleanup comes before migration
A migration copies whatever exists in the source org — including the duplicates, the blank fields, the accounts owned by people who left in 2021, and the picklist values nobody uses. Moving that data costs the same effort as moving clean data, and cleaning it afterward is harder because the records now live in a new org with new automation firing on every insert. Clean first, move second. We keep field notes on migrations and integrations in our Salesforce and AI articles.
Phase 1 — scope and audit
- Define the migration scope in objects, not vibes. List the objects moving, the objects staying, and the objects being retired. A written scope ends the "should we bring Cases too?" debates mid-project.
- Profile the data volume. Count records per object and note the largest ones. Volume drives tooling choice: a few thousand records moves with Data Loader, millions need a bulk API approach and a schedule.
- Find the owners. Every object in scope needs a business owner who can answer "is this record still active?" — otherwise cleanup stalls at the first judgment call.
- Check field usage. Identify fields that are empty or filled with free-text noise. Fields nobody populates do not migrate; they get documented and dropped.
Phase 2 — deduplicate and standardize
- Run duplicate rules on accounts, contacts and leads. Salesforce's built-in duplicate rules and reports surface the obvious merges. Decide merge policy before touching anything: which record survives, which fields win on conflict.
- Standardize picklist values. One org's "Closed - Won" is another's "Won" and a third's "won!!". Normalize values before the mapping exercise, or the mapping carries the chaos forward.
- Fix ownership. Reassign records owned by departed users to active teams. Ownership also drives sharing, so this step fixes access problems you would otherwise rediscover after cutover.
- Archive, do not delete, what you are unsure about. Records outside the migration scope move to an archive object, an export, or a holding sandbox — never straight to the trash. "We might need it someday" is a valid archive reason.
Phase 3 — map and prepare the destination
- Write the field mapping document. Every source object and field gets a destination: same field, different field, concatenated, dropped. The document is the contract — every dispute during load gets settled by pointing at it.
- Create custom fields and objects in the destination first. Loads fail halfway when a target field does not exist. Build the destination schema before any data moves.
- Decide what happens to automation. Flows, validation rules and triggers in the destination fire on every loaded record. Plan which rules get temporarily deactivated for the load and re-enabled after, and record the list — a rule left off after cutover is a silent data-quality leak.
- Assign external IDs where possible. An external ID on the destination object makes upserts possible and prevents the classic duplicate storm of loading the same file twice.
Phase 4 — dry run and validate
- Load a full sample into a sandbox. The first load is always a rehearsal in a sandbox, never production. Use a real-size sample, not ten rows — volume is where mapping errors and governor limits surface.
- Validate counts and spot-check records. Compare loaded record counts to source counts per object, then open a sample of records and compare field by field. Count mismatches trace back to filters on the extract; field mismatches trace back to the mapping document.
- Verify relationships survived. Parent-child links, lookup fields and activities are where migrations quietly break. A contact without its account is a count that matches and a record that is wrong.
- Time the load. The rehearsal tells you how long the real load takes, which sets the cutover window and the downtime you need to ask the business for.
Phase 5 — cutover
- Freeze data entry in the source org. Announce the freeze window in advance and enforce it. Data entered during a load is data that exists in neither system afterward.
- Run the production load during the window. Same scripts, same order: parents before children, users and accounts first.
- Reconcile and re-enable. Compare counts again, spot-check the same sample, re-enable the automation you deactivated, and record every difference with a reason.
- Keep the source org read-only for an agreed period. Not deleted — read-only. The first month after cutover is when someone asks for a record that did not make it.
Where migrations go wrong
- Skipping the cleanup because the deadline is close. The deadline does not get shorter; the post-migration cleanup just gets more expensive.
- Mapping in someone's head. An undocumented mapping is undiscoverable when load three produces a field of nulls.
- No freeze window. Incremental syncs of "just the new records" introduce the duplicates you spent Phase 2 removing.
- Testing with ten rows. Small loads hide batching errors, relationship breaks and timeout failures that only appear at real volume.
What SOLVD works toward with clients
SOLVD is a Salesforce consulting partner working on implementations, integrations and the data hygiene underneath both. With clients, the goal we work toward on a migration is a boring one: a written scope, a mapping document both sides signed, a dry run with matching counts, and a cutover day with no surprises. Outcomes depend on the state of the source org — we do not promise numbers; we build the process that makes the numbers visible.
If your org is facing a migration or years of accumulated data debt, book a fit conversation at https://solvd.cloud/fit/#book.
FAQ
How long does Salesforce data cleanup take before a migration?
It depends on org size and data age, but most teams should plan cleanup as its own phase with its own deadline — typically weeks, not days, for an org with several years of history. Cleanup done in a hurry shows up as duplicate and mapping problems after cutover.
Should we clean data before or after migrating to Salesforce?
Before. Cleaning after a migration is harder because the records sit in a new org where automation fires on every edit, and you have paid to move data you are about to change or discard.
What is a dry run in a Salesforce data migration?
A full-size test load into a sandbox that mirrors the production load: same extracts, same mapping, same order. It validates counts, relationships and timing before anything touches production.
How do we prevent duplicates when loading Salesforce data?
Standardize and merge in the source org first, freeze data entry during the load window, and configure external IDs so repeated loads upsert instead of inserting. A freeze window matters more than any tool.
Should old Salesforce records be deleted before a migration?
Archive them instead — to an export, an archive object or a holding sandbox. Deletion is irreversible and migration scope debates usually end with someone needing the data after all.
What is a field mapping document?
A written table mapping every source object and field to its destination — same field, different field, transformed, or dropped. It is the contract that settles every dispute during the load.