Salesforce Data Migration: The Complete Guide to Planning, Cleaning & Cutover

The Short Answer

Salesforce data migrations commonly fail, not due to the tools themselves, but because of flawed processes. This includes starting data loads before understanding source quality, field mappings developed in isolated Excel sheets without anomaly checks, and loads that disregard object dependencies. A proper process is built as an iterative cycle: profiling, mapping, cleansing, controlled loading, testing, and reconciliation—and only then, cutover.

This article aims to break down the migration lifecycle into clear stages, providing a data load order table and a reconciliation checklist that can be used effectively. In most projects, the difference between a smooth migration and one that leads to rework is decided in the first week, during the source profiling phase.

Early data cleansing work prevents later damage, and it's highly recommended to read more on this at Salesforce Data Deduplication.

Source Profiling: Understand the Data Before Touching It

Before mapping a single field, you must profile the source data: How many records are in each table? Which fields are actually empty (not just in the schema but within the data itself)? What is the range of values in numeric and date fields? Where are free-text values that should be closed lists? In one project we oversaw, a "Client Status" field had 47 different formulations in the source—"Active", "", "Active " with a space, ""—all of which should have mapped to a single value in Salesforce.

Tools like OpenRefine, simple SQL queries, or even an Excel Pivot Table on a data sample are sufficient for most projects. The goal is to generate a profiling document that shows: total record count, percentage of empty required fields, number of unique values for each categorical field, and initial identification of potential duplicates by name, phone, or email.

This stage also identifies if there are multiple overlapping data sources—for example, the same customer existing in both an old CRM and an accounting system—and decides which source is the "Source of Truth" for each field. Such a decision must be documented, not assumed, as it impacts every subsequent stage.

Field Mapping: Beyond the Excel Sheet

Good field mapping isn't just "source column A = target field B." It also includes transformation directions: date format conversion, unit conversions, splitting a single address field into street/city/zip, and a solution for values not present in the target's picklist. The best mapping document we've seen included five columns: Source Field, Target Field, Transformation Type, Rule for Handling Missing Value, and Input/Output Example.

Special attention must be paid to Lookup and Master-Detail fields: they don't contain a direct value but a reference to another record. Therefore, their mapping depends on the linked record already having been loaded and holding an ID that can be referenced. This is why load order (discussed next) and field mapping are two sides of the same decision.

For a broader context on managing field quality over time, not just in a one-off phase, see Salesforce Data Quality Metrics.

Cleansing and Duplicates: Before Loading, Not After

Cleansing data after it's already in the production environment is exponentially more expensive: it involves updating live records, risking broken automations and approval processes, and sometimes compromising reports already distributed to management. Therefore, the cleansing phase must occur in the staging layer before data enters Salesforce.

Key cleansing rules to define in advance:

• Normalization of phone and email (removing spaces, consistent international format)
• Identification of duplicates by combining fields (name + phone, or company ID only for businesses)
• Rule for selecting the Master record when merging duplicates—for example, the most recently updated or most complete record
• Handling Null values versus empty strings, to avoid "phantom duplicates"

In a typical project with about 80,000 customer records, reasonable cleansing will identify between 3% and 8% true duplicates. A significantly higher number suggests the source itself was not maintained, and warrants a discussion with business process owners before proceeding.

External IDs and Load Order

An External ID is a unique identifier from the source system that is also stored in Salesforce, allowing for repeated loading (Upsert) without creating duplicates every time a file is re-run. Without an External ID, every subsequent Data Loader run might create another copy of the same record because the system cannot "recognize" an existing record.

The load order is determined by object dependencies: you cannot load a Contact before the Account it's associated with exists, and you cannot load an Order Item before the Order itself.

Deviating from this order is one of the most common errors in migration projects: teams trying to "save time" by loading all files concurrently later discover thousands of Lookup errors that are difficult to sift through afterward, because it's unclear if the error is due to missing data or an incorrect load order.

For more on managing field quality over time, not just in a one-off phase, refer to Salesforce Data Quality Metrics.

Environments and Testing

A migration is never loaded directly into production. A recommended environment structure includes a dedicated Sandbox for migration (separate from ongoing development Sandboxes), where the same data volume and the same configuration of Validation Rules and Triggers as in production are loaded, to expose issues before they impact real users.

Testing at this stage includes volume testing (does the load complete within a reasonable timeframe), error testing (what percentage of records are rejected and why), and automation behavior testing—a Flow or Trigger that runs on record creation could send a real email to a customer if not temporarily deactivated in the test environment. Forgetting such a detail in one project resulted in thousands of duplicate "welcome" emails being sent to existing customers.

Dry Run: A Full Rehearsal

A Dry Run is a full execution of the loading process under conditions as close as possible to production—same volume, same files, same order—but in a Sandbox environment. The goal is to measure two things: actual execution time (to plan the cutover window realistically) and the percentage of errors at each stage.

It's recommended to perform at least two full Dry Runs: the first often uncovers most issues, the second verifies that the fixes actually resolved them and didn't introduce new problems. If a second run still yields more than 1%-2% errors in critical objects, it's usually better to postpone the cutover date than to compromise on quality.

Cutover and Data Reconciliation

Cutover is the actual window during which the old system is frozen, the latest information is loaded into Salesforce, and users transition to working in the new system. Success at this stage is measured not just by "did the load complete?" but by reconciliation—a systematic comparison between the source and target.

A reconciliation checklist to run at the end of each cutover:

• ☐ Record counts are identical (or explained by a known discrepancy) in every key object
• ☐ Sums of financial fields (e.g., total value of open opportunities) match between sources
• ☐ A random sample of 30-50 records is manually checked field-by-field
• ☐ Relationship checks—does every Contact have a valid Account, every Opportunity Line Item an Opportunity
• ☐ Check for "orphan" records—loaded without a valid reference
• ☐ Comparison of duplicate counts before and after against the target set during the cleansing phase
• ☐ Business process owner approval that their data sample appears correct

Common reconciliation discrepancies include: matching record counts but incorrect sums, because a numeric field was loaded in the wrong format; or missing relationships because a Lookup was loaded by text value instead of External ID. Full documentation of the reconciliation process, including a baseline example, is also found in Salesforce Master Data Management.

Post-Go-Live Fixes

Even a successful cutover leaves a "tail" of fixes: individual records rejected during the load, users reporting missing data, and discrepancies that only emerge when real users work with the system, not just test it. A two- to four-week window for targeted fixes should be allocated in advance, with a daily exception report in the first week and weekly afterward.

It's important to distinguish between a specific fix (a single record updated manually) and a systemic fix (a mapping error that recurs across thousands of records and requires a fix in the loading tool itself and a re-run). Confusing the two causes teams to manually fix a problem that is actually systemic, wasting significant time.

Example Organizational Scenario

A distribution company with approximately 120,000 customers in an old CRM and a separate customer list in the accounting system wanted to migrate both sources to a single Salesforce instance. Initial profiling revealed that 11% of customers appeared in both sources with different contact details, and the "Industry" field contained 340 free-text values that should have been about 25 categories.

The team built detailed field mapping, established a merge rule based on a combination of company ID and phone, and designated the accounting system as the Source of Truth for billing details and the old CRM as the Source of Truth for contact information. The first Dry Run revealed that 4% of records were rejected due to invalid date formats—a fix that was accounted for in the second run. Cutover was performed over a weekend, with full reconciliation on Monday morning before opening the system to users.

The result: less than 0.3% of records required manual correction after Go Live, compared to the team's initial estimate of about 5% exceptions. The difference was almost entirely due to the two Dry Runs performed before the official date.

Common Risks and Prevention Actions

At the management level of a Salesforce data migration, this risk table is just a starting point. An expansion on continuous quality management, including the difference between one-time cleansing and ongoing data governance, is covered in Data 360 Zero Copy.

How to Measure Success

For most projects, three to five metrics are sufficient for the first version. A good metric can be calculated before and after the change, is relevant to the business process owner, and cannot be artificially improved by partial data entry. When no documented baseline exists from the old system, it's worth spending a day or two measuring the current state before reporting improvements.

Checklist Before Go Live

• ☐ Source profiling performed and includes percentages of empty and duplicate fields
• ☐ Full field mapping document, including transformations and handling of missing values
• ☐ External ID defined for every object requiring re-loading
• ☐ Written load order agreed upon by the technical team
• ☐ Two Dry Runs performed and errors reduced below the defined threshold
• ☐ Written rollback scenario in case the Cutover fails
• ☐ Reconciliation Checklist ready and the person responsible for it is known in advance
• ☐ A post-Go Live fix window allocated in the schedule
• ☐ Automations that could send communications to customers checked and deactivated during the load
• ☐ Business process owner signed off on a final data sample

In-Depth Notes for Implementation and Maintenance

Architect's Note: Migration Is Not a One-Time Event

Even after a successful Go Live, changes in the source system (if it continues to operate temporarily in parallel) or manual corrections will create data discrepancies. Therefore, it is advisable to maintain a regular reconciliation report—weekly in the first month, then monthly—that compares a data sample between old and new reports and identifies deviations early. A project that treats migration as a finish line misses the fact that data quality is an ongoing process.

From a management perspective, the true test of a Salesforce data migration is not just whether the records were loaded, but whether Data, CRM, and project managers can trust the reports the day after, without manually checking every number. Organizations seeking professional guidance for such a process can leverage Integration and Data Services, which supports both the planning phase and the cutover window itself.

Professional Resources

• Salesforce Data 360 — https://www.salesforce.com/data/
• Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
• HPI Pro – Integrations and Data — https://hpi.pro/integrations-data