I’ve spent more than a decade helping enterprise teams plan and deliver large-scale Salesforce implementations, org consolidations, and migrations. And if there’s one thing I’ve learned, it’s this:
Salesforce org merges don’t fail because teams lack effort or intent. They fail because complexity hides in places most plans never fully account for.
If you search Reddit or Salesforce community forums, you’ll find posts going back ten years describing the same concerns I still hear from customers today:
The questions haven’t changed because the underlying challenge hasn’t changed. Salesforce environments have only become more complex, with more automation, more integrations, and more teams relying on the platform as their system of record.
What has changed is our ability to plan with far more visibility than we had even a few years ago.
This article is meant to be practical. It reflects what works in real projects, where time is limited, stakeholders disagree, and perfection isn’t an option. If you’re planning a Salesforce org merge, this guide will help you get started the right way.
One of the most common mistakes I see is teams jumping straight into how to merge Salesforce orgs before they are aligned on why they are merging them in the first place. Org merges are often triggered by acquisitions, restructures, or cost pressures, but too rarely do teams pause to define what success actually looks like. Is the goal a single source of truth? Lower operating costs? Better reporting? Simpler processes? Without a clear set of outcomes, even a technically successful merge can miss the mark. An org merge is not just a data or metadata migration; it is a strategic transformation that should be guided by well-defined business goals, not just a cutover plan.
In reality, an org merge is an organizational transformation that affects:
You can migrate data and metadata successfully and still fail if the merged org reinforces broken or unused processes.
This is why SalesforceBen’s long-standing advice still resonates:
“Managing and consolidating two systems is the easy part. Ushering people, process, and data through consolidation is the challenging endeavor.”
That insight shows up in almost every project I’ve worked on.
The best org merges follow a structured, phased approach. This isn’t new. What’s new is how much better informed each phase can be today.
.png)
Goal: Build a complete, evidence-based understanding of what exists today — across technology, data, processes, and the teams that use them.
Discovery is not just about cataloging metadata and records. It is about understanding how Salesforce supports the business today and how that may need to change. Before deciding what to merge, migrate, or retire, teams need clarity on both the technical landscape and the organizational reality behind it.
In practice, this means assessing five dimensions in parallel:
1. Metadata and Configuration: Catalog standard and custom objects, fields, record types, flows, Apex, validation rules, approval processes, and installed packages. This establishes the structural footprint of each org and surfaces overlap, divergence, and technical debt.
2. Data Health and Complexity: Assess data quality, duplication, orphaned records, inconsistent field usage, and historical data retention requirements. Understanding data risk early prevents costly cleanup later.
3. Integrations and System Dependencies: Document every inbound and outbound integration, including middleware, ERP, marketing automation, CPQ, data warehouses, and productivity tools. Identify ownership, criticality, and potential points of failure during consolidation.
4. Reporting and Metrics: Identify dashboards and reports that leadership relies on to run the business. Clarify which metrics must remain consistent across orgs and which variations are acceptable.
5. Process Execution and Team Alignment: This is where discovery expands beyond the technical layer. Assess how core processes are actually executed today and how teams are organized around them:
Understanding whether teams and processes are expected to stay distinct or move toward a shared operating model is critical. Without this clarity, teams risk designing a merged org that either over-standardizes too early or preserves fragmentation indefinitely.
Why this matters: Org merges often fail not because teams miss technical assets, but because they defer organizational decisions until late in the project. Discovery should surface these questions early, even if the answers come later during strategy and design. Capturing assumptions and open decisions at this stage gives stakeholders a shared starting point and prevents misalignment as the project progresses.
Goal: Define a future-state org that is simpler, more consistent, and easier to govern.
This phase answers the question: What are we actually building toward?
1. Consolidation model
There is no universally “correct” choice. The right model depends on regulatory needs, operating autonomy, and long-term governance maturity.
2. Data model and ownership
3. Process harmonization
This is where process analysis pays off. Instead of relying only on interviews or politics, teams can design around how work actually happens today.
4. Governance design
Goal: Execute the merge safely while preserving business continuity before, during, and after go-live.
Execution is where even well-planned org merges can stumble if teams focus only on migration tasks and underestimate go-live complexity. This phase is not just about moving data and metadata; it is about ensuring the business can continue to operate through cutover with minimal disruption.
Execution typically runs across several coordinated workstreams:
Validation should not stop at “it works.” It should confirm that teams can operate without workarounds.
Goal: Stabilize, drive adoption, and prevent complexity from returning.
A merge is not the end of the journey. Without governance, complexity creeps back quickly.
This is where ongoing measurement matters. If you can see where users deviate from intended workflows, you can address issues before they become systemic.
Ongoing monitoring can also support building a backlog of enhancements to make now that teams are getting comfortable with the new system and processes.
Across projects, the same risks surface repeatedly:
Most data seems simple and straightforward when you first think about it. When you start to draw out the data model and consider all the connections, the junction objects, etc, you notice it becomes more complex with each consideration. Then when you begin looking at live data, you begin to see even more complexity lying within. This complexity grows as you bring two data models together and consider the intricacies of both. The longer it takes to see live data from all sources, the more assumptions you have to make during design and build that may be proven wrong.
Mitigation: profile data early, define canonical models, plan dedupe deliberately.
Bringing multiple processes together isn’t just about finding the commonalities. It’s about taking a step back to make sure the process as a whole stands the test of merging businesses. Some steps may not make sense anymore. In some cases, users may not be using the processes as they were designed. Often, new steps need to be considered to support the merging of multiple use cases. Without the process alignment from the businesses first, you risk building processes that are quickly proven outdated or inefficient.
Mitigation: analyze adoption and variation before locking in workflows
Before executing an org merge, you need to account for every integration users rely on, including those from installed packages. You’ll often find overlapping integrations, whether it’s the same system connected in multiple ways or different systems supporting the same business purpose. To avoid rework later, make future-state integration decisions early and ensure your target process flows reference the correct endpoints, which should be included in the migration plan.
Mitigation: build and validate a complete integration map, not just a list.
Processes will change; object or field names may change; permissions may change; integration endpoints may change. Org merges hold a lot of change bundled up in a single project.. Without the proper methods to support these changes and ensure there is communication and easy access to get help, users will feel frustrated and resistant.
Mitigation: identify power users early, communicate often, and support teams post-launch.
Everyone wants to see a plan come together quickly. After all, it doesn’t always sound that complicated before you start digging in. The reality is, some efficiencies are lost when you try to rush things that just need more time. When you make assumptions that end up being wrong, rework is born. Rework adds time, stress, and moves dates. It’s important to set realistic goals based on input from the team doing the work and clear success criteria along the way to validate progress and tracking towards go live.
Mitigation: define readiness gates based on validation, not dates.
These risks compound. One missed dependency often triggers several others.
If you’re just beginning to plan a merge, start here:
The most successful org merges I’ve seen share three traits:
The fundamentals of good consulting haven’t changed. What has changed is our ability to see reality more clearly and plan with confidence.
Used well, modern tooling doesn’t replace expertise. It makes good decisions easier and bad surprises rarer.
