This article is part two of a joint blog series with Simplus on things to consider when merging Salesforce orgs after a merger or acquisition. For an in-depth discussion on this topic with industry experts, register for our virtual event on February 10.
As valuable as Salesforce is as a customer relationship management system (CRM), it becomes even more essential when you take advantage of its many built-in integrations. For example, marketing teams can use Salesforce Pardot and Marketing Cloud to manage marketing activities and centralize their customer relationship management. These tools work seamlessly with Salesforce from the get-go. In addition to these built-in integrations, organizations can also integrate apps and systems that aren’t native to Salesforce. The Salesforce AppExchange features a massive library of applications, components and solutions to address almost any need within Salesforce.
Together, both these native systems and outside applications can help you get more out of your Salesforce platform than you otherwise could. When it comes to merging Salesforce orgs however, integrations and applications can add an unexpected layer of complexity to the process. Altering integrations during the org merge can create unintended changes to existing processes you have set up in Salesforce.
Here are a few best practices to help you navigate this process.
The first thing you’ll need to do is consider all the integrations from both orgs and which ones are similar. Can these be merged into the same middleware or direct API integration? If so, will it affect any processes already in place?
It’s not as simple as just disconnecting integrations from the old org to the new one. These are live production integrations which need a careful transition process, timeline, and communication to cut over at the right time with proper preparation. Don’t be surprised if merging these integrations requires some change management and training, as well as delta migrations so you can keep the system up and running as much as possible.
If you’re worried about how these integrations might affect your live data and metadata, consider first testing in a sandbox. This environment is a complete duplication of your production Salesforce environment, including all configuration, code, and data, and will ensure that all issues are exposed early. Testing in a sandbox will allow you to make any required fixes easily before they cause errors in production.
Just as both orgs will have existing integrations, you’ll likely each have an abundance of apps and components that may or may not need to be included in the merge. Consider breaking this project down into two parts.
First, identify apps that are in either source org. It’s important to take stock of what you have, what you need, and what you actually use. Just like in your home, your Salesforce org will accumulate clutter over time, and one common source is installed apps and packages. An org merge is an opportunity to do a little cleaning up. But before you get started, make sure you talk to your fellow users, admins, and developers. You don’t want to accidentally delete something that someone is, in fact, still using.
Once you’ve done that, you may find that you have some of the same systems or apps as the org you are merging with. These should be thoroughly mapped out to ensure as standard a process as possible in the usage policies to ensure a consistent user experience, good data, fewer administration issues. Some may require end of life or transition processes to be put in place. Licenses are another consideration, as well as contract terms and lengths which will need to be analyzed and either co-termed or renegotiated.
While it is possible to manage all of your various integrations yourself, it will be difficult unless you have significant technical knowledge and the resources to maintain an integration long-term. Luckily, there are tools available to help...just choose wisely.
The Data Loader is a commonly used data migration tool, but for integrations it will be difficult to automate. We also don’t recommend using a different middleware for each integration, as maintaining mixed tools can become a nightmare.
Instead, choose an integration tool robust enough to merge most or all your integrations into a single tool, like MuleSoft for example. MuleSoft makes it easy to connect any application, data, and device with APIs, or Application Programming Interfaces. By using a modern API-led approach, each integration becomes a reusable building block. This process enables organizations to accelerate IT delivery, increase organizational agility, and deliver innovation at scale.
NOTE: We’ll cover this in greater detail in a later post, but it’s critical to have a backup solution in place before, during and after making these changes. It’s important to establish a baseline before any changes are made, roll back any changes during the process, and capture all of the daily activity after the merge.
When it comes to merging your integrations, and your org merge process in general for that matter, don’t work in a vacuum. Before merging integrations, be sure to talk to stakeholders on all sides. Like with any major change to your Salesforce org, don’t assume that something is necessary or unnecessary without walking through real world scenarios with all parties before planning your strategy.
For a more tactical tip, choose only one channel of communication with your implementation partner. With daily communication between Slack, email, and Chatter, it can become difficult to find files or conversations. Having one channel of communication is any easy way to prevent this issue.
Our next blog in the series, written by our partners at Simplus, covers the logistics of an org merge, including time, scope and team. Read it here!