Managing multiple Salesforce orgs is becoming the norm for growing businesses — either as a deliberate strategy, or as a consequence of mergers, regional expansions, or data residency obligations. But making the leap from a single Salesforce org to a multi-org setup comes with challenges. Deployments can become harder to coordinate, customizations drift apart, and what started as a practical solution can introduce silos and inefficiencies.
Managing multiple orgs doesn’t have to be difficult. With the right solution, teams can find a multi-org DevOps process that keeps their orgs in sync. In this post, we’ll explore why teams go multi-org, the challenges they face, and how Gearset’s layered modules can help you stay in control, even as you scale.
Why can multi-org deployments be a challenge?
Managing deployments across multiple Salesforce orgs isn’t simple. Each new org can lead to increased complexity and increased costs. Without a clear strategy, a multiple org architecture can lead to silos, making collaboration harder and slowing down development.
As large organizations break into smaller, more independent parts, new production orgs are often created to serve specific regions or business units. Integrations between these new orgs can quickly become complicated, especially when they rely on unique systems — like local payment gateways, compliance tools, or customer platforms — while still needing to sync core metadata across the organization. Keeping everything aligned without adding friction requires some strategic thinking about how the different orgs will evolve and scale.
While some businesses choose a multi-org setup, others inherit multiple orgs through acquisitions or regional expansion. In some cases, consolidating into one org with a single org strategy gives the best results. If you’re preparing for an org merge, check out these best practices to ensure a smooth transition.
Methods for managing multiple orgs
Coordinating the changes needed to run multiple Salesforce production orgs simultaneously is a complex task, involving all parts of the DevOps lifecycle. When it comes to the deployment of these changes there are a few methods that many will be familiar with.
Customized CI/CD pipelines
Managing multiple orgs is often done through a DIY CI/CD process, using scratch orgs, SFDX deployments, custom scripts, and automated metadata deployments to maintain consistency.
Managed packages
Some teams can achieve success using privately listed managed packages to distribute their changes across multiple orgs. This comes with pitfalls as managed packages are primarily designed for third-party app developers and require strict versioning and upgrade processes.
Unlocked packages
This is the classic way to tackle the problem of managing a multi-org strategy. A modular approach allows for easier distribution of distinct units of work, as metadata can be structured into unlocked packages. Many teams struggle to manage the versioning of these unlocked packages because the skillset needed is so specific.
To truly streamline multi-org deployments, teams need a flexible, modular approach — one that keeps shared components in sync while allowing each org to evolve independently.
TDX 2025
Meet with our product team at TDX 2025
Building a multi-org strategy that supports your business
A good Salesforce org strategy evolves over time to reflect developments in best practice, legislation, and the tools available to support business functions. Once a business has recognized the need to upgrade from a single org to multiple orgs, it’s key to assess how they’ll be divided up and the implications of using multiple regions.
Structuring orgs for business units
If orgs are created to support distinct business units, the core data model should be the same. This will mean that relevant records can be transferred between orgs, different departments can still share essential data while maintaining their own workflows, and reporting remains consistent across the organization.
Business processes, layouts, flows, and record types specific to that business unit can be created independently by the team developing the org and don’t need to be replicated across other orgs if they aren’t relevant to them. Even if the metadata differs at a surface level, maintaining a centralized standard of quality control is essential for consistent development practices.
Structuring orgs for regional units
If orgs are split to support regional business units, their metadata is likely to be much more closely aligned. The purpose of the orgs — whether fundraising for a non-profit, customer support for an international retailer, or sales and accounts management for a manufacturer — is ultimately the same.
The challenge in this setup is balancing development efficiency with the need for customization. Orgs must be tailored enough to serve their markets without introducing unnecessary duplication or complexity.
Instead of having mostly independent teams overseen by a Center of Excellence (CoE), a regional org strategy has much more of the development effort centralized and consolidated in a “global” development team. This team acts as the hub, managing core functionality and consistency. The region‑specific customizations are then carried out by admins or developers with an understanding of the requirements of the local markets.
Scaling multi-org architecture without losing control
Orgs tend to evolve organically in response to the needs of the users and the skills of the teams maintaining them. Without oversight this can quickly get out of hand. If your orgs begin in sync, it makes sense to have one development team supporting a deployment framework with a single source and multiple destinations.
Many teams start in this way, setting up an automated process to deploy the same update to multiple orgs without differentiating between them. This straightforward method allows them to adopt a classic Git-first process, using version control to track changes as components are built once and deployed everywhere.
This approach can work for a while, especially in the early stages, allowing the team to iterate and validate the build of the new org as they go. But these orgs can’t stay identical long term, as they will need to adapt to support local markets.
An example we’ve seen a lot over the last year has been the need to create a new org for business operations in China. This org needs to have the same functionality as the original but also be able to integrate with WeChat, AliPay, and Lark.
This creates a new challenge — if a standard object exists in all orgs, its subcomponents are probably customized for customers’ needs and the local market. If the development team creates a new tab that is specific to China, the central team will need to design a process that ensures:
- The tab is only deployed to the China org that it belongs to.
- The object the tab is dependent on can be kept up-to-date with the global architecture and any updates to it are deployed to all orgs.
Modularizing your metadata with layered modules
This is where modularization comes into play. Gearset’s layered modules make it easy to build and deploy different configurations across multiple diversified production orgs. With layered modules, teams can configure multi-org pipelines that simultaneously update the core architecture across multiple orgs, while a separate stream of org-specific customization is layered on top. There are two layers of modules:
- A core module containing shared metadata used across all orgs
- Org-specific modules holding metadata unique to individual regional or business unit orgs
These are maintained as separate entities in source control and can be updated independently. At the point of deployment the core module is combined with the org-specific module to create a single deployment package.
Here’s why this approach makes managing multiple orgs easier than ever:
- A complex landscape of code is organized into modules, which can be combined to create org-specific deployment packages.
- A single core module keeps the common architecture in sync across every org.
- Org-specific modules let teams own their local customizations without worrying about them being overwritten by global updates.
Setting up your layered modules
Expanding your multi-org pipeline? With Gearset, you can add a new org by creating a module and slotting it into your existing setup without any disruption.
After running the modularization wizard in your repository for the first time, you’ll be able to create new org-specific modules whenever you need them.
After the modules have been created, you can populate them with metadata. If you are adding a new org, open Gearset, go to My Connections, and add your org as you would a standard Salesforce connection. If you are using layered modules with Alibaba Cloud, make sure to specify that option when you connect your org.
Once the org is connected to Gearset, you’ll be able to select the metadata you would like to populate your module with and selectively commit it.
1. Build a multi-org pipeline
Once your modules are set up, using Gearset’s Pipelines, you can layer them together. Head to Continuous delivery > Pipelines. In the All layered modules view you will see the overall view of your changes as they move between the stages of your environments as independent features.
When you update the core module, it has to pass validation checks against every affected environment before it can be merged and promoted further.
As core updates move through QA and UAT to production, these checks act as a quality gate, making sure that nothing is added to the core framework without confirming it’s compatible with every org.
Compare this to a more traditional package development model, where teams would finalize a package and then distribute it to the subscriber orgs, which could quickly fall out of sync. With layered modules, that’s not an issue — all production orgs contain the most up to date version of the core module at all times and are never out of sync with each other.
2. Keep local customizations separate
As we covered earlier, each org needs its own local adjustments to fit its market. To keep everything running smoothly, layered modules applies two key principles:
- Org-specific changes mustn’t overwrite or alter shared core components.
- Core updates mustn’t overwrite or alter org-specific changes.
Gearset makes this simple. If you need to update the China layered module, just select the target module, run a comparison, and pick the components you want to add.
Once selected and added to the China module, the changes are then promoted through the pipeline independently of core updates — so they’re safe from being overwritten.
3. Give teams the right level of visibility
Teams working on regional environments only see and interact with the orgs relevant to them. No accidental crossovers, no stepping on each other’s toes. Just streamlined, controlled multi-org DevOps with the right access to the right environments.
What if I already have multiple orgs and want to align them?
If you already have a multi-org setup that needs restructuring, layered modules work for that too.
Find the common components. Your existing orgs may already be using a Git-first deployment process with their own repositories. Start by identifying the components shared between all your orgs and grouping them into your core module.
Separate what’s different. Next, identify the components which are unique to your orgs and do not exist in the core module. These will become your new layered modules.
Combine everything into a single workflow. Once your modules are defined, you can build a new pipeline where deployments automatically layer the core module with the right org-specific modules.
With layered modules, you don’t have to start from scratch. You’re building on what’s already in your Salesforce environment — making it more structured, scalable, and easier to maintain.
Future-proofing your multi-org strategy
By separating shared metadata from org-specific customizations, layered modules keep your Salesforce orgs aligned while allowing for localized differences. This makes deployments smoother, reduces manual work, and keeps maintenance simple.
Stronger governance
Your org strategy isn’t static. As your business evolves — adding new orgs, changing their purpose, or restructuring teams — a modular approach keeps everything organized. Whether your company is expanding globally or adapting to new security regulations like data residency laws, layered modules make it easy to adjust your multi-org setup without disrupting development.
DevOps best practices
DevOps is all about automation, consistency, and continuous delivery, and that’s exactly what layered modules deliver for multi-org teams.
- Enforceable change management. Every update passes through a validation process, ensuring core components work across all orgs before deployment.
- Improved DevSecOps performance. Secure, modular deployments mean less risk and fewer late-stage fixes.
- Less manual effort. Automate multi-org deployments without relying on packages or repetitive, org-by-org changes.
Try it for yourself
Scaling your Salesforce setup doesn’t have to be complicated. Layered modules simplify the process of setting up and maintaining a multi-org pipeline — and you don’t need anything other than the Gearset platform to get started.
Layered modules are available as part of our 30-day free trial and the Enterprise Automation platform.
