Best Practices of Data Migration to Salesforce
A Salesforce go-live is only as good as the data you bring into it. Most migration problems, like broken relationships, duplicates and missing records, come from skipping the planning, not from the load itself. Hereβs how we plan and run migrations so they land cleanly the first time.
When you need a Salesforce data migration
Most projects fall into one of these situations:
Replacing an old CRMMoving off an outdated system like HubSpot, Zoho, Podio or a home-grown database.
Consolidating systemsBringing data from several separate tools into one Salesforce org.
Adding new capabilitiesMoving data in to use features your current system doesnβt offer.
Connecting other systemsBringing data from a database, app or storage system that works alongside Salesforce.
Merging orgsCombining two Salesforce orgs after an acquisition or merger.
Splitting an orgBreaking one Salesforce org into several, for example when a business unit is sold.
The five phases of a migration
Every migration we run follows the same path. Skipping a phase is where most of the rework comes from.
Phase 1
Access your data sources
- Get access to every source: the existing database, system or cloud app.
- Check how data can come out: a built-in export, an API, or direct database access.
- Review the data with the business and agree what moves and what gets left behind.
Phase 2
Design the migration
- Agree on filters and expectations in writing, such as βonly active accountsβ or βopportunities from the last five years.β
- Assess data types, volumes, objects and fields.
- Flag risks early, including Salesforce governor limits, storage limits and automation that fires on insert.
- Design the extract, transform and load (ETL) approach.
- Plan the delta migration for records that change between the main load and go-live.
Phase 3
Build the solution
- Set up the metadata and users in the target org before loading anything.
- Break the data into categories and build the load for each one separately.
- Install or set up the tools from your design, like Data Loader, dataloader.io, SFDMU or custom Python or Node scripts.
- Test each piece as you go, so problems surface early instead of on cutover day.
Phase 4
Load the data
- Run a small sample first, check it, then move to the full load.
- Do a full dry run in a sandbox before touching production.
- Split the migration into smaller batches and work through them one at a time.
Phase 5
Review data quality
- Audit the migrated data for accuracy.
- Write validation test cases and run them.
- Note any cleanup or enrichment needed before users rely on the data day to day.
Best practices during the migration
1. Decide exactly what to migrate
- Choose which objects to bring over.
- Be specific. For example, migrate only Contacts for each Account, or only Accounts from one division.
- Leave junk behind. A migration is the cheapest time to drop duplicates and stale records.
2. Create templates for each object
- Export each object with Data Loader and use that file as your template. See Insert, Update, or Delete Data Using Data Loader.
- Identify required fields and relationships, because they set the load order. See Considerations for Relationships.
- Load parents before children. The order below works for most Sales Cloud orgs.
Typical load order. Users come first because they own records. Custom objects slot in after the records they look up to.
3. Populate templates carefully
- Clean and review the data before it goes into the template.
- Load one record, check the result, then load the rest.
4. Prepare the destination org
- Create a custom field on each object to store the legacy ID from the old system. See Create Custom Fields.
- Mark that field as an External ID so itβs indexed. You can then upsert and link related records by legacy ID instead of mapping Salesforce IDs by hand. See Can I import using external IDs?
- Create custom fields for any non-standard data youβre keeping. For example, if the old system stored Home Phone on Users, add that field in the new org.
- Temporarily switch off validation rules, flows, triggers and email alerts that would block the load or email customers by mistake. Turn them back on right after.
5. Validate the data
- Build reports to compare record counts with the source and get an overall view of the migration. See Build a Report in Lightning Experience.
- Spot check individual records against the source, especially ones with lots of related data.
- Review the error files from every load to see what didnβt make it in and why.
Choosing a migration tool
The right tool depends on volume, how complex the relationships are and how often youβll need to rerun the load.
| Tool | Best for | Keep in mind |
|---|---|---|
| Data Import Wizard | Small, simple loads of standard objects like Accounts, Contacts and Leads | Built into Setup and easy to use, but limited to 50,000 records per import |
| Data Loader | Larger loads and most objects, including inserts, updates, upserts and deletes | Free desktop app. Use the Bulk API setting for high volumes |
| dataloader.io | Teams that want a browser-based tool with scheduling | Free tier has limits. Paid plans add more volume and automation |
| SFDMU | Org-to-org moves, sandbox seeding and complex related data | Free Salesforce CLI plugin that handles relationships and load order for you |
| Custom scripts (Python, Node) | Heavy transformations, unusual sources or repeatable pipelines | Most flexible, but needs developers to build and maintain |
Migration checklist
- Access to every data source confirmed
- Scope and filters agreed in writing
- Metadata and users set up in the target org
- Legacy ID External ID fields created
- Load order mapped from object relationships
- Automation and validation rules paused
- Sample load tested and checked
- Full dry run done in a sandbox
- Production load completed in batches
- Record counts and spot checks match the source
- Error files reviewed and fixed
- Automation turned back on and delta load planned
Planning a migration to Salesforce?
Weβve moved data from HubSpot, Podio, Freshdesk and more. Email migration@tenetizer.com or reach out below.