- The most common reasons organisations end up with multiple Salesforce orgs
- The three strategic responses to multi-org: merge, federate, or coexist
- The genuine business triggers that justify the expense of an org consolidation
- The cost and risk profile of an org merge — and why it is almost always underestimated
- The cases where maintaining multiple orgs is the correct long-term answer
How Organisations Accumulate Multiple Orgs
Multiple Salesforce orgs are rarely the result of deliberate strategy. They accumulate. A business unit implements Salesforce independently of the central IT function. An acquisition brings in the acquired company's existing Salesforce deployment. A regional team stands up a separate org to avoid the governance overhead of the enterprise programme. A proof-of-concept org drifts into production use.
Within five years of an organisation's first Salesforce deployment, it is common to find three to six active orgs across different functions, geographies, or business units. Each has its own data model, custom code, user base, admin team, and integration landscape. The question of what to do with them eventually surfaces — and the instinctive answer is "we should consolidate."
The instinct is not wrong. Consolidation can deliver real benefits. But it is almost always more expensive and more disruptive than anticipated, and the benefits are not always worth the cost. This tutorial gives you the framework to make the decision rationally rather than by instinct.
When facing multiple Salesforce orgs, there are exactly three architectural responses: (1) Merge — consolidate all orgs into a single org, (2) Federate — maintain separate orgs but implement a shared integration layer and common master data, (3) Coexist — operate orgs independently with no significant integration investment. The right answer depends on data sharing requirements, business unit independence, and consolidation cost vs benefit.
The Case for Consolidation
Org consolidation is justified when several conditions are genuinely true:
Shared customer view is a business priority. When the same customers appear across multiple orgs — buying from different divisions, receiving support from different teams — and the business actively needs to manage those relationships holistically, a single org enables Customer 360 visibility that separate orgs cannot provide without complex integration. If the business genuinely needs to know that a customer with an open service case is also in the sales pipeline, consolidation serves a real purpose.
Duplicate licensing costs are material. Multiple orgs often mean multiple sets of licences, multiple admin teams, and duplicated support contracts. At enterprise scale, the licence and administration cost of four orgs where one would suffice is meaningful — potentially millions of pounds annually. When cost savings are the driver, quantify them precisely before using them to justify a consolidation programme.
Governance and compliance require a single system of record. Regulated industries with data residency, audit trail, or reporting requirements that span business units may need a single Salesforce org to maintain a coherent compliance posture. Multiple orgs with inconsistent data governance are a compliance risk.
The technical estate is unmanageable. Multiple orgs, each with their own custom development estate, create unsustainable admin overhead. If the organisation cannot maintain the security, compliance, and release management of four separate orgs with existing headcount, consolidation reduces the governance surface area.
The Cost and Risk Reality
Org consolidation is routinely underestimated. The most common failure mode is treating it as a data migration project. It is not. It is a full reimplementation of one or more orgs into a combined architecture — with data migration as one component among many.
Data model reconciliation. Two orgs built by different teams at different times will have incompatible data models. Field names, picklist values, object relationships, and record types will conflict. Reconciling them requires architectural decisions that have downstream implications for both user populations. This work takes months, not weeks.
Process standardisation. The business processes encoded in each org reflect how those business units work. Consolidation forces a conversation about whose process wins — or whether a new, standardised process will be created. These are political decisions as much as technical ones, and they take time, sponsorship, and negotiation.
Integration re-architecture. Each org has its own integration landscape. In a consolidated org, all those integrations must be redesigned for the combined data model and user base. Integration projects within a consolidation are often as large as the original integration projects they replace.
Change management for two user populations. The users of both legacy orgs are losing their familiar system. Double the change management overhead of a standard implementation — and the risk that adoption in one of the legacy populations falls post-consolidation.
A common budgeting error is calculating consolidation cost as "X% of the original implementation cost of the smaller org." The correct calculation is closer to a fresh reimplementation of the combined scope. Data migration, integration re-architecture, and process reconciliation for two separate business units typically cost more than implementing either org from scratch — because you are also managing the complexity of two legacy estates simultaneously.
When Multiple Orgs Is the Right Answer
There are genuine scenarios where maintaining separate Salesforce orgs is the strategically correct decision:
Business units with genuinely independent customer bases. If the customers of Division A and Division B are entirely separate — no shared accounts, no cross-sell opportunity, no shared service — there is no Customer 360 benefit to consolidation. Independent orgs with independent governance are both simpler and cheaper.
Post-acquisition orgs pending divestiture. If an acquired business is expected to be divested within 3-5 years, investing in consolidation creates technical dependency that complicates the divestiture. Maintaining the acquired org independently preserves clean separation.
Different regulatory environments. Business units operating in different regulatory regimes (e.g., financial services and non-financial services within the same group) may have incompatible compliance requirements that make a shared org architecturally problematic. Separate orgs with separate compliance postures may be cleaner.
Different release cadences. If one business unit needs aggressive, frequent Salesforce customisation to support a fast-changing product and another needs a stable, change-minimal platform, a shared org forces both into the same governance and release framework — typically to the detriment of both.
The Federation Option
Between full consolidation and fully independent operation sits federation: maintaining separate orgs but implementing a shared integration layer that gives selected stakeholders a cross-org view of shared data.
Federation uses Salesforce's own integration capabilities — or a middleware layer — to create a shared customer or account record that exists across orgs, providing a unified view without requiring a single org. Data Cloud is increasingly used for exactly this purpose: aggregating data from multiple Salesforce orgs into a unified customer profile without requiring org consolidation.
Federation is the right answer when: the business needs a customer view that spans orgs, but the operational processes of each business unit are genuinely independent and would be disrupted by consolidation. It costs less than consolidation and delivers the primary business benefit — shared insight — without the operational disruption.
Making the Decision
The consolidation decision framework has three steps:
Step 1: Quantify the benefit. What specifically improves if you consolidate? Customer 360 revenue uplift — quantified, not aspirational. Licence cost savings — calculated precisely. Governance overhead reduction — measured in headcount or hours. If you cannot quantify the benefit, you cannot make the investment case.
Step 2: Cost the consolidation honestly. Commission an architectural assessment of both orgs to understand the data model gap, the integration re-architecture required, and the change management scope. Use this to produce a realistic cost estimate — including the 20-30% contingency that every consolidation programme should carry for scope discovery.
Step 3: Assess the federation alternative. Before committing to consolidation, price the federation option. If Data Cloud or an integration layer can deliver 80% of the benefit at 30% of the cost, federation is likely the better answer — and can be implemented without the operational disruption of a full merge.
Org consolidations triggered by post-acquisition integration pressures almost always happen too fast. The political pressure to show integration progress drives a timeline that the technical scope cannot support. The organisations that manage consolidations successfully impose a minimum 6-month discovery and design phase before any migration work begins — and they resist executive pressure to compress it.
Key Takeaways
- Multiple Salesforce orgs are common in enterprise environments and are not inherently a problem — they become a problem when the costs of independence outweigh the costs of consolidation
- Three strategic responses exist: merge, federate, or coexist — the right answer depends on data sharing needs, business unit independence, and consolidation economics
- Consolidation is justified by Customer 360 requirements, material licence savings, compliance needs, or unmanageable governance overhead — not by tidiness
- Org consolidation costs are systematically underestimated — treat it as a fresh reimplementation of the combined scope, not a data migration project
- Federation using Data Cloud or integration middleware can deliver the primary benefit of consolidation (shared customer view) at a fraction of the cost
- Take a minimum 6-month discovery and design phase before any migration work — and hold the line against political pressure to compress it
Checkpoint: Test Your Understanding
1. An organisation has two Salesforce orgs from a recent acquisition. The acquired company serves a completely different customer segment with no overlap. What is the most appropriate strategic response?
2. Why is "data migration" an inadequate framing for an org consolidation project?
3. An organisation needs a unified customer view across two Salesforce orgs but the business units are operationally independent with different release cadences. What is the recommended approach?
Discussion & Feedback