Short answer: stay in one org unless something forces you out, and the things that genuinely force you out are a short list: a regulator that requires separation, an acquisition you cannot merge inside a sensible horizon, or release cycles that cannot be reconciled. Everything else people cite (different processes, different regions, different business units) is an argument for configuration, not for a second org.
What a second org actually costs
The costs are not the licences. They are structural, they compound, and they arrive later than the decision:
- Every integration doubles. Each system that talks to Salesforce now talks to two, with two sets of credentials, two error paths and two things to test at release.
- Reporting stops being possible in the platform. Cross-org reporting means a warehouse, which is another system, another owner and another latency.
- Customer identity fragments. The same account exists twice, diverges, and no automated match is ever quite trusted.
- Change costs double, forever. Two release cycles, two sandbox sets, two sets of metadata drifting apart from the day you split.
- People pay for it daily. Two logins, two search boxes, two places a record might be.
None of that is fatal. All of it is permanent, which is the point: consolidation later is a programme, not a project.
The reasons that hold
Regulatory separation. A regulator requiring that one business unit’s data be inaccessible to another, in a way sharing cannot satisfy, not “should not see”, but “must be unable to”. Sharing can hide data from users. It cannot hide it from an administrator, and that difference is the whole argument.
Data residency. Where data must physically stay in a jurisdiction and your org cannot satisfy it.
An acquisition on a real clock. A company running its own Salesforce, with a merger that cannot wait. This is the honest common case, and the mistake is treating the temporary state as permanent instead of setting a date to revisit it.
Irreconcilable release cadence. One business needs weekly change, another needs quarterly with formal validation. Governance can sometimes fix this. Sometimes governance is what failed.
The reasons that do not hold, and what to do instead
“Different sales processes.” Record types, page layouts, path, and separate automation. This is what the configuration model is for.
“They must not see each other’s data.” Org-wide defaults set to Private, no role hierarchy overlap, and sharing granted deliberately — covered in org-wide defaults explained by outcome. If the requirement is that an admin cannot see it either, that is the regulatory case above and you are back on the short list.
“Our org is a mess and we want a clean start.” The mess is process debt, and it comes with you. A new org gets messy on the same schedule, and now you have two.
“We are hitting limits.” Check which. Custom object and field limits have specific numbers. Storage is purchasable. API allowances scale with licences. Splitting an org to solve a limit you have not identified is expensive guessing.
If you already have several
Most orgs asking this question are not choosing — they inherited three and want to know whether to merge. The order that works:
- Stop the bleeding. Agree that no new org is created without a decision at the same level that would approve the merge.
- Name the system of record per object. Not per org. Per object. Which org owns Account, which owns Opportunity. Most of the pain is ambiguity here.
- Pick the direction of integration and keep it one-way wherever possible. Two-way sync between orgs is the most expensive integration most companies own.
- Merge on a business event. A re-platform, a rebrand, a licence renegotiation. Merges justified only by tidiness lose their funding halfway.
The decision I would actually write down
One page, three questions, filled in before the architecture: what specifically cannot be satisfied in one org, which control would be required to satisfy it, and who is accountable for the doubled integration and reporting cost. If the first question has no concrete answer, the answer is one org.
And record the reversibility, because it is asymmetric. Staying in one org and splitting later is expensive. Splitting now and merging later is much more expensive, and the data model divergence is the part that makes it so, which is worth reading beside what happens when one org’s data does concentrate, since a single large org has its own scale problems and they are the cheaper set to have.
Frequently asked
Does Salesforce charge more for multiple orgs? Licences are per org, so you lose the volume position and gain administrative overhead. The bigger cost is still the integration surface.
What about a sandbox as a second org? A sandbox is not a second production org, and treating one as production is how data ends up somewhere with no backup guarantee and a refresh schedule.
Can Data Cloud solve cross-org reporting? It can unify data for analysis, which addresses reporting and not the operational split: users still work in two places, and integrations still land twice.
Is one very large org risky? It has scale problems: sharing recalculation, data skew, deployment risk. Those are known problems with known techniques. The multi-org alternative has structural problems with no technique.
