VP of Marketing
Hayley Coxon is the Vice President of Marketing and Revenue Operations for Prodly and accidental admin since 2010. You can find her on LinkedIn.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
Make a list of the systems the consolidation will impact. This will include your core Salesforce Clouds, as well as:
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.
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?
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.
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.
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.
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.
Perform the following steps to carry out the org consolidation process:
Congratulations! You have successfully completed the org merge!
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.
The gold standard for documenting SOX in Salesforce CPQ!
