Salesforce to Salesforce Data Migration: 5 Steps, No CSVs

To migrate data from one Salesforce org to another, you can skip the CSV step entirely. Connect both orgs to a migration tool, choose the parent and child objects you want to move, and let the tool link each child record to its new parent in the target org. Record IDs change in every org-to-org move, so the hard part is rebuilding lookups such as Contact.AccountId against the new IDs. That is the job a CSV export and a spreadsheet of VLOOKUPs usually ends up doing by hand.

With the Dataimporter Salesforce to Salesforce migration tool, the short version is:

1. Connect the source and target orgs. Log in to each one with OAuth. Production and sandbox orgs both work.
2. Build a Migration Template. Add parent objects such as Account, then their related objects such as Contact and Case.
3. Map objects and fields. Where object names match, Dataimporter fills in the object and field mapping. Lookups between objects in the template are linked with Magic ID.
4. Preview and run a sample migration into a sandbox. Check the records, then fix mappings and filters.
5. Back up the target, then run the same template for cutover. Compare record counts and retry any failed records.

The numbered sections below cover each step, plus Files, audit fields and rollback. Before cutover, also run through our Salesforce data migration checklist.

1. What changes when data moves between Salesforce orgs

A Salesforce to Salesforce data migration looks simple because both sides share the same platform. These are the things that still catch people out:

• Record IDs: every record gets a new Id in the target org. Any lookup that stores an ID, such as AccountId, WhoId, WhatId or a custom Parent_Account__c, has to be rebuilt against the new IDs.
• Owners: OwnerId points at a user in the source org. Users need to exist in the target first, and you match them on something both orgs share, such as Username or Email.
• Record types and picklists: RecordTypeId values differ between orgs, and picklist values may have been renamed. Map record types by DeveloperName and translate picklist values on the way in.
• Audit fields: CreatedDate, CreatedById, LastModifiedDate and LastModifiedById are set to the loading user and the time of the load unless the target org has Set Audit Fields upon Record Creation enabled. See importing audit fields.
• Schema differences: the target org may have different fields, objects or managed packages. Dataimporter lets you migrate from any source object to any target object, so the names do not have to match.
• Automation: flows, triggers and validation rules in the target org run on every inserted record. Decide which ones to pause or allow for before the full run.

2. Connect the source and target orgs

Log in to both orgs from the Instances page using OAuth. The source org is where the data comes from and the target org is where it lands. You can connect production and sandbox orgs, which lets you test the same migration in a sandbox before you point it at production.

Use a dedicated integration user in the target org if you can. It keeps the load separate from real users in field history and makes the records easy to filter on LastModifiedById later.

3. Build a Migration Template for multi-object migrations

A single migrate job moves one object. A Migration Template moves a hierarchy of objects in one run and keeps the relationships between them. To set one up:

• Name the template and pick the source and target instances.
• Add a parent object, such as Account, from the dropdown.
• Expand it to see related objects and the lookup that links them, for example Contact via AccountId and Case via ContactId.
• Choose a batch size, and keep Stop on Failure ticked so the run stops if every record for an object fails.

Objects you add through the related list only include records linked to the parent. To migrate every record of an object, or a subset chosen with a SOQL filter, add it from the dropdown at the top instead. A filter such as RecordType.DeveloperName = 'Business_Account' or CreatedDate = LAST_N_DAYS:365 keeps the run to the records you need.

You can add the same object more than once with different filters or mappings, for example Business Accounts and Person Accounts.

4. Map objects, fields and lookups

The template view shows each source object, its target object, the operation and the run order. Where the object names match in both orgs, Dataimporter completes the object and field mapping for you. For any object without a match, open its mapping and choose the target object and fields by hand.

Lookups are where org-to-org migrations usually go wrong. A common mapping looks like this:

• Account to Account, run first
• Contact to Contact, with AccountId linked to the new Account via Magic ID
• Opportunity to Opportunity, with AccountId linked via Magic ID
• Case to Case, with AccountId and ContactId linked via Magic ID
• OwnerId on each object matched to a target user by Username or Email

Magic ID matches the source and target IDs of the parent records the template created, so each lookup points at the same record it did in the source org. The parent object has to be in the template and has to run before the child. For lookups to records that already exist in the target org, such as users or products, use a key that exists in both orgs, like a name or an External ID field.

5. Clean and transform data on the way in

Fixing data during the migration saves you a second round of updates afterwards. In the job you can:

• Deduplicate rows on the fields that define a duplicate, such as email or name
• Replace null values with a default
• Filter records with SOQL so only the records you need move across
• Use Dataimporter Formulas to translate picklist values, transform record types and populate lookups

If you are merging orgs after an acquisition, deduplicate against records that already exist in the target org as well as within the source data.

6. Preview and run a sample migration in a sandbox

Preview a sample of the records before anything is written. The preview applies your SOQL filters and deduplication rules, so you can check the mapping and formulas on real data.

Then run the template into a sandbox. A sample of a few hundred records per object is usually enough to find mapping problems, missing users and automation that fires when it shouldn't. Have someone who uses the data check it against real tasks. If you need production-like data in a sandbox for development or UAT, see why sandbox seeding matters.

7. Migrating Files, Attachments and emails

Salesforce Files are stored across three objects: ContentDocument, ContentVersion (the file itself) and ContentDocumentLink (which record the file is attached to). To migrate Files, include ContentVersion and ContentDocumentLink in the template. Salesforce creates the ContentDocument automatically when a new ContentVersion is inserted, so you don't add it yourself.

• Files: ContentVersion and ContentDocumentLink
• Legacy attachments: Attachment, linked through ParentId
• Emails: EmailMessage, after the Case or other parent record it belongs to
• Activities: Task and Event, after the records in WhoId and WhatId

Large files need a smaller batch size. Through the Salesforce REST API, a multipart upload can be up to 2 GB for a ContentVersion, but a non-multipart request is limited to 50 MB of text data or 37.5 MB of base64-encoded data, and an sObject Collections request is limited to 500 MB for all files combined. See Salesforce's guide to inserting blob data. Check file storage in the target org as well, since Files count against it.

8. Back up the target org and plan a rollback

Decide how you will undo a run before you start it. The approach depends on what the job did:

• Inserted records: Dataimporter's Rollback button deletes the records an insert job created, including sample runs. It is available for 7 days after the job completes.
• Updated records: you need their values from before the job. Dataimporter Backup snapshots the records a job is about to change, so you can restore only those records.
• Records loaded with another tool: keep the success file, or filter on an External ID field or a CreatedDate window to find them.

For the full process after a bad run, see how to roll back a failed Salesforce import.

9. Cut over and reconcile

When the sandbox run checks out, use the same template for the production cutover:

• Freeze changes in the source org, or agree a cut-off time for a final delta run
• Run the template against the production target org
• Compare record counts per object between source and target
• Review failed records, fix the cause, and use Retry to re-run only those records
• Spot-check a handful of records end to end, including Files and activities
• Migrate permission set assignments if users moved too. See permission set assignment migrations

If the two orgs need to stay aligned during a phased migration, the same mappings can run again on a schedule.

10. Summary

A Salesforce to Salesforce data migration comes down to moving records in parent-to-child order and rebuilding every lookup against the new IDs in the target org. Test the full template in a sandbox, back up the records the run will touch, and keep the success and error results from every run. If your source is a spreadsheet or another system, the process is a CSV or Excel data load instead. To compare tools, see best Salesforce migration tools.

You can try Dataimporter for free and build your first Migration Template, or book a demo to walk through your migration.

Frequently asked questions

How do I migrate data from one Salesforce org to another?

Connect both orgs to a migration tool, add the objects you need in parent-to-child order, map fields and lookups, run a sample migration into a sandbox, then run the same setup for cutover. With Data Loader alone, you export each object to CSV, load parents first, then rebuild each child's lookups against the new IDs before loading it.

Do record IDs stay the same when you migrate between Salesforce orgs?

No. The target org assigns a new ID to every inserted record. To keep relationships, a migration tool maps old IDs to new ones as it goes, or you store the old ID in an External ID field such as Legacy_Id__c and use it to link child records. If you match IDs in Excel, use 18-digit IDs.

Can I keep the original created dates and owners?

Yes. For owners, the users must exist in the target org, and you map OwnerId to them by username or email. For CreatedDate and CreatedById, enable Set Audit Fields upon Record Creation in the target org and give the loading user that permission. Audit fields can only be set when a record is inserted.

How do I migrate Salesforce Files between orgs?

Migrate ContentVersion for the files and ContentDocumentLink to attach them to records, after the parent records are in. ContentDocument is created automatically. Legacy Attachment records migrate as a separate object.

Can I test a Salesforce org-to-org migration first?

Yes. Run the same template into a sandbox with a sample of records, check the results, and fix mappings before the production run. Insert jobs, including sample runs, can be rolled back in Dataimporter for 7 days.

Is the native Salesforce to Salesforce feature a migration tool?

Not really. Salesforce to Salesforce (S2S) is built for sharing records with a partner org on an ongoing basis. It is not designed for bulk migration of full data models with Files, filters and transformations.