A few months ago we were helping a logistics company migrate their sales data into Salesforce from an old CRM. The admin assigned to the project had used the Data Import Wizard before — comfortable with it, no installation headaches, clean browser UI. Everything was going fine until they hit the Opportunities. Three thousand rows of pipeline data, perfectly formatted CSV, and the wizard simply would not let them proceed. Two days later, after a lot of confused back-and-forth, the answer was straightforward: the Data Import Wizard does not support Opportunities. Never has. Data Loader was the right tool from the start.
We tell that story at the beginning of every data migration kickoff we run, because it captures the exact mistake that catches people. Salesforce ships two native import tools and they look similar enough that it's easy to assume they're interchangeable. They are not. The object support, volume limits, and available operations are fundamentally different, and choosing based on familiarity rather than fit will cost you time.
The Import Wizard: fast, browser-based, limited scope
The Data Import Wizard lives in Setup under Data > Data Import Wizard and requires nothing beyond a browser. For non-technical admins or for anyone who can't install desktop software, this is a genuine advantage. You upload a CSV, map fields, choose how to handle duplicates, and it runs.
The objects it supports are: Accounts, Contacts, Leads, Solutions, Campaign Members, and custom objects. That's the full list. If you need to import Opportunities, Cases, Tasks, or Events — you need a different tool. In our experience, Opportunities is by far the most common trap. Nearly every sales-data migration involves Opportunities, and nearly every admin who hasn't hit this wall before assumes the wizard handles them.
For the objects it does support, the wizard gives you Insert and Update operations, and it has decent built-in duplicate detection. For Contacts and Leads it can match on email or name, and when it finds a duplicate it asks you whether to skip the record, create a new one anyway, or update the existing one. For a one-off import of leads from a trade show, or cleaning up an Account list from an acquisition, this is entirely sufficient and much faster to set up than Data Loader.
The hard ceiling is 50,000 records per import file. If your CSV has 80,000 rows you'll need to split it, which is annoying but manageable for a one-time job. For anything recurring or high-volume, the wizard isn't the right tool regardless of which objects you're working with.
Data Loader: the serious tool for serious jobs
Data Loader is a desktop application — you download it from Setup under Integrations > Data Loader, install it on Windows or Mac, and authenticate via OAuth or username-password. That extra setup step puts some admins off, but the capability gap more than justifies it once you're past the initial install.
The most important thing to understand about Data Loader is that it supports every Salesforce object. Every standard object, every custom object, every platform object. Opportunities, Cases, Tasks, Events, Attachments — all of it. When a client comes to us with a migration that touches anything beyond the wizard's narrow object list, we go straight to Data Loader.
The operation set is also far broader. You get Insert (create new records), Update (modify existing records by matching on a Salesforce ID or external ID), Delete, Hard Delete (permanent deletion that bypasses the Recycle Bin, which requires the Bulk API Hard Delete permission), Export via SOQL query, and Export All which pulls records from the Recycle Bin as well. And then there's Upsert, which is the feature we reach for most often on integration work.
For volume, Data Loader handles up to five million records per operation, using the Bulk API under the hood for large batches so records are processed asynchronously. On a migration we did for a financial services firm with around 400,000 historical Account records, Data Loader ran overnight without issue. That job would have required eight-plus manual splits with the wizard.
Why Upsert changes everything for ongoing syncs
Upsert is probably the single most important reason to use Data Loader over the Import Wizard on any project that involves ongoing data synchronisation rather than a one-time import.
The mechanism works through External ID fields — custom fields on your Salesforce objects that you flag as External IDs in the field settings. These fields hold identifiers from your external system: an ERP account ID, a legacy CRM record ID, whatever uniquely identifies the record in the system you're syncing from.
When you run an Upsert in Data Loader, it reads the External ID on each incoming row and checks whether a record with that value already exists in Salesforce. If it does, the record is updated. If it doesn't, a new record is inserted. One operation, one file, no pre-processing required.
Without Upsert, a daily sync becomes genuinely awkward. An Insert run will create duplicate records for anything that already exists. An Update run will fail or silently skip any records that are new. You'd have to pre-process the incoming file to split it into "new records" and "existing records" before every run — which is error-prone and time-consuming. We've seen this done manually on projects before we got involved, and it always creates problems eventually.
We always set up External ID fields during the initial data modelling phase on any project that will have external system integrations, specifically because Upsert becomes so much cleaner when they're in place from the start. Retrofitting them later is possible but requires an Update run to backfill the values before Upsert will work correctly.
When native tools aren't enough
Both tools have their ceiling. The Import Wizard can't be scheduled and has no CLI. Data Loader does have a command-line interface that enables automation — you can write a batch script that runs a nightly Upsert from a staged CSV file — but it requires setup work and some technical comfort with configuration files and scripting.
For production-grade recurring pipelines, we usually recommend evaluating third-party tools like Dataloader.io or Jitterbit. These add browser-based scheduling, visual field mapping with transformation logic, error dashboards that flag failed records without stopping the whole job, and in some cases direct API-to-API integration that doesn't require intermediate CSV files at all. The trade-off is licensing cost and another vendor to manage.
Our rule of thumb: for a one-time migration or an occasional cleanup, native tools are fine and we use them without hesitation. For anything that needs to run on a schedule, handle large volumes reliably, or feed from a live system rather than a file, we have the third-party tool conversation early in the project rather than after the first production incident.
How we approach this on every project
Before any data migration or integration engagement, we run through a short checklist: Which objects are involved? What volume are we expecting? Is this a one-time import or an ongoing sync? Does the incoming data need matching against existing records, and if so on what field?
If the answers point to objects outside the wizard's list, volumes above 50,000, Upsert requirements, or anything automated — we open Data Loader. If it's a straightforward one-off load of Leads or Contacts under 50,000 records and the admin is comfortable in the browser, the Import Wizard is faster to get running and perfectly appropriate.
The mistake we see most often is choosing based on familiarity — the Import Wizard feels easier so people reach for it first and discover its limits mid-migration. Two minutes spent checking the object support list before you start will save you the two days our logistics client lost. We always check first.
