Salesforce Data Migration Guide | SalesforceTutorial

Salesforce data migration is the controlled movement of records from a legacy system, database, spreadsheet, or another Salesforce org into a target Salesforce org. A safe Salesforce data migration covers planning, field mapping, external IDs, load order, validation, security, and user testing before production cutover.

This guide is written for admins, developers, and architects who need practical steps rather than a generic import checklist. The examples use current Salesforce API v67.0 patterns for Summer ’26 and avoid assumptions that vary by org.

Salesforce Data Migration: What should be planned first?

A Salesforce data migration should start with a migration workbook. Salesforce data migration planning should happen before the first production-like extract leaves the source system. The workbook should list each source table, Salesforce object, field mapping, transform rule, owner, lookup dependency, and validation owner.

Data migration to Salesforce mapping checklist

A data migration to Salesforce should map source values only after the target object model is stable. A data migration to Salesforce becomes harder when record types, required fields, restricted picklists, or lookup fields change after transform scripts are built.

• Keep source keys: store values such as CustomerID, ContractNumber, or LegacyCaseId in Salesforce external ID fields.
• Normalize values: map legacy picklist labels to Salesforce values before loading restricted picklists.
• Define null behavior: decide whether an empty source value clears a Salesforce field or leaves the existing value unchanged.
• Plan ownership: map source owners to active Salesforce users before records are loaded.
• Stamp the run: use a field such as Migration_Run_Id__c where audit and rollback analysis are needed.

Data migration to Salesforce checkpoints before the first load

For data migration to Salesforce from multiple sources, pick one source of truth for each field. For data migration to Salesforce with staged files, freeze the mapping workbook before the test load. For data migration to Salesforce with consent data, involve the legal or compliance owner before values are loaded.

Which sfdc migration tool should you use?

The right sfdc migration tool depends on volume, supported objects, transform complexity, repeat frequency, and audit requirements. Choose the sfdc migration tool after you know record counts, error handling needs, and whether the load repeats after go-live.

An sfdc migration tool should give repeatable mappings, clear error files, and a way to rerun corrected rows. The chosen sfdc migration tool should preserve enough logs for audit review. For data migration to Salesforce, this tool decision should be made before files are transformed. For related setup, see Salesforce Data Loader setup and usage and Salesforce integration patterns.

How to migrate data from SQL Server to Salesforce?

The question how to migrate data from SQL Server to Salesforce usually means either a one-time cutover load or a repeatable integration pipeline. Teams asking how to migrate data from SQL Server to Salesforce should first decide whether SQL Server is only a cutover source or remains part of the future integration design.

How to migrate data from SQL Server to Salesforce in controlled steps

1. Freeze the Salesforce target model, including objects, fields, record types, required fields, and external IDs.
2. Extract parent tables first, then child tables. Keep the SQL Server primary key in every extract.
3. Transform to Salesforce-ready CSV files. Convert dates, owners, picklists, currencies, and address fields before loading.
4. Upsert parent objects such as Accounts, Products, and reference records.
5. Load child records using parent Salesforce IDs or supported external ID relationship syntax.
6. Reconcile counts, failed rows, duplicate reports, and business samples after each object.

-- SQL Server extract for Account migration.
SELECT
    c.CustomerID AS Legacy_Account_Id__c,
    c.CompanyName AS Name,
    c.BillingCity AS BillingCity,
    c.BillingCountry AS BillingCountry,
    c.Phone AS Phone,
    c.LastModifiedDate AS Source_Last_Modified__c
FROM dbo.Customers c
WHERE c.IsActive = 1
  AND c.CustomerID IS NOT NULL;

For a Salesforce data migration from SQL Server, save the query, export timestamp, row count, checksum, and transform script with the migration run notes.

How do Bulk API 2.0 and external IDs support Salesforce data migration?

External IDs make Salesforce data migration repeatable. If a test run creates records and the next run creates the same records again, the migration has a keying problem. An upsert operation uses a key to decide whether to create a new record or update an existing record.

curl --request POST \
  'https://yourDomain.my.salesforce.com/services/data/v67.0/jobs/ingest' \
  --header 'Authorization: Bearer $ACCESS_TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{"object":"Account","operation":"upsert","externalIdFieldName":"Legacy_Account_Id__c","contentType":"CSV","lineEnding":"LF"}'

PATCH /services/data/v67.0/sobjects/Account/Legacy_Account_Id__c/CUST-10045 HTTP/1.1
Host: yourDomain.my.salesforce.com
Authorization: Bearer ACCESS_TOKEN
Content-Type: application/json

{"Name":"Acme Distribution","BillingCity":"Austin","BillingCountry":"United States"}

The REST request creates or updates the Account whose external ID is CUST-10045. Use REST upsert for smaller batches and targeted corrections. Use Bulk API 2.0 for larger CSV-based Salesforce data migration jobs.

How do you validate Salesforce data migration results?

Salesforce data migration validation needs technical checks and user checks. Technical checks prove counts, required fields, relationships, duplicate levels, ownership, and failed rows. User checks prove that migrated data supports real work such as lead conversion, case updates, opportunity close, order lookup, and reporting.

SELECT COUNT(Id)
FROM Account
WHERE Migration_Run_Id__c = 'RUN-2026-06-04-A'

SELECT Id, Name, Legacy_Account_Id__c
FROM Account
WHERE Migration_Run_Id__c = 'RUN-2026-06-04-A'
AND Legacy_Account_Id__c = null
LIMIT 200

For Apex audit utilities, enforce permissions when reading migrated data. The example assumes the custom fields already exist.

public with sharing class MigrationAccountAudit {
    public static List<Account> findRecentlyLoadedAccounts(Datetime startDate, Datetime endDate) {
        if (startDate == null || endDate == null || startDate >= endDate) {
            throw new IllegalArgumentException('Provide a valid migration date range.');
        }
        return [
            SELECT Id, Name, Legacy_Account_Id__c, Migration_Run_Id__c, CreatedDate
            FROM Account
            WHERE Legacy_Account_Id__c != null
            AND CreatedDate >= :startDate
            AND CreatedDate < :endDate
            WITH USER_MODE
            ORDER BY CreatedDate DESC
            LIMIT 200
        ];
    }
}

In this Apex example, with sharing enforces record sharing rules and WITH USER_MODE helps enforce object and field permissions for the query. If a migration utility performs DML, bulkify the code and avoid DML inside loops.

What are salesforce paas ecommerce migration capabilities?

The phrase salesforce paas ecommerce migration capabilities often appears when teams compare Salesforce Platform, Commerce Cloud, integrations, and custom data models. In a Salesforce data migration for ecommerce, translate salesforce paas ecommerce migration capabilities into ownership decisions: which system owns customer identity, product catalog, orders, order items, payments, service cases, and consent after go-live?

For adjacent topics, see Salesforce Data Cloud concepts and Salesforce Commerce Cloud overview.

What security and automation controls affect imports?

Salesforce data migration runs through platform rules unless you design a controlled bypass. Do not disable validation rules, duplicate rules, flows, or triggers as a blanket fix. Decide rule by rule, document the reason, and remove temporary bypass permissions after cutover.

• CRUD and FLS: migration users need object and field permissions for loaded fields.
• Sharing: ownership and role hierarchy affect visibility after load. Test with real user profiles.
• Duplicate rules: decide whether rules block, alert, or are bypassed for approved batches.
• Validation rules: bypass only known legacy exceptions with a named migration permission and audit field.
• Flows and triggers: bulk-test automation before the full load.

Common Salesforce data migration errors and fixes

Best practices for production cutover

A production Salesforce data migration should be scripted, rehearsed, and timed. Run at least one full rehearsal with the selected sfdc migration tool in a sandbox with production-like data volume, the same API version, the same sfdc migration tool, and the same validation queries planned for go-live.

1. Agree on a source freeze window and communicate user impact.
2. Run the final delta extract from SQL Server, the legacy CRM, ecommerce platform, or source application.
3. Load reference and parent records before child records.
4. Save success and error files for every job.
5. Run reconciliation and duplicate checks after each major object.
6. Ask business testers to validate real process paths.
7. Remove migration permissions, bypass flags, and temporary credentials after signoff.

Official Salesforce references for migration teams

Use official documentation when you decide Salesforce data migration tool limits, API behavior, and security patterns. Start with Salesforce Help for Data Import Wizard, Salesforce Help for Data Loader, the Developer Guide for Bulk API 2.0 ingest jobs, and the REST API guide for upsert by external ID.

Frequently Asked Questions