Salesforce org merges 101

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, each org is 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 to keep, what to improve, and what to retire or archive.

What does an 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; the org that will contain your entire Salesforce CRM after consolidation. 

The legacy org—the other original org—will be retired. However, 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.

On the other hand, you might choose to combine multiple production instances of Salesforce into a new org. This means neither of your legacy orgs will survive the process.

4 reasons to merge Salesforce orgs

Because org merges are so complex, companies usually only perform them for four reasons: 

1. Corporate acquisition
2. Reduce technical debt
3. Eliminate silos between teams
4. Cost management

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.

‍

5 tips for saving money on Salesforce sandboxes

‍

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

• 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. 
• 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.
• 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:some text
  • 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.)
• 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.
• 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?

You might also like: How to prepare for a Salesforce org merge - FAQ

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.

• 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.
• 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.

7 steps for performing an org merge

1. Provision a sandbox from your surviving org, seeding any data from the surviving org if needed.
2. Configure any new objects, fields, and apps that you need in the surviving org.
3. Extract and load your legacy data into the sandbox, transforming it per your ETL logic.
4. Test, test, test! This should include unit testing and UAT in the sandbox. 
5. Train users on any changes to processes.
6. Deploy your metadata changes and records to production. 
7. Review all deployments. Remedy any errors, and redeploy if necessary.

Congratulations! You've 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.