Throughset

Insights

How to merge two Salesforce orgs after an acquisition

Merging two Salesforce orgs is a design and data project with a tooling problem inside it. The tools move metadata and records, but they cannot tell you which org survives, which fields mean the same thing, or which duplicates are the same customer.

This guide puts the decisions first, then the mechanics. It covers data and metadata. It does not cover users and single sign-on, sharing design, integrations or privacy obligations in a merger, so plan those separately. We did not find a Salesforce page describing a native tool for merging two production orgs, and we have not assessed third-party tools. Limits quoted here were read on 28 October 2026 and can change.

Decide before you touch a tool

Settle these four things first, in writing, with one named owner for each.

  1. Merge at all, or run two orgs. A 2014 Salesforce Developers blog post lists reasons to keep orgs separate: a diversified business model, regulated data that needs a walled garden, or org limits. It also says that stakeholder impatience is not a good reason to split. The post predates most of today's tooling and does not mention acquisitions, so treat it as a prompt for the conversation, not an answer.
  2. Which org survives. In our view, choose on data model fit, the quality of the automation you want to keep, the integrations already in place, edition and contract dates, and the number of users. The surviving org need not be the larger one. A third, clean org that both move into is possible, at greater cost and effort.
  3. What stays behind. Old reports, unused fields, dead automation and records nobody has touched in years should be retired in the source org, or not moved. Every item you carry across is an item you test, secure and explain later.
  4. Who owns each object. One person decides what an Account, an Opportunity or a Product means in the merged org.

One note on terms. Searches for "instance consolidation" return Salesforce documents about its own infrastructure, where it adds customer orgs to an existing instance. That is a different operation from merging two companies' orgs.

Map the two data models

Two companies rarely describe a customer the same way. This part is our method, not Salesforce's. For each object, build a sheet with these columns: source field, target field, type, picklist value map, transformation, and owner. Add a user map for record owners, so that each old owner points to a person in the surviving org.

Then list the metadata that exists in both orgs under the same name, such as an object, a flow or a profile. Decide which one survives, or rename one, before you deploy anything.

Move metadata, and not with change sets

Change sets carry setup metadata only. Salesforce's page says they do not contain records, and that you cannot create deployment connections between arbitrary orgs. Connections exist between a production org and its own sandboxes. So two companies' production orgs cannot exchange change sets.

The options Salesforce documents for moving metadata between orgs that have no source tracking are the Salesforce CLI, which retrieves and then deploys, and unlocked packages, which hold metadata you can roll out to several orgs. For most merges, we would retrieve with the CLI and compare the two orgs' metadata side by side. Salesforce says DevOps Center is being renamed Lifecycle Center from October 2026, and that the managed-package version stays supported. We found nothing saying that it moves metadata between two companies' production orgs.

Two cautions from Salesforce's pages. Profiles in a change set need another component alongside them, and Salesforce says change sets are not designed to update profile settings, so verify permissions after any deployment. And check users, connected apps and picklist values against the current documentation for your case, because we could not confirm from a Salesforce page whether they can be deployed.

Choose the loader

The Data Import Wizard loads up to 50,000 records at a time from a file up to 100 MB, and cannot import opportunities, cases, products and several other objects. For an org merge, use Data Loader. Salesforce recommends the Bulk API for sets of 10,000 or more records, though it is a recommendation, not a hard limit.

Build the ID crosswalk

Records you load into the surviving org receive new Salesforce IDs. Anything that pointed to the old ID, such as a child record, a file link, an integration or a report filter, needs a way to find the new one.

Add a Unique External ID field to each object you migrate, and store the old ID in it with a prefix for the source org, such as A- or B-, so that two orgs cannot clash. Salesforce describes loading related records by external ID instead of by Salesforce record ID. The steps are:

  1. Mark the parent object's field External ID and Unique.
  2. Repeat the parent's external ID value in the child file.
  3. Map that column in the upsert.

Data Loader can upsert on a Salesforce ID or an external ID.

Keep the crosswalk, a table of old ID to new ID per object, outside any sandbox. Salesforce says sandbox record IDs are copied at refresh and then drift from production, and the sandbox org ID changes on each refresh. A crosswalk that lives only in a sandbox is lost at the next refresh. Load in dependency order: parents before children, users and reference data before the records that use them.

Two accounts for the same company, one in each org, go into a staging file where they match on web domain and one survivor is picked. The surviving org holds one record with a new Salesforce ID. A crosswalk table records that both old IDs, A-0007 and B-0412, point to the new ID.Org A accountAcme Ltd, id A-0007Org B accountAcme Limited, id B-0412Staging fileMatch on web domainPick one survivorSurviving orgAcme Ltd, one recordNew Salesforce IDCrosswalk table: A-0007 and B-0412 both point to the new ID
Keep the old ID of every record you merge or drop. An illustration with made-up values, not a real client.

Deduplicate the load file, not just the org

Two companies often share customers, so plan duplicates as a workstream of their own. Our order is:

  1. Choose match keys, such as email address, web domain, or company name plus postcode.
  2. Deduplicate the staging file before you load.
  3. Pick the surviving record in each cluster by a stated rule, such as most recently active or most complete.
  4. Keep the losing record's old ID in the crosswalk so that nothing is orphaned.

Three Salesforce limits shape this:

  • A merge handles at most three records of the same type at a time, so a cluster of ten needs several passes.
  • Duplicate rules compare saved records with records already in Salesforce. Records saved together are not compared with each other, so duplicates inside your own load file slip through.
  • Duplicate rules do not run on manual merges, on lead conversion without Apex Lead Convert, or on undelete. An active duplicate or matching rule can fail an import row, and Salesforce advises against deactivating them.

Leads and contacts cannot be merged directly with each other, so decide which each record is before you load.

Plan files as their own workstream

Files are not an attachment to a record. Salesforce describes a ContentDocument as the parent of a ContentVersion and its ContentDocumentLink records, and inserting a version creates the parent and a link automatically. Bulk loading means two Data Loader passes, ContentVersion first and ContentDocumentLink second, using the new document IDs. Salesforce recommends a batch size of one and notes that base64 encoding adds about 30 percent to file size. Allow time for this, and rehearse it separately from the record load.

Rehearse in a Full sandbox

A Full sandbox is a copy of production including its data, so it is the sandbox type closest to a real load. Salesforce notes that it has a long refresh interval, which is why it is awkward for day-to-day development. Check whether your edition includes one, and plan your rehearsal calendar around its refresh.

The loop is our own design, not Salesforce's:

  1. Load into a refreshed Full sandbox of the surviving org.
  2. Record the time for each object, the error count and the cause of each error.
  3. Check a sample against both source orgs: a count of records, a count of files, and ten records chosen by the business.
  4. Fix the load files and automation, refresh, and run again.
  5. Agree a go or no-go rule in advance with each object owner, such as an error limit per object and a business sign-off, and stop when you meet it.

Run it more than once. Each run shows what the previous one missed, and the last run gives you an estimate of the cutover time.

Cutover

Agree a freeze window in both source orgs, then work through this list in the order you rehearsed:

  1. Freeze changes in both source orgs.
  2. Load metadata, then reference data, then records, then files.
  3. Repoint integrations and single sign-on.
  4. Check counts against the rehearsal and get each owner's sign-off.
  5. Tell users what changed.

Decide before you start what would make you stop and go back. Keep the source orgs, read only, for a set period after cutover, and ask your Salesforce account team what that costs in licences. Salesforce's pages we checked do not describe an undo for a completed record merge, so do not rely on one. Your way back is the source org and your crosswalk.

Where we fit

We do not run the data load. The Org Review shows what in each org should be fixed or left behind before you combine them.

The Org Review is our fixed-fee review of your Salesforce setup, from USD 3,500. It gives you a costed list of what needs fixing, what it costs to leave it and what the fix takes. You keep the findings whether or not you hire us for the work.

If you would like to talk it through, book a free twenty-minute call.

Sources

Statements about Salesforce in this guide were checked against these pages on 28 October 2026.

Related guides

Last reviewed 28 October 2026. Throughset.

Start with the Org Review, not a contract

A fixed fee from USD 3,500, ending in a costed fix list you own outright. Book a free twenty-minute call about your merger.

Talk to us → How the Org Review works