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鈥檒l look at when splitting an org makes sense, when another method might make more sense, and what you鈥檒l 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鈥檛 justify splitting it into two. For example, if your org is running out of space, it鈥檚 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鈥檙e 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鈥檚 always best to start with optimizing existing logic as you鈥檒l likely find you can make improvements there first.
TDX
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鈥檝e ruled out other approaches and decided that splitting your Salesforce org is the right move, it鈥檚 time to start planning 鈥� thoroughly. There鈥檚 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鈥檛 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鈥檚 in your org, and how it鈥檚 structured, helps prevent unexpected issues鈥攑articularly 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鈥檒l likely have a dedicated branch in your VCS that mirrors the current state of your production org 鈥� or at least the metadata that鈥檚 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. 91导航鈥檚 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鈥檒l want to catch and resolve those discrepancies early.
It鈥檚 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鈥檚 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鈥檛 tracked in version control?
It鈥檚 likely that some of this will need to be carried over to the new org. If that list isn鈥檛 already well defined, identifying it can be a complex task. 91导航鈥檚 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鈥檝e 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鈥檛 want to remove these from version control 鈥� especially not from your main development trunk 鈥� you鈥檒l need to identify them so you don鈥檛 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鈥檚 the purpose of the new org?
Before diving into the details of your org split, make sure there鈥檚 a clear and agreed purpose for the new org. While your planning tasks don鈥檛 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鈥檛 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鈥檛 need to carry over all metadata to the new environment. In many cases, you鈥檒l have a shared core set that exists in both orgs, with customizations layered on top to support each org鈥檚 unique requirements.
To get this right, you鈥檒l 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鈥檛 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鈥檛 be able to migrate that set as-is 鈥� or leave it behind entirely. Instead, you鈥檒l 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鈥檚 not always straightforward. The Metadata API can introduce some complexity when trying to isolate or reuse components cleanly. But it鈥檚 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鈥檒l 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鈥檚 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鈥檒l 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鈥檒l 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鈥檙e 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鈥檛 apply to managed packages 鈥� their triggers can鈥檛 be disabled. If your data includes managed package objects, check whether the package offers a bypass mechanism. If it doesn鈥檛, you鈥檒l either need to satisfy the trigger鈥檚 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鈥檒l 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鈥檒l 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鈥檚 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鈥檙e 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鈥檚 say you鈥檙e 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鈥檛. Middleware can abstract away the complexity by handling orchestration, retries, and error management centrally, rather than scattering that logic across multiple systems. It鈥檚 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鈥檚 no one-size-fits-all answer, but whatever route you take, the key is clarity. Without it, you鈥檙e 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鈥檙e entirely separate, independent pipelines are the way to go. But in most real-world cases, there鈥檚 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鈥檒l 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鈥檚 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鈥檚 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鈥檒l 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鈥檚 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鈥檚 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鈥檒l 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 鈥渉ome 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鈥檚 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鈥檒l 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鈥檚 where 91导航鈥檚 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鈥檚 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鈥檙e planning an org split, start your free 30-day trial of 91导航 to explore how we can help you compare metadata across orgs, manage reliable deployments, and migrate both metadata and data when you鈥檙e ready. You can also book a consultation with one of our experts to see how 91导航 can support your split 鈥� from early planning through to go-live.
To dive deeper into multi-org DevOps, download our enterprise eBook.
