Data migration is the most underestimated part of a Salesforce project and the one that causes the most pain at go-live. The configuration is visible — you can see the page layouts, click the buttons, demo the flows. The data is invisible until a sales rep opens an account and finds the wrong contact, a duplicate, or a blank field where their pipeline number should be. That is the moment adoption dies.

This guide is the process we use for small and mid-sized businesses moving into Salesforce, whether from a spreadsheet, an older CRM, or three disconnected systems held together by copy-paste. It is not glamorous. Done well, nobody notices it happened. That is the goal.

Why migration is harder than it looks

Moving data sounds like an export and an import. For a clean list of 500 contacts, it nearly is. The trouble is that most SMB data is not clean, and the messiness is not visible until you try to load it.

Relationships break. Your legacy system knows that Contact “J. Rivera” belongs to Account “Rivera Plumbing.” Salesforce does not, unless you carry that link across deliberately.
Duplicates multiply. The same customer exists three times because three people entered them over five years. Load as-is and you import the mess into a clean org.
Formats disagree. Dates, phone numbers, states, and picklist values that were free-text in the old system now have to fit Salesforce fields with validation rules.
History is uneven. Ten years of records where the first five are missing half their fields. Some of it matters; most of it does not.

The real work is deciding what to bring, cleaning it before it lands, and proving it arrived intact.

Step 1 — Audit the source data

You cannot plan a migration for data you have not measured. Before mapping a single field, profile every source system:

Record counts per object: how many accounts, contacts, opportunities, cases, notes, attachments.
Fill rates per field: what percentage of records actually have a value. A field that is 4% populated usually should not migrate.
Distinct values in every field you plan to map to a picklist. This is where you discover 14 spellings of “California.”
Duplicate estimates: sort by name, email, and phone to gauge how bad the overlap is.
Orphans and broken links: contacts with no company, opportunities with no account, records pointing at owners who left in 2019.

A day spent here saves a week later. It also gives you the numbers to push back when someone insists “we need all of it” — the audit tells you how much that really is and what shape it is in. This is the same discipline from our data audit guide, applied to a CRM migration rather than an AI project.

Step 2 — Decide what actually migrates

The instinct is to bring everything. Resist it. Every record you migrate is a record you have to clean, map, validate, and support. Old junk in a new system is still junk, and it drags down trust in the org on day one.

A workable default for most SMBs:

All active accounts and contacts. These are the working set.
Open opportunities and cases, plus closed ones within a cutoff — usually 24 to 36 months. Reps rarely reference a deal that closed five years ago.
Notes, tasks, and attachments only where they attach to records you are keeping.
Everything else gets archived, not migrated — exported to CSV or a data warehouse where it stays queryable without cluttering Salesforce.

Get this scope agreed in writing before you build anything. “Which records make the cut” is a business decision, and if you make it silently, someone will notice their favorite ancient account is missing the week after launch.

Step 3 — Build the field mapping document

The mapping document is the spine of the whole migration. It is a spreadsheet, one row per source field, with these columns at minimum:

Source field	Source object	Target field	Target object	Transformation	Owner
Company	Contacts	Account Name	Account	Trim, title-case	Ops
Cust Type	Contacts	Type	Account	Map to picklist values	Sales
Created	Deals	CreatedDate	Opportunity	Requires “Set Audit Fields” perm	Admin

The mapping is where the real decisions live:

Picklist alignment. Every distinct source value maps to exactly one Salesforce picklist value, or to a documented default. No stragglers.
Required fields. Salesforce will reject records missing required fields. Decide the fallback value now, not mid-load.
Date and number formats. Standardize to what Salesforce and your data loader expect, including time zones.
Owner assignment. Every record needs an owner. Map legacy owners to Salesforce users, and pick a default owner for records whose original owner is gone.

Do this in the spreadsheet, deliberately, with the field owners signing off. The alternative is discovering the decisions one error at a time during the load.

Step 4 — Deduplicate and cleanse before loading

Clean the data in staging — a working copy in a spreadsheet or a staging table — before anything touches Salesforce. It is dramatically cheaper to merge two duplicates in Excel than to untangle them in a live org after reps have added notes to both.

Deduplication comes down to two decisions:

Matching keys. What makes two records the same? Email is the strongest key for contacts; normalized company name plus domain works for accounts. Phone and name alone are weak — expect false matches.
Master record rules. When two records match, which wins, and how do you combine them? Usually: keep the most recently active record, but merge in any non-blank fields from the loser so you do not lose data.

Standardize while you are in there — trim whitespace, fix casing, normalize states and countries, validate email formats. Turn on Salesforce’s own duplicate rules after the clean load, so they protect the org going forward without fighting you during the migration.

Step 5 — Rehearse the full load in a sandbox

Never load production first. Run a complete dress rehearsal in a Full Copy or Partial Copy sandbox — a Developer sandbox rarely has the room or the configuration to be a fair test.

The rehearsal is where three things get proven:

Load order. Parents before children, always. Accounts before contacts before opportunities before opportunity line items. Notes and attachments last, once their parent records exist.

Relationship preservation via external IDs. This is the technique that makes relational migration work. Add an external ID field (for example, Legacy_Id__c) to each object and load the old system’s primary key into it. When you load child records, you reference the parent by its legacy ID instead of the Salesforce ID you do not have yet. Salesforce resolves the link. Without this, you are re-matching relationships by name and hoping — and hope is not a migration strategy.

Automation off during load. Deactivate validation rules, workflow rules, flows, Apex triggers, roll-up recalculations, and email alerts before loading, then re-enable them after. Otherwise your load either fails against rules written for user-entered data or fires thousands of notification emails to real people. This is the single most common cause of a migration going sideways.

Time every step during the rehearsal. If the full load takes nine hours, that dictates your cutover window. Most SMB migrations use Data Loader (free, handles the volume and relationships); the Data Import Wizard is fine only for simple, single-object loads under 50,000 records.

Step 6 — Validate against the source

A load that finishes without errors is not a load that worked. Validation is proving the data arrived intact, and you define what “intact” means before you start:

Record counts per object, source versus Salesforce. They should match exactly, or every gap should be explained.
Numeric reconciliation. Sum total pipeline value, count of open opportunities, sum of a few key amount fields. The totals should tie out to the source.
Random sampling. Pull 20 to 30 records at random and trace them end to end — right account, right contact, right owner, right values, right relationships.
Relationship integrity. No orphaned contacts, every opportunity on the correct account.
Ownership and sharing. Records land with the right owner so the right people can see them.

Have the business sign off against these criteria. “The data looks right” from someone glancing at a list view is not validation.

Step 7 — Execute the production cutover

By now the sandbox rehearsal has run cleanly at least once — ideally twice. Production cutover is the same sequence, executed against the live org on a schedule everyone has agreed to:

Freeze the legacy system. Users stop entering data. This is why cutovers happen on weekends.
Final delta load. Load everything created or changed since your last sandbox extract.
Re-enable automation — validation rules, flows, triggers, duplicate rules.
Run the full validation suite from Step 6, in production this time.
Keep the legacy system read-only. Do not delete it. It is your reference and your fallback.

When the rehearsal was thorough, the cutover is a calm few hours of running a known script. The drama all belongs to the preparation. Where data migration sits in the wider project schedule is covered in our Salesforce implementation timeline guide.

Step 8 — Keep a rollback path

Every migration needs an answer to “what if the load is wrong?” Build the rollback before you need it:

Batch-tag every record. Stamp a migration batch ID (a custom field or a Data Loader success file with all the new record IDs) on everything you load. A bad batch can then be deleted precisely, without touching anything else.
Snapshot before cutover. Export the target objects immediately before the production load so you have a known-good baseline.
Keep legacy authoritative until validation passes. The old system stays the source of truth until the new data is proven in production, not before.

Rollback is insurance you hope to never claim. The teams that skip it end up manually deleting 40,000 wrong records on a Sunday night.

The pitfalls that quietly wreck migrations

The same handful of mistakes recur across SMB migrations:

Leaving automation on during the load. Flows fire, emails send, validation rules reject data written for humans. Deactivate first.
Migrating relationships by name. Skipping external IDs and re-matching on name guarantees mismatches. Use legacy IDs.
Cleaning data in production. Every day spent deduping in the live org is a day of reps building on records that are about to be merged. Clean in staging.
No cutoff on history. Bringing ten years of dead records because deleting felt risky. Archive instead.
Validating by eyeball. A list view that “looks full” hides missing relationships and silent truncation. Reconcile with numbers.
Testing only the happy path. The rehearsal that skips the messy 5% is the rehearsal that lied to you.

Where a human actually matters

Plenty of a migration is mechanical, and tools handle the mechanical parts well. The judgment calls are where an experienced pair of hands earns its cost:

Mapping ambiguous fields. When the legacy schema has three overlapping “status” fields and nobody remembers which one the business relies on, someone has to make a call and defend it.
Master-record rules for duplicates. Deciding which of two conflicting records wins, and how to merge them, is a business-risk decision, not a spreadsheet formula.
Transformation logic for weird legacy structures. Data that was never designed to be relational — flattened exports, multi-value cells, notes fields carrying structured data — needs real thought to reshape safely.
Reading the org’s automation before you load. Knowing which flows will fire, and which will quietly corrupt the load, comes from having been burned before.

If your data is a clean list from one system, you can likely run this process yourself with Data Loader and a careful weekend. If you are consolidating multiple systems, carrying years of relationships, or your data has never been audited, the migration is usually where a project succeeds or stalls — and the phase most worth a second set of eyes. It is also a real line item in the budget; our implementation cost guide breaks down where data migration falls in a typical range.

Before you start

If you want a fast read on how much cleanup your data needs, our 90-minute CRM audit is a good place to start, and our Salesforce services cover the full migration when you would rather not do it alone.

If you are planning a move into Salesforce and want to know what your specific data will take — how bad the duplicates are, how much history is worth keeping, how long the cutover window needs to be — book a free 30-minute call. We will look at your actual export, flag the risks, and give you a straight answer before you commit to anything.

The SMB Guide to Salesforce Data Migration