Do I Need to Clean Data Before a Salesforce Migration?

Updated May 2026 · 12 min read

Yes. In almost every case, you should clean your data before you migrate to Salesforce, not after. Whatever you don't fix in the old system gets carried into the new one, and your reps see the same duplicates and blank fields on day one that made them distrust the last CRM. The only real exception is a small move (a few thousand records) from a source you already keep tidy, and even then you'll want a quick dedupe and email check first.

Here's why "export everything, import everything, fix it later" fails so reliably. Once your team is live in Salesforce, they're creating records, logging calls, and building pipeline on top of the mess. Cleaning then means disrupting active workflows. Cleaning before means doing it once, in a system you control, where nobody's depending on the data yet.

Migrating dirty data into a clean Salesforce instance is like moving house and bringing every bag of junk from the garage. You had a chance to start fresh. Instead, you paid movers to haul garbage across town.

A Salesforce data migration done right starts with cleanup. The rest of this guide covers when you can skip it, what to clean and in what order, how field mapping works, and how to verify the import actually worked.

When You Can Skip the Cleanup (and When You Can't)

Not every migration needs a four-week cleanup project. The honest answer depends on volume, source quality, and how long the data has been sitting. Use this to decide how much work is in front of you.

Your situation	How much cleanup you need
Under 5,000 records from a CRM you actively maintain	Light. Dedupe, validate emails, drop obvious junk. A day or two.
10,000-100,000 records, mixed quality, last audited 1+ years ago	Full pass. Dead-record removal, dedupe, field standardization, email validation. 2-4 weeks.
Multiple source systems merging into one Salesforce org	Heavy. Cross-source dedupe and conflict resolution on top of everything above.
Spreadsheets or a legacy CRM nobody remembers configuring	Heavy. Expect surprises in how fields were actually used. Interview your team first.
You're consolidating to reduce billing or storage	Removal-focused. The goal is migrating less, so dead-record and duplicate cleanup pay off twice.

So can you ever truly skip it? Only at the top row, and even there "skip" really means "do the fast version." There's no scenario where importing known duplicates and dead emails into a fresh org pays off. You're just deferring the cost to a worse time.

What to Clean First

Don't try to fix everything. Focus on the problems that will cause the most damage if they make it into Salesforce. Clean in this order.

1. Remove Dead Records

Before you think about fixing data, get rid of the data you don't need. Every record you don't migrate is a record you don't have to clean, map, or maintain.

Candidates for removal:

• No activity in 2+ years and no open Opportunities. These people have probably changed roles or companies.
• Bounced emails with no other contact info. If you can't reach them, there's no point migrating them.
• Test records and junk entries. "Test Test" at "[email protected]." Every CRM has them.
• Competitors and vendors. Unless you track these intentionally, they don't belong in your sales pipeline.
• Personal email addresses for B2B records (gmail, yahoo, hotmail). These are usually low-quality leads that never converted.

Be aggressive here. We typically see 20-40% of a database qualify for archival or deletion before migration. That's 20-40% less data to clean, map, and verify. It also stops you from paying to move records that were already costing you. The true cost of bad CRM data doesn't disappear in a migration. It follows the records.

2. Merge Duplicates

Duplicates are the single biggest mess you can bring into a new CRM. They cause split pipelines, double outreach, and confused territory assignments from day one.

Run deduplication in your source system before exporting. It's easier to merge records in a system you know than in Salesforce on day one. See our duplicate management guide for the full process.

If you can't merge in the source system (some legacy CRMs make this painful), export your data and deduplicate in a staging environment. A spreadsheet works for small datasets. For larger volumes, use a tool like Cloudingo, DemandTools, or even a Python script that groups records by email or normalized company name.

3. Standardize Key Fields

Your old CRM probably has free-text fields where Salesforce expects picklist values. Clean these before migration so they map cleanly.

Field	Common Problems	Fix Before Migration
Country	"US", "USA", "United States", "U.S."	Standardize to Salesforce's country picklist values
State/Province	"California", "CA", "Calif", "calif."	Use 2-letter abbreviations consistently
Industry	Free text with hundreds of variations	Map to Salesforce's standard Industry picklist
Lead Source	"Web", "Website", "Inbound", "Web Form"	Consolidate to your planned Salesforce picklist values
Job Title	Inconsistent abbreviations and formats	Standardize seniority and function

4. Fix Incomplete Records

For records you're keeping, fill in the critical gaps. At minimum, every Account should have Industry, Website, and location data. Every Contact should have a valid Email and Title.

You don't need to enrich every field before migration. But the fields that drive routing, scoring, and segmentation should be as complete as possible. Starting with clean, complete data in Salesforce is much easier than trying to backfill after your team is already using the system.

5. Validate Email Addresses

Run your contact emails through a validation service (ZeroBounce, NeverBounce, BriteVerify) before migration. Remove or flag hard bounces. This saves you from importing thousands of dead emails that will hurt your sender reputation the moment you start sending from Salesforce or a connected marketing platform.

Field Mapping: The Tedious Part That Matters

Every CRM structures data differently. HubSpot properties don't map 1:1 to Salesforce fields. Legacy CRMs have custom fields with no obvious Salesforce equivalent. Spreadsheets have column names that mean something to one person and nothing to anyone else.

How to build a field map

1. Export your source field list. Every field name, data type, and a few sample values. If your source is a spreadsheet, this is just the column headers plus example rows.
2. List your Salesforce target fields. Standard fields plus any custom fields you've created. Note the data type and any picklist values.
3. Map source to target. In a spreadsheet, put source fields in column A and Salesforce target fields in column B. Mark each row as Direct Match, Needs Transformation, No Equivalent, or Don't Migrate.

Common mapping challenges

Migrating from HubSpot. HubSpot uses "Company" as a property on Contacts. Salesforce separates Contacts and Accounts. You'll need to extract unique companies from your HubSpot contacts, create Account records, then link Contacts to Accounts via AccountId. HubSpot's Lifecycle Stage maps loosely to Salesforce's Lead Status or Opportunity Stage, but not perfectly. Plan for manual mapping.

Migrating from spreadsheets. The biggest challenge is relationships. A spreadsheet is flat. Salesforce is relational. You need to figure out which rows become Accounts, which become Contacts, which become Leads, and how they connect. If your spreadsheet has "Company Name" and "Contact Name" on the same row, you'll need to split that into two records and create the lookup relationship.

Migrating from a legacy CRM. Older systems often store data in unexpected places. Notes fields might contain critical information that should be structured data. Custom fields may have been repurposed from their original intent ("Phone 2" is actually used for mobile numbers). Interview your team to understand what fields actually mean before mapping them.

Fields that need transformation

• Full Name to First + Last: Split on the last space. Handle edge cases like "Mary Jane Watson" (first: "Mary Jane", last: "Watson").
• Address to Street + City + State + Zip: Parse carefully. Regex works for US addresses but gets complicated for international.
• Date formats: "03/17/2026" vs "2026-03-17" vs "March 17, 2026". Standardize to ISO format before import.
• Currency: If your source stores revenue as text ("$1.5M"), you'll need to convert to a number (1500000) for Salesforce's currency field.
• Multi-select values: If your source uses a semicolon-separated list in one field, and Salesforce uses a multi-select picklist, make sure the values match exactly.

Testing in Sandbox

Do not import directly into your production Salesforce org. Ever. Use a sandbox.

Test migration process

1. Import a small batch (100-500 records) into your sandbox using Data Loader or Salesforce's import wizard.
2. Verify field mapping. Open 10-15 records and compare them against the source data. Are values in the right fields? Are picklists populated correctly? Are dates formatted right?
3. Check relationships. Are Contacts linked to the right Accounts? Are Opportunities associated with the correct Account and Contact?
4. Test automation. If you've built Flows, validation rules, or Apex triggers in Salesforce, make sure imported data doesn't break them. A trigger that fires on record creation might behave unexpectedly when 50,000 records are imported at once.
5. Run reports. Pull the reports your sales team will use on day one. Pipeline by stage, accounts by industry, contacts by account. Do they look right?
6. Fix issues, re-import. You'll find problems. That's the point of testing. Fix the field mapping, clean the data further, and import another test batch until it's right.

Post-Migration Verification

After the production import, run these checks before telling your team the new system is ready.

Record count verification

Check	Expected Result
Total Accounts in Salesforce	Matches your cleaned source count
Total Contacts in Salesforce	Matches your cleaned source count
Contacts without Accounts	Zero (unless intentional)
Opportunities without Accounts	Zero
Records with blank required fields	Minimal, matches pre-migration expectations

Data quality spot check

Pull 25-50 random records and compare them against your source system, field by field. Look for:

• Truncated values (fields that exceeded Salesforce's character limit)
• Encoding issues (special characters showing as garbled text)
• Date shifts (timezone conversions can move dates by a day)
• Missing related records (Activities, Notes that didn't migrate)

User acceptance

Have 3-5 reps open their accounts in Salesforce and tell you if the data looks right. They know their accounts. They'll spot problems that automated checks miss. "This account was acquired six months ago" or "This contact left the company" are things only your team knows.

Common Migration Cleanup Mistakes

Migrating everything "just in case." The data you don't migrate doesn't need to be cleaned, mapped, verified, or maintained. Be ruthless about what makes the cut. You can always import archived records later if someone actually needs them. They almost never do.

Cleaning after migration. Once your team is using Salesforce, they're creating new records, logging activities, and building pipeline on top of dirty data. Cleaning it after the fact means disrupting live workflows. Clean before.

Skipping the sandbox test. "We'll just fix it in production" is how you end up with 50,000 records where the First Name and Last Name fields are swapped. Test first.

Not involving your sales team. RevOps and IT can handle the technical migration, but your reps know the data. They know which accounts are actually active, which contacts are stale, and which custom fields matter. Get their input during the cleanup phase, not after.

Forgetting about Activities and Notes. Everyone focuses on Accounts, Contacts, and Opportunities. But Activities (calls, emails, meetings) and Notes contain critical context. If your reps open an Account in Salesforce and all the historical Activity is gone, they've lost months of relationship context. Plan for Activity migration or accept that history starts fresh.

When to Get Help

Small migrations (under 10,000 records from a known CRM like HubSpot) are manageable in-house with Data Loader and some spreadsheet work. You can follow this guide step by step and get it done in a week.

Larger migrations get complicated fast. Complex field mappings, multiple source systems, Activity migration, custom object relationships, and deduplication across hundreds of thousands of records. These are the projects where a mistake in the field mapping or a missed deduplication step costs weeks of rework.

We handle pre-migration cleanup regularly. It's one of the most common reasons companies reach out to us, usually 2-4 weeks before their planned go-live when they realize their data isn't ready. If you're in that situation, we can help. We clean data for a living, and migration prep is one of our specialties. A migration is also the cleanest moment to set up ongoing CRM hygiene so the org you just built doesn't drift back to where the old one was.

Common Questions About Salesforce Migration Cleanup

Related: All Salesforce Guides | CRM Migration Cleanup | Duplicate Management | Data Quality Audit