Salesforce Data Migration: What Most Projects Get Wrong

I have seen Salesforce projects go sideways for a lot of reasons. Bad requirements. Scope creep. Stakeholder misalignment. But the failure mode that catches organizations most off guard — and does the most lasting damage — is a botched data migration.

The technology side of Salesforce is usually the easy part. Moving years of existing data into it cleanly, without duplicates, broken relationships, or missing history, is where most projects quietly fall apart. Here is what I see go wrong and what to do instead.

Why Data Migration Is Harder Than It Looks

Most organizations underestimate data migration because they think of it as a copy-paste operation. You have data in one place, you move it to another. How hard can it be?

The reality is that your source data — whether it is in a spreadsheet, an old CRM, a database, or a combination of all three — was built around a different data model than Salesforce uses. Fields do not map cleanly. Relationships between records need to be reconstructed. Values that made sense in the old system do not translate to the new one.

Add to that the fact that most legacy data has years of accumulated quality issues — duplicates, incomplete records, inconsistent formatting, outdated contacts — and you have a project that requires real planning, not just a data loader and a weekend.

Mistake #1: Migrating Everything

The first instinct most organizations have is to migrate everything. Every contact, every account, every note going back ten years. The logic makes sense — you do not want to lose history.

But migrating everything means migrating all your bad data too. Contacts with no email address. Accounts that have been closed for years. Duplicate records that were never resolved. Opportunities with no owner and no close date.

Before you migrate a single record, define what you actually need in Salesforce on day one. Active accounts and contacts. Open opportunities. Recent activity history. Everything else can be archived in the source system or migrated in a later phase once the core data is clean and stable.

Mistake #2: Skipping the Data Audit

A data audit is not glamorous work, but it is the most important thing you can do before a migration. Pull your source data into a spreadsheet and look at it honestly. How many duplicate records do you have? What percentage of contacts are missing email addresses? How consistent is your naming convention for accounts?

The answers to these questions determine how much cleanup work you need to do before migration — and how long the migration is actually going to take. Organizations that skip this step almost always discover the problems mid-migration, when fixing them is far more disruptive.

I typically recommend spending at least as much time on data preparation as on the migration itself. Clean data going in means a clean org on the other side.

Mistake #3: Not Mapping Your Data Model First

Salesforce has a specific data model: Accounts, Contacts, Leads, Opportunities, Cases, and so on. Your source system probably has its own structure that does not map neatly to these objects. Before you touch a single record, you need a field mapping document.

A field mapping document lists every field in your source system and identifies where it goes in Salesforce — which object, which field, and what transformation (if any) is needed. It also flags fields that do not have a home yet, which tells you what custom fields you need to create before migration begins.

This document becomes your migration blueprint. It also serves as documentation for your Salesforce org going forward, which is a bonus most teams do not think about until later.

Mistake #4: Running One Big Migration

The riskiest approach to data migration is loading everything at once and hoping it works. When something goes wrong — and something always does — you are left trying to identify which records are bad, roll back what you can, and figure out what to fix before trying again.

A better approach is to migrate in phases and validate each phase before moving on. Start with Accounts. Verify the record count, spot-check key fields, confirm relationships look right. Then migrate Contacts and verify that they are correctly linked to their parent Accounts. Then Opportunities. Then historical activity.

Phased migration is slower, but it is far easier to troubleshoot and far less likely to result in a corrupted org that takes weeks to clean up.

Mistake #5: Migrating Into a Live Org

If your Salesforce org is already in use, never run your first migration directly into production. Use a sandbox. Run the full migration in a sandbox environment, validate the results, fix any issues, and only then run the same process in production.

This sounds obvious, but I have seen organizations skip it to save time — and then spend three times as long cleaning up a production org that has bad data mixed in with real records that users are actively working with.

The sandbox run also gives you a realistic time estimate for the production migration, which matters if you are planning a cutover window.

The Right Tools for the Job

Salesforce provides several native tools for data migration. Data Import Wizard works well for smaller, simpler migrations — up to 50,000 records, standard objects, no complex relationships. Data Loader handles larger volumes and gives you more control over field mapping and error handling.

For more complex migrations — multiple source systems, large record volumes, custom objects with complex relationships — third-party tools like Informatica, MuleSoft, or Jitterbit give you more flexibility and better error logging.

The right tool depends on your data volume, complexity, and how much transformation is required. There is no universal answer, but the worst choice is always the one made without thinking it through.

What a Good Migration Looks Like

A well-executed data migration follows a clear sequence: audit the source data, define the scope, build the field mapping, clean the data, run a sandbox migration, validate, fix issues, run production migration, validate again, and document what was done.

It is not fast. A thorough migration for a mid-size organization typically takes four to eight weeks when done properly. But the result is an org that users trust because the data in it is accurate — and that is the foundation everything else is built on.

If your organization is planning a Salesforce implementation or a migration from one org to another, the time you invest in getting the data right upfront will pay back many times over in adoption, reporting accuracy, and avoided cleanup work down the road.