Salesforce org merges are complicated but often necessary processes that involve combining one or more production instances of Salesforce. In this blog, we discuss everything you need to know about them, including what they are, what they involve, and four reasons to merge Salesforce orgs. We’ll also list what information to gather before a Salesforce org consolidation, how to prepare for a merge, and we’ll discuss how to merge Salesforce instances.
What Are Salesforce Org Merges?
A Salesforce org merge or org consolidation occurs when a company decides to consolidate two or more instances of their Salesforce CRM. You combine the integration of the various technological backends of these orgs into a new whole.
Oftentimes, these orgs are highly customized, with thousands of users, a significant amount of process automation, custom objects, Visualforce pages, Apex code, third-party apps, and more. Because of this, you have to sort through everything carefully to see what’s necessary and you need to keep, what you can improve, and what you no longer need.
What Does a Salesforce Org Merge Involve?
On the surface it sounds simple, but in reality, performing an org merge in Salesforce is highly complex. To do it correctly and to the benefit of your business, you have to decide how to merge two orgs with different processes, objects, fields, data, access levels, and so on.
An org merge tends to be a period of deep reflection and reevaluation of how you’ll leverage Salesforce to support the business’s growth going forward.
Typically, you select one of the orgs as the surviving org. However, you might choose to combine multiple production instances of Salesforce into a new org.
Either way, parts of the legacy org often survive the process. Perhaps the legacy org had a better solution for a shared business process or solved an issue that the surviving org never encountered. That’s why you need to merge any data you want to keep from the legacy org into the surviving org.
4 Reasons to Merge Salesforce Orgs
Because org merges are so involved, companies usually only perform them for four reasons: During a corporate acquisition, to reduce technical debt, to eliminate silos between teams, and to manage costs.
1. Corporate Acquisition Org Merge
A corporate acquisition is the most common reason for performing an org merge. When one company acquires another and they both use Salesforce as their CRM, they need to integrate their systems to fully integrate the company.
After the merge, there can only be one source of truth. That’s why you designate one Salesforce production instance as the surviving org.
2. Reduce Technical Debt
Another reason for merging Salesforce orgs is to reduce accumulated technical debt. Business changes rapidly, and decisions, processes, and workarounds that made sense last year might now be obsolete. When you perform an org merge, you can select what to keep, and what to discard.
In fact, companies that have accumulated significant Salesforce tech debt after years—or even decades—of using Salesforce may find it easier to start over fresh in a brand new org than try to unwind legacy processes. In this case, they save specific processes, optimize them, and move them to the new org. This is called the Greenfield approach.
3. Eliminate Silos Between Teams
At the same time, you might have originally had valid reasons for separate business units to operate in their own individual Salesforce orgs. However, today, it could be inhibiting greater collaboration.
4. Manage Costs
An org consolidation allows you to run your business more efficiently, because you can assign tasks across groups, run consolidated reports, and have one org as the single source of truth. You can also save money on duplicate license costs for any users who need access to both original orgs; plus, you have lower costs for setting up and managing the same or similar fields or processes in both instances.
This is ultimately a considerable cost saver. Learn more on saving on Salesforce sandbox spend.
Information to Gather for a Salesforce Org Consolidation
As we’ve discussed, a Salesforce org merge is a considerable undertaking. That’s why it’s wise to be as organized as possible before you begin. And good organization starts with information gathering. Answer the following questions:
- What do you hope to gain from the org consolidation?
- How many orgs do you need to merge? What are the editions of each?
- Do the orgs have a Classic or Lightning Experience UI?
- How many licenses are there in each org, and what types are they?
- Will you add to or subtract from the current number and types of licenses?
- Which third-party applications are currently installed in each org? What are their expiration or renewal dates? Which ones will you continue to use?
- Do you have a predetermined surviving org?
- Does the new org have sufficient file and data storage?
- Which data are you consolidating? All of it, or only specific records and objects?
- What duplicate content do you need to take into account?
- What automations and integrations are in place in either org?
- Will you need to provide training for users post merge?
- Do you want to preserve change histories and stage histories?
- How will you handle private views, dashboards, and reports?
- Do you need to preserve system audit fields?
- If there are inactive users, how do you want to handle them?
- Do you need to update sharing rules for the surviving org?
- Do you need to deploy special features like multi currency, multi language, or territory management?
- What is your timeline for the project?
- Do you have the resources in place to handle this merge project?
How to Merge Orgs in Salesforce
Each org merge project is unique and will have specific criteria for success, but the overall process is the same. Whether you complete the consolidation yourself or hire a consultant to do it, here’s how to merge orgs in Salesforce.
1. Prepare for the Org Consolidation
A. Create a Plan
Start by putting a plan in place, along with a realistic timeline. To determine your timeline, consider both your company’s needs, as well as license expiration dates.
It can also be useful to establish a Salesforce Center of Excellence to lead the initiative.
B. Build Your Team
Org consolidation is not a one-person job. It’s critical to engage your stakeholders early in the process. In addition, make sure that each team that will be impacted by the org is represented.
On the technical side, you’re going to need someone who understands the data structure of both orgs. This person should be able to make recommendations on the best way to map the data from the legacy org to the surviving org.
C. Assess What Systems the Merge Will Impact
Make a list of the systems the consolidation will impact. This will include your core Salesforce Clouds, as well as:
- Additional Salesforce Products (Pardot, Field Service, etc.)
- Custom objects
- Apps from the AppExchange
- Integrations to systems outside Salesforce (ERP, sales engagement, advertising platforms, web-to-lead/case forms, etc.)
D. Document Requirements
With all the information from the previous section at your fingertips, it’s time to list out the requirements for the org merge. Think also about things such as the length of time you’ll need to store data from the legacy org that you’re not consolidating, how processes will change, and what your testing plan is.
E. Create an Org Merge Strategy
You absolutely need a strategy to effectively complete the consolidation. Due to their complexity, org merges take time and multiple sprints. However, that doesn’t mean all work in production grinds to a halt.
Determine which sandbox to use for staging the org merge before deploying it to production. How will you keep the staging environment current with changes and hotfixes in prod? Do you have an easy, repeatable way to seed the sandbox with data (and possibly even metadata) without having to do a refresh that overwrites the org merge work in progress?
2. Build Your ETL Logic
ETL (extract, transform, load) is the process of taking data out of one system, cleansing it, and moving it into a new system. Mapping out your ETL logic is the key to a seamless org merge, so make sure to allocate this step the time and attention it deserves.
A. Map Objects Between the Two Orgs
Start by mapping objects between the surviving org and legacy org. Which objects do both orgs have in common? Which legacy objects will need to be mapped to existing objects in the surviving org? Will new objects need to be created in the surviving org so you don’t lose data?
Also, consider which objects should use audit fields for accurate reporting. For instance, if you’re not careful with Opportunities, you could make it appear that you created and closed the legacy Opportunities on the same day. This would completely invalidate your average sales cycle.
B. Check Field-Level Mapping
Now you’ve mapped the objects, it’s time to think about field-level mapping. Now the objects match, do their fields?
If not, is the data needed in the surviving org? If so, should the field be mapped to an existing field or recreated in the surviving org?
Pay attention to picklist values and any data standardization in the surviving org. Loading incorrect formats or values will impact reporting, validation rules, and general user experience.
For example, let’s say the surviving org uses Enterprise Territory Management to assign territories based on a two-letter state or province code. In this case, the legacy values should be transformed before loading, otherwise the legacy accounts won’t be assigned correctly in the surviving org.
3. Execute the Org Merge
With all the preparations complete, it’s time to perform the actual merge process. Remember: You’ll need to keep the legacy org operational until you’re ready to fully transition users to the surviving org. This means you’ll have to run through the org merge steps multiple times to make sure you’ve caught all new and updated records.
A. Steps for Executing an Org Merge in Salesforce
Perform the following steps to carry out the org consolidation process:
- Provision a sandbox from your surviving org, seeding any data from the surviving org if needed.
- Configure any new objects, fields, and apps that you need in the surviving org.
- Extract and load your legacy data into the sandbox, transforming it per your ETL logic.
- Test, test, test! This should include unit testing and UAT in the sandbox.
- Train users on any changes to processes.
- Deploy your metadata changes and records to production.
- Review all deployments. Remedy any errors, and redeploy if necessary.
Congratulations! You have successfully completed the org merge!
A Final Word
Keep in mind that the type of integration needed and your stakeholders’ requirements will dictate when you can start making changes. The earlier you can transition integrations that create or update records, the fewer times you’ll have to run through the org merge process.
However, this isn’t always possible. For instance, you can’t update your legacy web-to-case forms until you have users who can resolve customer issues actively working in the surviving org.
Prodly DevOps can help seed your sandbox, as well as automate the entire work migration process quickly and compliantly during an org merge. Check out our FREE on-demand webinar, Easier Org Merges, to see how we can help you prepare and perform your next org merge.
What is a Salesforce org?
A Salesforce org is a dedicated instance of the Salesforce platform where you store and manage your organization’s data, configurations, and customizations. Each org has its own set of users, data, and security settings and can be customized with various apps, objects, fields, workflows, and integrations.
How does a Salesforce org merge reduce technical debt?
When you consolidate two or more Salesforce orgs, you can significantly reduce technical debt by consolidating data, reducing the number of customized components you need to maintain, and minimizing the number of apps and integrations you need for your surviving org to function optimally. Learn more about technical debt in Salesforce.