Your company just acquired another business. Or your regional offices each built their own Salesforce instance. Or different divisions have been running separate systems for years. Now someone in leadership says, “We need to consolidate.”
What sounds like a straightforward technical project—moving data from system A to system B—turns out to be far more complex. Org merges force decisions about how the combined company should actually operate, and those decisions are often unresolved when technical work needs to start.
This guide explains what Salesforce org merges are, why companies do them, and what makes them more involved than most organizations expect.
What Is a Salesforce Org Merge? (It’s Not What You Think)
A Salesforce org merge is the process of combining two or more separate Salesforce instances (called “orgs”) into a single system. Despite the name, there’s no “merge” button in Salesforce. What’s really happening is data migration: moving information, configurations, and processes from multiple systems into one.
Companies typically consolidate orgs in three scenarios:
Post-acquisition integration: You acquire a company that has its own Salesforce instance. You’re running two separate systems for what’s becoming one company.
Regional consolidation: Your business expanded, and each region built its own Salesforce instance to handle local requirements. Separate orgs for each division or geographic area.
Organic sprawl cleanup: Different business units launched their own Salesforce instances over time. What made sense for each division independently now creates silos across the organization.
Why Companies End Up With Multiple Salesforce Orgs
These multi-org situations almost always made sense when they happened.
When you acquire a company, forcing an immediate system consolidation creates disruption during an already turbulent transition. Running parallel systems feels pragmatic—let both teams stay productive while you figure out the broader integration strategy.
When you expand into new regions, local requirements matter. Different states have varying data privacy laws. Different business units serve different market segments. Spinning up a regional instance gets you to market faster than retrofitting your existing system.
When business units operate independently, separate systems provide autonomy. Each division can customize Salesforce to its specific needs without compromising anyone else’s requirements.
The challenge is that what works in the short term becomes expensive over time. The cost of running parallel orgs compounds—in licensing fees and operational friction that’s harder to measure.
When Does It Make Sense to Consolidate Salesforce Orgs?
The reasons for consolidation usually fall into a few categories:
Operational Efficiency
Running multiple Salesforce instances means duplicating everything—reports, processes, and administrative work. Every new integration happens twice. Every system update requires testing in multiple environments. Every policy change needs coordination across orgs.
Data Visibility
When customer information lives in different systems, nobody can see the picture. Your support team handles a case, but can’t see the customer’s purchase history in the other org. Your sales rep pursues a prospect without realizing they’re already a customer of your other division.
Cross-selling and Upselling
Growth through existing customers requires knowing what they already buy and what else they might need. When account data is scattered across systems, opportunities stay hidden. Teams from different divisions end up competing for the same accounts without realizing it. Customers get pitched by multiple reps who can’t see the full relationship, extending sales cycles and creating confusion about whether you’re one company or several.
Reporting and Analytics
Your CFO wants to see the pipeline. Your CMO needs unified campaign performance. Your CEO wants customer acquisition costs across all business units. When data lives in multiple places, these requests trigger manual export-and-reconcile exercises that take days and produce stale information.
User Experience
Sales reps switch between systems to check if a prospect is already a customer. Service agents toggle between orgs to see if there’s an open case. Account managers maintain separate workflows for different products. This friction slows teams down and creates gaps where things fall through.
Cost
Multiple orgs create duplicate costs across licenses, integrations, and maintenance. These direct expenses add up, though the bigger drain often comes from operational inefficiency—the hours spent reconciling data, coordinating changes, and working around system limitations.
Three Ways to Consolidate Salesforce Orgs (And When Each Makes Sense)
When it’s time to address multiple orgs, you’re really choosing between three approaches:
Complete consolidation moves everything into one org. It’s the most efficient long-term path: clean reporting, a single system, and maintenance happens once. The catch is that it requires real process alignment across teams, and territory, security, and data access models all need to work for everyone. Timeline is typically 6-12 months.
Integration without migration keeps the orgs separate while automatically syncing data between them. Teams keep their familiar tools and autonomy, which helps with change management. The trade-off is that the complexity never goes away. Integration infrastructure needs ongoing maintenance, troubleshooting spans multiple systems, and you’re still managing duplicate configurations across orgs.
Phased consolidation moves business units or regions one at a time, spreading disruption and letting you learn as you go. Easier on resources, more time for users to prepare. The downside is time: a 9-month effort can stretch to 18 months phased, and you’re managing a hybrid state the entire time.
What Gets Migrated in a Salesforce Org Merge?
Regardless of approach, consolidation involves moving or aligning several categories of information:
Data
The customer records, account hierarchies, contact information, sales opportunities, service cases, and any custom objects your business relies on. This is what most people think of as “the migration,” but it’s only part of the picture.
Processes
The workflows that route leads, the approval chains for discounts, and the automation that creates tasks when opportunities close. These need to work in the consolidated environment, which might mean rebuilding them or adapting them to new business rules.
Configurations
The custom fields that capture your specific business information, the page layouts your teams see, the record types that organize different business processes, and the validation rules that enforce data quality. Every customization needs to be migrated or recreated.
Integrations
Every system connected to Salesforce (your marketing automation platform, ERP, billing system, data warehouse, etc.) needs to point to the new org. Some integrations can be redirected. Others need rebuilding. Discovering all the integrations is often harder than remapping them.
Users and Permissions
Access models that made sense in separate orgs might not work when combined. Who can see what customer data? Who can edit which fields? Who approves which transactions? These decisions reveal assumptions about business operations that need to be reconciled.
Reports and Dashboards
What people use to do their jobs daily. These often contain embedded business logic about territories, product lines, or customer segments that need updating for the new environment.
What Makes Salesforce Org Merges Complex?
Several factors make org consolidation more complex than it might appear:
Data quality issues surface: When you have two customer records for “ABC Corporation”—one spelled “ABC Corp” and one “A.B.C. Corporation”—which one is right? When contact information conflicts between systems, which source do you trust? Merges force data cleanup that’s been deferred for years.
Process differences matter: Your East Coast sales team closes deals with a three-stage process. Your West Coast team uses five stages with different criteria. In separate orgs, both work fine. In a consolidated org, someone’s process changes—or you build complexity to accommodate both.
Change impact is real: People accustomed to their current system face learning curves with the new one. Even when the underlying functionality remains the same, different page layouts, field labels, and navigation patterns can slow users down temporarily. Keeping teams productive during the transition requires deliberate planning.
Integration complexity compounds: Each connected system is a dependency in the migration. Your accounting system needs data from Salesforce. Your call center routing depends on case ownership rules. Your commission calculations pull from closed opportunities. Every integration is a thread that can’t break during the transition.
Business continuity is non-negotiable: Sales teams still need to close deals. Support teams still need to resolve cases. Marketing campaigns still need to run. The migration happens while business continues, which means careful cutover planning and sometimes maintaining parallel systems temporarily.
Governance questions emerge: Who decides which fields are required in the consolidated system? Who approves new integrations? Who owns the page layouts for each team? In separate orgs, these decisions were distributed. In a consolidated org, someone needs clear authority to make calls.
Why Salesforce Org Merges Fail (And How to Avoid It)
Not every org merge succeeds. The common failure points aren’t usually technical:
Undefined Business Requirements
Technical work can’t start without decisions about how the business will operate. Questions like “should sales reps see opportunities across all divisions?” sound simple, but surface unresolved assumptions about territory ownership, compensation, and collaboration. Getting stakeholder alignment on these requirements is what moves projects out of planning limbo.
Underestimated Timelines
Most initial estimates prove optimistic. Projects estimated at 3-4 months often run 9-12 months. The gap isn’t usually in the technical work—it’s in the business decision-making and data preparation that happens before technical work can start. Build these phases into your timeline up front, and add a 30% buffer for unknowns that surface during discovery.
Data Migration Surprises
Data that looks clean in the source org reveals problems during migration. Referential integrity breaks. Required fields are missing. Picklist values don’t match. What seemed like a straightforward extract-transform-load exercise turns into extensive data remediation. Invest in data profiling and sample migrations during planning to surface these issues early, not during production cutover.
User Adoption Challenges
Technical success doesn’t guarantee operational success. If users find the new system harder to use than what they had, they’ll work around it. Training helps, but so does involving users early in design decisions, so the result works for how they actually work.
Integration Gaps
Systems connected to Salesforce aren’t always well-documented. Discovering that the customer portal pulls data directly from Salesforce via an API nobody knew about—and that it’ll break in the migration—happens more often than it should. Conduct a thorough integration audit early and involve IT teams from both sides to map all system dependencies.
Governance Vacuum
After consolidation, someone needs to own the ongoing decisions about the system. Without clear ownership, configuration changes proliferate, processes fragment, and the system slowly drifts back toward the chaos you consolidated to escape. Establish governance structure and decision rights before go-live, not after.
What a Successful Salesforce Org Merge Actually Delivers
When a consolidation goes well, you feel it in day-to-day operations pretty quickly:
Centralized customer data means your team stops hunting across systems. Service agents can pull up purchase history, support interactions, and active opportunities all in one place, without toggling between tabs or asking a colleague which system has the right record.
Unified data standards put every cross-functional team on the same page. When everyone works from a single data set, you stop having the “which system is right?” argument in every meeting.
Integrated reporting replaces the Friday afternoon spreadsheet ritual. Dashboards pull from real-time data automatically, so reporting becomes something your system does for you rather than something your team cobbles together manually.
Reduced administrative workload is one of the quieter wins. One system means new integrations, process changes, and security reviews only have to happen once. The overhead of maintaining two parallel environments disappears.
Coordinated customer experience is where your customers notice the difference. When teams share notes and context, customers no longer have to re-explain their situation every time they reach a different department.
The Org Merge Benefits People Don’t Always Talk About
Beyond the obvious goals of cleaner data and better efficiency, a merge tends to surface some real secondary value:
Process optimization almost always comes with some housecleaning. A full workflow audit typically reveals that 30–50% of existing automation rules and validation logic are outdated or redundant and can simply be removed.
License recovery is often a welcome surprise. Audits routinely turn up duplicate or inactive licenses, and sometimes specialized ones (like Agentforce Sales), sitting with users who don’t actually need them. That’s real budget you can reallocate.
Feature maximization is less glamorous but financially significant. The review process frequently uncovers capabilities (CPQ, Einstein, and others) that were purchased and never fully implemented. A merge gives teams a concrete reason to finally use what they’re already paying for.
Technical debt cleanup naturally comes up during a merge. It’s one of the better moments to swap out legacy custom code for standard Salesforce features and modernize integrations that have been on the backlog for years.
Report rationalization addresses the bloat that builds up in separate orgs over time. The 80/20 principle holds pretty reliably here: around 20% of your reports are delivering 80% of the actual business value. The rest can be archived.
Integration streamlining reduces long-term complexity. Collapsing multiple connections to external systems (an ERP, for example) into a single integration means less maintenance, fewer points of failure, and a much cleaner architecture going forward.
None of these appear in the original ROI calculation, but they often outweigh the primary goals in terms of long-term value. A merge forces the kind of audit and cleanup that lets you rebuild your Salesforce environment around what you actually need today, not what piled up over the years.
When Should You Keep Salesforce Orgs Separate Instead?
Full consolidation isn’t always the right answer.
Integration and data-layer approaches, such as Data 360, can provide unified views across systems without migrating all the data into a single org. This works when you need cross-system visibility, but the business units legitimately require separate operational environments. It’s not a substitute for true consolidation, but it can bridge gaps when full consolidation isn’t feasible.
Keeping systems separate sometimes makes sense. Distinct business units serving different markets with different regulatory requirements might work better with tailored systems connected via integrations rather than forcing everything into a single system.
Delaying consolidation has costs, but so does consolidating too early. If your business strategy is still evolving post-acquisition—if you haven’t decided whether you’re building one integrated company or a portfolio of independent brands—consolidating the systems before that’s clear can force compromises you’ll later regret.
Each approach trades off different costs and capabilities. The choice depends on your specific situation and priorities.
How Long Does a Salesforce Org Merge Take?
Most projects follow a general pattern, though specifics vary widely:
Planning and discovery involve understanding what you currently have and what you need. Inventorying customizations, documenting integrations, mapping data relationships, and identifying process differences. This groundwork determines everything downstream.
Design and decision-making translate business requirements into system configuration. How should territories work? What data access do different roles need? Which processes stay as-is and which need to change? These decisions often take longer than anticipated because they surface disagreements that need executive resolution.
Data preparation includes cleaning duplicates, mapping fields between systems, standardizing values, and establishing data quality rules. The condition of your source data directly impacts the timeline—pristine data migrates faster than messy data that needs extensive cleanup.
Technical implementation covers the actual migration, configuration, and integration work. For straightforward scenarios, this is the fastest phase. For complex environments, it’s where unforeseen dependencies surface.
Testing and validation ensure everything works as intended before users depend on it. Unit testing confirms that individual pieces work. Integration testing confirms they work together. User acceptance testing confirms they work for actual business processes.
Training and rollout prepare users for the transition. Some organizations do intensive training sprints just before go-live. Others start enablement early and ramp up as the date approaches.
Stabilization follows go-live as issues emerge in production that didn’t surface in testing. Having support resources ready for the first few weeks prevents small problems from becoming big ones.
For most organizations, the timeline from start to finish runs 6-12 months. Simpler scenarios complete faster. More complex environments take longer. The companies that finish quickest typically do strategic planning and alignment before starting technical work.
Should You Hire a Partner for Your Salesforce Org Merge?
Some organizations handle consolidation entirely with internal teams. Others bring in partners. The decision usually depends on a few factors:
Prior experience: If your team has done this before, you know the pitfalls and can navigate them. If this is your first consolidation, experience matters. The learning curve is expensive when you’re learning on your own production system.
Timeline constraints: If you need to consolidate quickly (due to integration deadlines, system end-of-life, regulatory requirements, etc.), external resources can accelerate work. Internal teams often have other responsibilities that compete for attention.
Specialized expertise: Some aspects of complex merges—sophisticated integrations, custom code migration, change management at scale—benefit from specialized knowledge your team might not have.
Capacity: Even experienced internal teams have limits on how much simultaneous work they handle. Partners supplement capacity without requiring permanent hiring.
The decision isn’t binary. Many successful consolidations use a hybrid model—internal teams own the business decisions and ongoing ownership, while partners handle specialized technical work or provide advisory guidance.
The Bottom Line on Salesforce Org Merges
Salesforce org merges range from straightforward to highly complex, depending on how different your systems are and how aligned your business processes need to be. The technical work requires expertise—while Salesforce provides data migration tools, successful consolidations depend on experience with the patterns, pitfalls, and trade-offs involved.
The challenging part is usually the business layer underneath the technology: deciding how the consolidated company should operate, resolving process differences between business units, determining who owns what in the new environment, and managing the organizational change that comes with shifting systems.
Understanding what’s involved, technically and organizationally, helps set realistic expectations for the timeline, resources, and outcomes. Whether you’re three months or three years past an acquisition, facing that consolidation decision or still running parallel systems, knowing what org merges actually entail helps you make informed choices about when and how to proceed.
Getting Started With Your Salesforce Org Merge
The gap between “we need to consolidate” and actually starting the work often comes down to one thing: turning vague goals into concrete decisions.
Coastal created the Salesforce Org Merge Decision Framework to help companies bridge that gap. The framework walks through six decision areas that need resolution before technical work can start—things like how brand architecture affects data boundaries, which workflow rules need to be locked in before configuration, and how to assess change readiness across the organization.
It’s designed to help leadership teams move from broad mandates to concrete answers, which is typically what determines whether consolidation projects stay on track or stall for months in planning.
