Salesforce data migration, reconciled row by row
We move records into Salesforce from no-code tools, other CRMs and other Salesforce orgs, and we prove the counts match before anyone switches the old system off.
Four kinds of migration we are asked for
The source changes. The risk is always the same one: records that arrive but no longer mean what they meant.
Off a no-code tool
Apps built in QuickBase or Kissflow hold years of records in a shape that made sense to whoever built them. We have moved both onto Salesforce, and the work is mostly deciding what each table really is before any row moves.
Another CRM, or another org
HubSpot, Zoho, Dynamics, or a second Salesforce org left over from an acquisition. Same job underneath: map objects and owners, keep the history that matters, and drop the duplicates on the way in rather than after.
Bulk jobs inside a live org
Not every migration is a launch. Backfilling thousands of leads, moving records between objects, or pulling a large email set out for another system all need the same care, because users are working in the org while it runs.
Data that carries a legal duty
Consent and do-not-call flags have to arrive intact. We treat suppression fields as the first thing to test, not the last.
The order we do it in
Nothing touches production until a full trial load has reconciled in a sandbox.
- 01
Inventory the source
Every table, field and attachment, with a row count and a note on who still uses it. Fields nobody has filled in years are flagged so you can decide to leave them behind.
- 02
Map to the Salesforce data model
Source fields to standard and custom objects, picklist values to picklist values, users to owners. Relationships are the hard part, so parent records and their external IDs are planned before anything loads.
- 03
Load into a sandbox first
A full trial run against a sandbox, with record counts reconciled object by object and a sample checked by the people who know the data. Automation that would fire on insert is identified and paused for the load.
- 04
Cut over and reconcile
The production load runs in a planned window, counts are reconciled again, and the source is set read-only rather than deleted, so anything questioned later can be checked against the original.
Migrations are not a side line here
Our invoiced Salesforce work includes moving a business off QuickBase, in more than one phase, and moving another set of processes off Kissflow. Both are no-code platforms where the structure grew one form at a time, so the first job each time was working out which tables were live and which were history.
Inside live orgs we also run the bulk data jobs that keep data useful, as part of the ongoing work we do for a lending company. These are the jobs where a trigger or flow firing on every record can do real damage, so automation is reviewed before the load, not after.
For the mechanics, Salesforce documents its own tools well: the Data Import Wizard, exporting data with Data Loader and the Bulk API 2.0 that large loads run on. Trailhead's importing and exporting data module is a fair introduction if you want to understand the moving parts before you talk to anyone.
The part most plans underestimate is cleanup. Duplicate accounts, contacts with no owner, and picklists with six spellings of the same value all load perfectly well, and then sit in Salesforce making every report wrong. We would rather spend a day agreeing the merge rules with you before the load than a month cleaning up after it.
If the old system has to keep running alongside Salesforce, that is an integration rather than a one-off move; see Salesforce integration. Budgeting for the migration as part of a wider project is covered on what Salesforce implementation costs.
What people ask about moving data
What is Salesforce data migration?
Moving records from somewhere else into Salesforce, or from one Salesforce org into another, so they arrive in the right objects with their relationships, owners and history intact. The copying is the small part. Most of the effort is the mapping before it and the reconciliation after it.
Can I export data from Salesforce?
Yes. Salesforce has a built-in Data Export Service that produces a weekly or monthly set of CSV files, and Data Loader can export any object you have access to on demand. Both are documented in Salesforce's own help. Your data is yours to take out, and a migration plan should include a full export before any load begins, as a backup.
Can you migrate data from one Salesforce org to another?
Yes, and it is more common than people expect, usually after a merger or when a business unit was given its own org years ago. The objects may share names but rarely share fields, picklist values or record IDs, so it is planned the same way as any other migration, with external IDs used to rebuild the relationships.
Which tools are used for Salesforce data migration?
For small, simple loads Salesforce's Data Import Wizard is enough. For larger volumes or objects the wizard does not support, Data Loader, which can use Salesforce's Bulk API for large volumes. We pick by the size and shape of the data, not by a favourite tool, and the choice matters less than the mapping and testing around it.
Other Salesforce work
Tell us what you are moving
Name the source system and roughly how much is in it. We will tell you what we would check first, and the one-week org review is free if the data is already in Salesforce.