# Single-org versus multi-org strategy trade-offs

*Platform Development Lifecycle and Deployment Architect Study Guide · System Design · Last updated October 26, 2026 · https://www.certifyforce.com/study-guide/platform-development-lifecycle-and-deployment-architect/system-design/single-org-versus-multi-org-strategy-trade-offs*

How to decide between one org and several: the operating-model test, the isolation, regulatory and redundancy triggers that justify multi-org, the cost and security multipliers it brings, and how to govern either choice with a CoE, packages and hub-and-spoke integration.

- Certification: Salesforce Platform Development Lifecycle and Deployment Architect
- Exam section: System Design
- Study guide: https://www.certifyforce.com/study-guide/platform-development-lifecycle-and-deployment-architect

**Official exam objective:**

> Given a customer landscape and their requirements, evaluate business, technical, and architectural considerations which support the defined org strategy.

## What the exam expects

- Recommend one org or several from how standardized and integrated the business processes are.
- Separate valid multi-org triggers (regulatory or contractual isolation, data residency, recovery beyond the platform) from weak ones (backlog, independence, limits that could be raised).
- Build a multi-org total cost of ownership model and explain the security governance it multiplies.
- Choose between platform-managed redundancy, active-passive and active-active, and between point-to-point and hub-and-spoke integration.
- Describe what a single org with several lines of business needs, and how a CoE and reference architecture stop org sprawl.

Key terms: **operating model** (the business's mix of process standardization and process integration); **hub-and-spoke** (one org holds shared master data for the others, integrated through middleware); **active-passive** (a synchronized but idle secondary org takes over in an outage); **TCO multiplier** (costs that repeat per org); **trust boundary** (a crossing where data must be authenticated, authorized and monitored).

## Key facts

| Fact | Detail | Source |
|---|---|---|
| Unification or coordination | As few orgs as possible | [Single-org versus Multi-org Strategy](https://developer.salesforce.com/blogs/developer-relations/2014/10/enterprise-architecture-multi-org-strategy) |
| Backlog across lines of business | Not a reason to split; fix with CoE roadmap and tiered admin | [Single-org versus Multi-org Strategy](https://developer.salesforce.com/blogs/developer-relations/2014/10/enterprise-architecture-multi-org-strategy) |
| Before a new org for limits | Talk to the Salesforce account team; some limits can be raised | [Single-org versus Multi-org Strategy](https://developer.salesforce.com/blogs/developer-relations/2014/10/enterprise-architecture-multi-org-strategy) |
| Concurrent batch jobs | Five queued or active per org; flex queue holds up to 100 in Holding | [Execution Governors and Limits](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm) |
| Multi-org operational cost | 2-3x for admin, release management, monitoring, compliance | [License Optimization - Patterns](https://architect.salesforce.com/docs/architect/well-architected/guide/resource-and-cost-optimization-license-patterns.html) |
| Default availability | Single region with platform-managed redundancy suffices for most | [Reliability](https://architect.salesforce.com/docs/architect/well-architected/guide/reliability.html) |
| Cross-region disaster recovery | Separate paid offering, not in any standard edition | [Reliability](https://architect.salesforce.com/docs/architect/well-architected/guide/reliability.html) |
| Cross-org integration | A trust boundary needing explicit authentication and authorization | [Trust](https://architect.salesforce.com/docs/architect/well-architected/guide/trust.html) |
| Sharing a process to internal orgs | Unlocked package with version control as source of truth | [Unlocked Packages](https://developer.salesforce.com/docs/platform/sfdx-dev/guide/sfdx-dev-unlocked-pkg-intro.html) |

## Check yourself

- Why is a growing backlog across lines of business not a reason for a second org?
- When does Well-Architected consider a multi-org pattern justified for reliability?
- Which costs must the multi-org side of a TCO model include?
- Why do two orgs make security governance harder than one?

## Sources

- [Enterprise Architecture: Single-org versus Multi-org Strategy](https://developer.salesforce.com/blogs/developer-relations/2014/10/enterprise-architecture-multi-org-strategy)
- [Execution Governors and Limits](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)
- [Reliability | Well-Architected](https://architect.salesforce.com/docs/architect/well-architected/guide/reliability.html)
- [License Optimization - Patterns | Well-Architected](https://architect.salesforce.com/docs/architect/well-architected/guide/resource-and-cost-optimization-license-patterns.html)
- [Trust | Well-Architected](https://architect.salesforce.com/docs/architect/well-architected/guide/trust.html)
- [Unlocked Packages](https://developer.salesforce.com/docs/platform/sfdx-dev/guide/sfdx-dev-unlocked-pkg-intro.html)

## About the full unit

The "Core concepts", "Exam traps" and "Worked scenario" sections of this unit, its 13 linked practice questions, and unlimited timed mock exams are included with the Platform Development Lifecycle and Deployment Architect pack (USD $19): https://www.certifyforce.com/practice-exams