Salesforce Org Consolidation After a Merger

Salesforce org consolidation means merging two or more Salesforce orgs, usually after an acquisition, so the business runs on fewer of them. Salesforce's own guidance is that a highly unified business should have as few orgs as possible, while a business whose units run separately can justify several. You now have a middle option too: keep the orgs and unify the data layer with Data 360, so a full merge can wait until it's worth doing.

Should you merge Salesforce orgs after an acquisition?

Not automatically. An acquisition hands you a second Salesforce org, with its own objects, automation, integrations and admin habits. The instinct is to merge them straight away. Sometimes that's right, and sometimes it's an expensive way to force two businesses to work alike when they don't.

The deciding question is how the combined company intends to operate. Salesforce's long-standing multi-org guidance, a 2014 developer blog on enterprise architecture that is still the standard reference, borrows the MIT CISR operating-model quadrants:

Unification: shared customers and shared processes. Salesforce's advice is as few orgs as possible.
Replication: the same processes run by largely separate units. Several orgs connected by shared packages can work.
Coordination and diversification sit between and beyond those two, and the right answer there depends on how much the units actually share.

If the acquired company will sell to the same customers, through the same team, on the same process, you're in unification territory and consolidation is probably worth it. If it will keep its own brand, customers and sales motion, the case is weaker.

What does Salesforce recommend on multi-org strategy?

Salesforce's current architecture guidance points the same way. Its Well-Architected framework treats multiple orgs as something to keep only for hard requirements, such as localization or contractual isolation, and asks you to weigh that isolation against the extra governance load that every additional org brings.

Its Data 360 provisioning decision guide adds a newer point: think enterprise-wide, not org by org. Multi-org customers should keep the number of Data 360 instances to a minimum, ideally using Data Cloud One. Data Cloud One, generally available since October 2024, lets several Salesforce orgs share one Data 360 "home org," with three companion connections included.

That matters for anyone planning Agentforce, because Agentforce depends on Data 360. Two orgs with two separate data layers means two versions of the customer for an agent to reason about.

What are the options for Salesforce org consolidation?

There are three realistic approaches, and they aren't mutually exclusive over time.

Approach	What it involves	When it fits
Merge into one org	Migrate data, automation and users into a single org, then retire the other	Unified businesses with shared customers and processes
Keep several orgs, connect them	Integration, often through MuleSoft, passes records and events between orgs	Separate processes that still share some customers or data
Keep several orgs, unify the data layer	Data 360 with Data Cloud One gives one view of the customer across orgs	When a merge is right eventually but can't happen yet

The third option is the one most often missed. It buys time: reporting and AI get a single customer view now, and the full merge can be scheduled when budgets and the business are ready.

What are the steps in a Salesforce org merge?

If you decide to consolidate, the work usually runs in this order:

Inventory both orgs. Objects, fields, record types, validation rules, flows, code, integrations, licenses and who actually uses what.
Choose the target org. Often the larger or cleaner one, but pick on data model fit, not size.
Design the combined data model. Decide which definitions win where the two orgs disagree, and write the mapping down.
Deduplicate before you move. Two companies that sold into the same market will share accounts and contacts.
Rebuild automation deliberately. Don't copy both sets of flows and rules across and hope they coexist.
Re-point integrations. ERP, marketing and anything else connected to the retiring org.
Migrate in rehearsals. Test loads in a sandbox until record counts and relationships reconcile.
Cut over, then retire. Freeze the old org, move the final delta, train users, and shut it down so licenses stop multiplying.

What goes wrong in Salesforce org consolidation?

Partner and vendor write-ups, including Gearset's and Traction Complete's merge guides, list the same risks again and again:

Duplicate records that multiply rather than merge.
Broken record IDs and relationships. Record IDs and the relationships that depend on them can break when data moves between orgs, so lookups and related records have to be remapped and checked.
Clashing data models, validation rules and automation that fire in ways neither team expected.
Integrations to ERP and marketing systems that must be re-pointed and retested.
License overlap while both orgs are live.

On timing, full merges are often quoted at 12 to 18 months in those partner write-ups. Treat that as anecdote, not a benchmark. The real driver is how different the two orgs are, and you won't know that until the inventory is done.

How should you decide?

Start with the operating model, not the technology:

Will the combined business share customers and processes? If yes, plan for one org.
Are there hard localization or contractual reasons to keep separation? If yes, keep them separate and connect them.
Is a merge right but not affordable this year? Unify the data layer first and schedule the merge.

Then do the inventory before anyone quotes a timeline for Salesforce org consolidation. It is one of the services MSquare Technology, our certified Salesforce partner, delivers: merging, retiring and migrating orgs so admin effort and licensing stop multiplying. There's more on how that engagement runs on our Salesforce and AI page, and on how we work with partners and with you.

Running short of space? The free Salesforce data storage calculator shows what each org uses against its allowance, and how long until it's full.

Salesforce org consolidation after a merger: one org or several?