For most Salesforce data migrations the short answer is two tools from Salesforce itself. The Data Import Wizard handles first loads of accounts, contacts and leads under 50,000 records per file, and Data Loader handles everything else, opportunities included, at volume. Org to org moves suit the open source SFDX Data Move Utility, and ongoing syncs from other systems suit an ETL platform.
What none of them does is decide which of your source records are the same customer. Every loader copies the CSV it is given. If the legacy CRM has Granite Ridge Construction LLC and Granite Ridge Construction as two accounts, Salesforce gets two accounts. That step sits before the tool choice, and it is the one that decides whether the record counts hold up at sign off.
Which tool is best for Salesforce data migration?
| Tool | Best for | Volume | Matching on load |
|---|---|---|---|
| Data Import Wizard | Accounts, contacts, leads, campaign members | Under 50,000 per file | Name or email; accounts on name and site |
| Data Loader | Any object, opportunities included | Documented to 5 million | None on insert; ID or External ID on upsert |
| dataloader.io | Browser loads and scheduled jobs | Depends on plan | Insert, update or upsert on a key you pick |
| SFDX Data Move Utility | Org to org, related objects in one run | Large | External ID fields you configure |
| ETL platforms | Ongoing syncs and heavy transforms | Large | Rules you build in the platform |
Jitterbit Data Loader, long the free alternative, was retired in November 2025 and is no longer offered to new users.
Pick by the hardest object in the job, not the easiest. A migration that is only contacts and accounts under 50,000 rows can run entirely in the wizard. The moment opportunities, cases or custom objects with lookups are in scope, Data Loader or something built on the API does the loading, and the wizard is at most a convenience for the first object.
Data Loader or Data Import Wizard for a migration
The Data Import Wizard runs inside Setup, needs no install, and Salesforce recommends it for loads under 50,000 records. It supports a limited set of objects, and opportunities are not among them. Its useful trick is matching: contacts and leads can be matched to existing records on name or email, and accounts on account name and site together, so a second file can update instead of duplicate.
Data Loader is a desktop client, available in Enterprise, Performance, Unlimited and Developer editions, and Salesforce documents it for loads of up to 5 million records. It loads any object and runs from the command line for repeatable jobs. On a plain insert it matches nothing, so every row becomes a new record. On an upsert it matches on the Salesforce ID or an External ID field, which is why a migration should carry the legacy system key into an External ID field from the first load.
Is Salesforce Data Loader free?
Yes. Data Loader is included with the Salesforce editions that support it, at no extra charge, and so is the Data Import Wizard. The cost of a migration is rarely the loader. It is the admin or partner hours spent mapping fields, ordering loads so children find their parents, and fixing the records that should never have been loaded twice.
When a paid Salesforce migration tool earns its keep
Browser loaders such as dataloader.io from MuleSoft help teams that cannot install a desktop client or want scheduled imports from cloud storage. SFDMU, a free plugin for the Salesforce CLI with a desktop app, earns its place on org to org work: it moves many related objects in one run, keeps the relationships, and can migrate attachments and files. ETL platforms such as Informatica, MuleSoft, Talend and Skyvia are worth the contract when the migration is really an integration, with a source that keeps changing and transformations that have to run every night.
If the legacy system has no usable export at all, an old web portal for instance, a web scraping API can turn its screens into structured rows before any of these loaders sees them. The cleanup step itself, whatever the target system, is covered on our data migration cleansing software page.
Do Salesforce data migration tools remove duplicates?
No, not in the way a migration needs. The wizard can match an incoming row to a record already in Salesforce, and duplicate rules can block or alert. Neither looks inside your source file and decides that two of its rows are one customer. Rules set to Allow with an alert save the row anyway in a bulk load, because the alert is a screen in the Salesforce interface. Whatever is duplicated in the CSV is duplicated in the org.
After go live the fix is slower. Salesforce merges at most three records at a time and a merge cannot be undone, as set out on Salesforce merge accounts and Salesforce merge contacts. On the export, a duplicate is a row you drop.
What a cleanup pass found on a legacy accounts export
We ran a twelve row accounts file from a legacy CRM through our engine, with a Legacy ID, website, phone and billing address. These are the real results, misses included.
| Legacy account | Second record | Result | Before the load |
|---|---|---|---|
| Granite Ridge Construction LLC | Granite Ridge Construction | Same company name | Merge, keep A-1001 |
| Copperline Software Corp | Copperline Software Corporation | Same company name | Merge, keep A-1009 |
| Meridian Foods, Chicago | Meridian Foods, Columbus | Grouped, flagged for addresses | Read it, may be two branches |
| Bluewater Marine Supply Inc | Blue Water Marine Supply | Not matched | Check by eye |
| Hollis & Grant Advisors | Hollis and Grant Advisors | Not matched | Check by eye |
| Northstar Pediatrics PC | Northstar Pediatrics | Not matched | Check by eye |
The same run turned colorado, florida, massachusetts and the other state names into two letter codes and repaired the Boston ZIP 2109 to 02109.
Three groups out of six real pairs is an honest result for a file like this. The engine sets aside Inc, LLC and Corp, so those pairs collapse, and it flags the Meridian pair instead of merging it because the addresses disagree. It does not yet treat a space inside a name, an ampersand against and, or the PC suffix as equal, so sort the account file by name and read the neighbors. The matching is the same data deduplication engine used across the site, with fuzzy matching for close spellings of people.
How to clean source data before the Salesforce load
- 1 Export accounts, contacts and leads from the legacy system as CSV, with the legacy record ID in every file. Use plain headers: Owner rather than Account Owner or Contact Owner.
- 2 Load each file into the data cleaning demo. It runs in your browser, so the customer list never leaves your machine.
- 3 Read every proposed group. Each says why it matched, and conflicts such as owner or address are shown before you approve anything.
- 4 Export the cleaned file and the audit log, which lists every legacy ID that folds into another. That is the answer when someone asks why 41,000 accounts became 38,600.
- 5 Load with the tool that fits the object, accounts first, then contacts and leads, then opportunities, with the legacy ID in an External ID field so every reload is an upsert.
Who pays for the cleanup step
The person who signs off the migration: a RevOps lead, a Salesforce admin or a partner project manager with a cutover date, who has to defend the record counts to sales and finance. The loaders are free and the partner hours are not, so a few hours of matching on the export is the cheapest insurance in the project. Source specific guides cover Zoho to Salesforce migration and HubSpot to Salesforce migration.
DataUntangler is a data cleaning tool on the Analyst plan at 59 dollars a month, or 348 dollars a year, with unlimited files up to about 100,000 rows each. It does not connect to Salesforce or the legacy system and writes nothing to either. You review the groups, export the clean file, and load it with whichever tool above fits the job.