As companies grow and processes evolve, their Salesforce org grows too. Eventually, there might come a time when splitting the org becomes part of the conversation.
In this post, we’ll look at when splitting an org makes sense, when another method might make more sense, and what you’ll need to consider if you do decide to move ahead.
When is a Salesforce org split worth considering?
Discussions around org splits are usually triggered by something going wrong — a pain point or performance bottleneck — rather than a steady, predictable trend. Splitting a Salesforce org is a complex and costly undertaking, so it should only be pursued after carefully weighing up the alternatives.
Simply outgrowing your org doesn’t justify splitting it into two. For example, if your org is running out of space, it’s much better to adopt an archiving solution or even buy additional storage — rather than spinning up a second production org and going through the effort of bringing it online.
Likewise, if you’re seeing performance issues, like slow transactions or exceeding governor limits, an org split might be an option — but it should be one of the last options you consider. It’s always best to start with optimising existing logic as you’ll likely find you can make improvements there first.
Dear Irving on Hudson
Gearset After Hours at NYC Agentforce
Building the case to split a Salesforce org
Org splits are considered in scenarios where there are distinct lines of business operating under the same org. If you do find yourself with a single org covering business areas that are largely independent from one another, then splitting them could be the right move.
Data residency is another common driver. Even when business processes are broadly aligned across regions, compliance requirements can make it impossible to store all your data centrally — prompting the need for separate orgs to meet local regulations.
Making the decision to split orgs
If you’ve ruled out other approaches and decided that splitting your Salesforce org is the right move, it’s time to start planning — thoroughly. There’s no set sequence for the prep work, but every key area needs attention before the migration begins. That upfront planning will form the foundation of a reliable, step-by-step migration plan detailing what needs to happen, when, and in what order.
A well-considered multi-org strategy doesn’t have to be significantly more complex than a single-org model, the transition itself — much like an org merge — is a complex undertaking. Success depends on having detailed knowledge of your Salesforce org. Understanding exactly what’s in your org, and how it’s structured, helps prevent unexpected issues—particularly those that could cause delays or extend downtime during migration.
These are some of the critical factors businesses should account for when preparing for an org split:
Is your source of truth ready for the split?
In most orgs, version control plays a central role in the development process. You’ll likely have a dedicated branch in your VCS that mirrors the current state of your production org — or at least the metadata that’s actively managed through your deployment pipelines. That said, not everything in production is always tracked in source control. User-driven changes, such as reports and dashboards, are often created directly in the live org outside the formal dev process.
When preparing for an org split, this setup raises a few important considerations:
Is your branch truly up to date?
This step is critical — your source of truth for metadata will feed directly into the new org. Gearset’s comparison tools and org monitoring jobs jobs make it easy to spot changes made directly in production that were never captured in version control. You’ll want to catch and resolve those discrepancies early.
It’s also worth reviewing the state of the source org itself. Pulling in stale, redundant, or unused metadata can lead to unnecessary complexity in the new environment. A cleanup ahead of time will save you headaches down the line.
If there’s drift between production and your VCS, resolve it before proceeding — and understand how it happened. Closing those gaps helps future-proof your process. Ongoing comparisons and monitoring jobs can keep your environments in sync and prevent new misalignments from creeping in.
How will you handle metadata that isn’t tracked in version control?
It’s likely that some of this will need to be carried over to the new org. If that list isn’t already well defined, identifying it can be a complex task. Gearset’s metadata filter can help here — you can build a manifest visually by selecting all metadata types, then removing items already mastered in version control. What remains is what lives in the org but not in your source branch.
You may choose to store this in a separate repository and keep it up to date until the new org is ready, avoiding disruption to your ongoing development work while ensuring you’ve captured what needs to be migrated.
Are there any environment-specific metadata items to exclude?
Things like hardcoded values, SSL certificates, or org-specific configurations may not make sense to carry into the new org and should instead be recreated there. While you probably won’t want to remove these from version control — especially not from your main development trunk — you’ll need to identify them so you don’t deploy them into the new environment by mistake.
This includes metadata such as sharing rules, profiles, and roles. Can you be sure the sharing model in your new org will match the original setup 1:1? If not, you may need to migrate the existing configuration first, and then evolve it separately for the new org.
What’s the purpose of the new org?
Before diving into the details of your org split, make sure there’s a clear and agreed purpose for the new org. While your planning tasks don’t need to follow a strict sequence, this decision should come first — it directly impacts how you structure your metadata and whether your version control setup needs to evolve.
Data residency requirements
The simplest scenario is when the new org is intended to be a near-identical replica of the current one — at least from a metadata standpoint. As mentioned earlier, hitting Salesforce limits typically isn’t a compelling reason to create a second org. But where data residency comes into play — with identical business processes running across different regions — splitting into multiple orgs can be a smart move.
In these cases, your existing Git repo might still serve both orgs and their related sandboxes, provided that deployments are coordinated. This shared setup avoids unnecessary complexity while meeting compliance needs.
Business divergence
If the org split is being driven by diverging business processes, you won’t need to carry over all metadata to the new environment. In many cases, you’ll have a shared core set that exists in both orgs, with customizations layered on top to support each org’s unique requirements.
To get this right, you’ll need a detailed understanding of your current metadata, data structures, and user access — and a clear plan for how each org will operate going forward. Splitting isn’t usually as straightforward as assigning one group of components to the new org and leaving the rest behind. Some level of rework is almost always required.
For example, consider a permission set that grants access to objects and fields that are being split between the two orgs. You won’t be able to migrate that set as-is — or leave it behind entirely. Instead, you’ll need to define new permission sets for each org. Once those are in place, the original set becomes redundant.
Version control requirements
Your version control setup will depend on what the new architecture looks like — but the core principle remains the same: every metadata item should have a single source of truth. Duplicating metadata across multiple repositories increases the risk of drift, deployment failures, and regressions.
That’s not always straightforward. The Metadata API can introduce some complexity when trying to isolate or reuse components cleanly. But it’s worth taking the time to work through each case to maintain that single-source approach.
Supporting multiple orgs might mean adding complexity to your DevOps process — like separate pipelines or org-specific workflows — but with the right tooling, you can scale without losing visibility or control.
What data needs to move to your new org?
In many org splits, you’ll need to migrate some — but not all — data to the new environment. The first task is identifying which records and objects are relevant. This can be time-consuming, but it’s essential groundwork for a clean and accurate migration.
Once you know what needs to move, the next step is figuring out how to migrate it without introducing errors. You’ll likely be dealing with historical data — records that were created under previous validation rules or flows that would now block their re-creation.
Take Opportunities with a Closed Won stage, for example. A validation rule might prevent those from being created directly. That rule makes sense during normal business operations, but during a migration, you’ll want to preserve the record in its final state — not force it back through an earlier lifecycle just to pass validation.
Process automation adds another layer. Triggers and flows typically fire on insert, but you’re not trying to recreate the full record history — just replicate the end result. You want the data to land in its finished form, without reprocessing.
Salesforce provides basic options here: you can temporarily deactivate validation rules, triggers, and flows during migration and reactivate them afterward. But this doesn’t apply to managed packages — their triggers can’t be disabled. If your data includes managed package objects, check whether the package offers a bypass mechanism. If it doesn’t, you’ll either need to satisfy the trigger’s requirements post-insert or decide whether that data is essential to carry across.
What if data needs to be deleted or shared?
In some cases, a split might also require deleting data from the original org — for example, to meet data residency requirements. If data is moving to the new org permanently, it may need to be removed from the source org entirely. That kind of deletion can have wide-reaching consequences. You’ll need to fully understand the downstream impact, including whether cascading deletes could remove other records unintentionally. Always take a full backup before any data migration or deletion.
You may also run into shared data models — like accounts or contacts that span both orgs. If global fields need to stay in sync while allowing for regional variations, you’ll need a strategy for managing that split.
Finally, migrating large volumes of data is rarely simple. Record relationships, parallel loads, and locking issues can cause problems during insertion. Make sure you follow established Salesforce data migration best practices and build those steps into your plan ahead of time — rather than figuring them out on the fly.
How will integrations be affected?
Alongside metadata and data migration, it’s critical to assess how your integrations will be impacted by the org split. Your Salesforce org is likely just one part of a broader ecosystem — consuming data from external systems or serving as a source of truth for others. Some of the data needed in the new org might not originate in Salesforce at all, but instead be mastered in another platform and synced in.
If you’re moving from a single production org to two, this is the perfect opportunity to re-evaluate your integration strategy. Point-to-point integrations can quickly become brittle and hard to manage as the number of endpoints grows. Introducing middleware — like MuleSoft, Jitterbit, Dell Boomi, or similar platforms — helps consolidate integration logic, reduce risk, and streamline maintenance.
Let’s say you’re pulling Account data from SAP on a nightly schedule. If the sync to one org succeeds but fails in the other, you now have two environments that should be aligned — but aren’t. Middleware can abstract away the complexity by handling orchestration, retries, and error management centrally, rather than scattering that logic across multiple systems. It’s a far more scalable solution than managing duplicate integrations independently.
Middleware also minimizes the burden on your external systems. Rather than forcing upstream platforms to maintain separate connections and custom logic for each Salesforce org, middleware acts as the intermediary — allowing you to scale integrations with far less overhead. If five external systems feed into Salesforce, middleware lets you manage one integration hub instead of five distinct projects.
Planning for integration changes
As part of your org split planning, map out every system in your architecture that integrates with Salesforce. For each integration, determine:
- Will this system now connect to a different Salesforce org?
- Does it need access to both orgs after the split?
- Are there changes needed to data routing, access controls, or scheduling?
- Can the integration be consolidated through middleware?
Make sure any changes are accounted for early — and tested thoroughly — so integrations remain reliable once your new architecture is live.
What will your development process look like?
If the split is driven by divergent business processes, each new org will likely need its own set of sandboxes — and potentially its own release cadence. That has implications for your version control strategy. If some metadata is shared in name but differs in configuration between orgs, how will you manage that?
You might choose to maintain separate copies in different repositories, or extract a shared baseline that gets customized per pipeline. There’s no one-size-fits-all answer, but whatever route you take, the key is clarity. Without it, you’re at risk of introducing confusion, misaligned releases, or technical debt.
If the orgs are exact mirrors, things are simpler — a single pipeline can serve both. If they’re entirely separate, independent pipelines are the way to go. But in most real-world cases, there’s partial overlap. In those scenarios, strict pipeline management is essential. Too much flexibility and you risk diverging sources of truth. Too little, and your process might become a bottleneck, slowing down delivery or introducing regressions.
You’ll also need to consider how your team is structured. Will developers be working across both orgs? Will they be managing multiple sandboxes and repositories? That kind of setup increases the risk of someone building the right feature — in the wrong place. Put processes and checks in place to reduce that risk and make it easy for the team to stay on track.
How will you keep everyone informed?
Communication is key in any successful org split — and your stakeholder group is likely to be wide-ranging, including everyone who uses Salesforce in your business.
Given how many moving parts there are, building a detailed project plan upfront may not be realistic. But as work progresses and more specifics come into view, your plan should evolve — and be shared clearly with everyone involved. Timely, transparent updates will keep stakeholders aligned and avoid surprises down the line.
If possible, aim to get access to the new org as early as you can — even if it comes at a cost. Having that environment available ahead of time gives you more space to plan, test, and communicate effectively across the organization.
How will you test the new setup?
Once the migration is complete, the new orgs need to be thoroughly validated — but a significant portion of that validation must happen before any data is moved. That’s because, at the point of migration, the source org should be placed into a code and data freeze. Any records created after that point also need to be migrated, adding complexity and extending downtime.
For that reason, it’s not realistic to rely on weeks of post-migration testing before the new orgs go live. Test automation is critical, but what matters even more is the quality and coverage of those tests. Before you migrate anything, you should have a strong grasp of the business processes that will run in each new org — and automation in place to verify those workflows. This ideally includes Apex tests that assert expected behaviors at the code level.
Manual testing after the migration is unlikely to be fast enough. UI-based tests can be useful, but they also create data in the org — which you’ll then need to clean up — or they require spinning up a full-copy sandbox of the new org, which takes time and adds operational overhead.
If issues emerge during testing, you need to be ready to respond immediately. That’s why as much testing as possible should happen before the critical cutover window. The more you can validate in advance, the smoother — and faster — your go-live will be.
What coordination is needed after the split?
Even after the org split, there may still be a need for cross-org visibility — particularly for executive-level reporting, analytics, or metrics. If reporting is already centralized through an external BI or data warehousing platform, adding the new org’s data into that ecosystem may be relatively straightforward.
But if your reporting currently depends on Salesforce-native tools — such as reports, dashboards, or custom API-based processes — these will need to be reviewed and updated. You’ll want to ensure they continue to provide accurate insights post-split.
One option is to use Salesforce Data Cloud to create a virtualized architecture — designating one org as the “home org” and surfacing data from the other into it for unified reporting. Alternatively, third-party tools that aggregate data across multiple Salesforce orgs can also provide a single pane of glass for reporting and analytics.
Whatever approach you choose, it’s essential to plan for this in parallel with the split — not as an afterthought. That way, your reporting continuity is preserved even as your architecture evolves.
Managing DevOps across multiple orgs
Moving to a multi-org setup brings new challenges for DevOps. Even if your orgs start out identical, they’ll quickly evolve — with different processes, regional requirements, and integrations. This is especially true for distributed Salesforce teams working across different time zones or business units, where keeping everyone aligned becomes even more challenging. Without a clear approach, deployments become harder to coordinate, and consistency starts to slip.
That’s where Gearset’s layered modules come in. You can separate shared metadata into a core module, and layer org-specific customizations on top — so each org can evolve independently, while staying aligned at the architectural level. This modular approach makes it easier to keep orgs in sync without duplicating effort, control what gets deployed where and scale confidently with consistent quality across all orgs.
Planning your org split with confidence
Splitting a Salesforce org is a significant and complex decision. It’s not something to take on lightly — and definitely not something to rush. But in the right circumstances, with careful planning, the move to a multi-org setup can unlock flexibility, improve compliance, and better support your evolving business needs.
If you’re planning an org split, start your free 30-day trial of Gearset to explore how we can help you compare metadata across orgs, manage reliable deployments, and migrate both metadata and data when you’re ready. You can also book a consultation with one of our experts to see how Gearset can support your split — from early planning through to go-live.
To dive deeper into multi-org DevOps, download our enterprise eBook.
