Do I Need to Clean Data Before a Salesforce Migration?

Updated May 2026

Yes. In almost every case, you should clean your data before you migrate to Salesforce rather than 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 worked.

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

Some migrations need only a focused cleanup pass. The scope depends on volume, source quality, object complexity, and how long the data has been sitting. Use a sample to decide how much work is in front of you.

Your situation	How much cleanup you need
A small, actively maintained CRM	Light. Dedupe, validate emails, drop obvious junk. A day or two.
A larger CRM with mixed quality and no recent audit	Full pass: inactive-record review, deduplication, field standardization, and email validation.
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 used in practice. 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.

A focused migration may need only a short validation pass, but known duplicates and invalid contact fields should still be separated before import. Deferring reviewed exceptions moves the same work into the production system, where rollback and ownership are harder.

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. Each record you don't migrate is a record you don't have to clean, map, or maintain.

Candidates for removal:

• No activity since the date your team selected and no open Opportunities. Review these records before moving them.
• 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]." Each 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 rarely converted.

Be deliberate here. Excluding ineligible records reduces the data to clean, map, verify, and move. Record the exclusion rule and retained archive so the decision can be reviewed later.

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, each Account should have Industry, Website, and location data. Each Contact should have a valid Email and Title.

Enrich the fields that drive routing, scoring, and segmentation before migration. Other fields can wait. 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

Each 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. Each 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" holds mobile numbers). Interview your team to understand what each field holds 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.
• Worked example: if a source stores revenue as abbreviated text, define the conversion to a numeric value and test it against the target CRM'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 deliberately small, reversible batch into a sandbox with the approved import tool, then inspect mappings, relationships, automation, and rejected rows.
2. Verify field mapping. Open a representative sample and compare it against the source data. Are values in the right fields? Are picklists populated correctly? Are dates formatted correctly?
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 needed 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." Data outside the approved scope does not need to be cleaned, mapped, verified, or maintained. Keep an archive and a documented retrieval path for excluded records instead of importing them speculatively.

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. 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 still active, which contacts are stale, and which custom fields matter. Get their input during the cleanup phase rather than 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. 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