Salesforce Migration: Data Import Wizard, Data Loader, Bulk API 2.0 or ETL?

Salesforce documentation lists five different ways to import data. The challenge is not finding them — it's knowing which one to pick based on volume, available technical expertise, and desired automation level. This guide covers all five tools with their decision matrix, real limitations, and the configurations that make the difference.

The Five Salesforce Migration Tools

• Data Import Wizard: native graphical tool in Salesforce Setup. Supports standard objects (Contacts, Leads, Accounts, Opportunities, Campaign Members). Limit: 50,000 records per batch. No technical skills required.
• Data Loader: desktop application (Windows / macOS). Supports all objects, including custom objects. Recommended for 5,000 to 5 million records. Can run in Bulk API mode for large volumes.
• Bulk API 2.0: Salesforce asynchronous REST API for high-volume operations. Processes data in batches, optimized for mass inserts/updates without saturating synchronous API limits. Accessible via Data Loader, Salesforce CLI, or any HTTP client.
• Salesforce CLI (sf): official Salesforce command line. The sf data upsert bulk command runs Bulk API 2.0 operations directly from a terminal or CI/CD pipeline. Ideal for automating a repeatable migration.
• ETL / iPaaS (MuleSoft, Informatica, Talend): solution for complex migrations involving multiple source systems, significant transformations, or ongoing post-migration sync.

Decision Matrix

• Volume < 50k, standard objects, no technical skills → Data Import Wizard
• Volume 50k–5M, all objects, Salesforce admin → Data Loader (Bulk mode)
• Volume > 1M, automation required, CI/CD pipeline → Bulk API 2.0 via Salesforce CLI
• Multiple sources, complex transformations, integration budget → ETL / MuleSoft
• Org-to-org migration (config + data) → Metadata API + Data Loader combined

Data Loader in Bulk API Mode

By default, Data Loader uses the standard REST API (200 records per batch). For large migrations, enable Bulk API mode in Data Loader settings. In Bulk mode, Data Loader sends data in asynchronous batches of thousands of records, significantly reducing migration time and daily API limit consumption.

Key setting: Data Loader Settings → Use Bulk API. Important note: Bulk API does not fire Apex triggers or complex validation rules by default. If your org has critical triggers (deduplication, auto-calculations, third-party syncs), testing in sandbox with a representative dataset is mandatory before production migration.

Salesforce CLI and Bulk API 2.0

The Salesforce CLI command for a upsert migration via Bulk API 2.0:

• sf data upsert bulk --sobject Account --file accounts.csv --external-id External_ID__c --wait 10
• --sobject: target Salesforce object (Account, Contact, Opportunity, or any custom object)
• --file: source CSV file (UTF-8 encoding required)
• --external-id: the field marked External ID for upsert operation (insert if absent, update if present)
• --wait: wait time in minutes before timeout (set to 0 for async mode with manual polling)

The upsert operation is fundamental for migrations: it checks whether a record with this External ID already exists in Salesforce. If yes: update. If no: create. This makes the migration idempotent — running the command twice does not create duplicates.

External ID: The Key Concept

An External ID is a custom field marked as such in Salesforce (check 'External ID' in the field definition). It stores the record identifier from the source system (ERP customer ID, legacy CRM contact ID, etc.). Three critical uses during a migration:

• Upsert without duplicates: Salesforce knows whether the record needs to be created or updated.
• Relationship reconstruction: when importing Contacts, you can reference the parent Account via its External ID instead of its Salesforce ID (which doesn't exist yet during the first migration pass).
• Post-migration traceability: keeping the legacy_id in an External ID field makes it easy to trace back to the original record in case of question or dispute.

Salesforce Object Migration Order

Import order matters as much as method. Salesforce cannot attach a Contact to an Account that doesn't exist yet.

• 1. Users (or mapping to existing owners)
• 2. Accounts
• 3. Contacts
• 4. Leads (if separate from Contacts)
• 5. Opportunities
• 6. Opportunity Products (OpportunityLineItem)
• 7. Cases and Service Cloud objects
• 8. Activities (Tasks, Events) — always last because they attach to almost every object

Reconciliation After Salesforce Migration

After import, don't just verify that total row counts match. Also validate: all Contacts have an AccountId set (no orphan contacts), all Opportunities have a valid StageName and AccountId, OwnerId fields point to active users, Amount and CloseDate fields are in consistent ranges, records rejected by Bulk API have been analyzed and addressed.

For org-to-org Salesforce migrations with relationship and metadata preservation, see: Migrating to Salesforce — How to Preserve IDs, Relationships and Metadata