|
Author: David Masri Founder & CEO |
I've been in the CRM space for nearly 15 years, when I started most of my projects where from clients looking to implement a divisional or enterprise-wide CRM system for the first time. Often, they had salespeople using scattered processes, tracking leads in and contacts in outlook or some other rolodex type software. More sophisticated sales people would have a personal CRM, usually ACT!. As time passed a larger percentage of project work was migrating off legacy CRMs that lost or failed in the marketplace, or simply moving away from bad implementations of more mature CRM systems.
Currently we are seeing a major uptick in Salesforce-to-Salesforce Data Migrations, commonly referred to as a Salesforce Org Merge. In my opinion this is (primarily) happening for one of two reasons.
Reason One: The business world is full of mergers and acquisitions, but with the increased adoption of CRM, and with Salesforce dominating market share, it's becoming increasingly common for the two merging companies to have a mature CRM system, and for that system to be Salesforce.
Reason two: Historically CRM was often implemented at the division level by a group of non-technical business users without the input of IT (Cloud based systems made this possible, and quite frankly some went with a cloud system because it allowed them to avoid talking to IT). As time passed larger organizations found themselves having to support multiple CRM systems. Corporate IT decided to take control of those systems away from the business users and manage them properly, using IT best practices. At this point it became clear that there is data duplicated in all these systems, there is no central point of truth, and often they can’t be used for customer service or marketing, because those activities really need to be at the corporate level. So, IT decided to bite the bullet and roll out an enterprise-wide CRM system. Again because of Salesforce dominating market share, it's very common for a large organization to have several (sometimes dozens) of Salesforce Orgs.
This article aims to walk you through exactly what need to be done to merge 2 (or more) Salesforce orgs into one, and what pit falls to watch out for.
You want the core stakeholders of each of the Orgs to be merged working as a team, communicating with each other, and working towards a common goal. This is a project that's goal is to better unify the people in the company, not just a software platform and/or processes within the company. This committee is the start of that and will be a driving force in implementing, first a unified vision and goal, and then a rollout of a CRM system that supports that vision and goal.
Once you have your committee in place, work with them to fully understand the current system landscape, ask the following questions:
This list is by no means exhaustive, but you get the idea.
Once you have a full understanding of all the systems and business processes in place, you can look at all that info and decide what processes can be unified/ standardized across teams. Also, decide if (individual system) roadmap items can be implemented as part of the unification process as opposed to unifying a soon to be deprecated process.
It's important to understand that it's very difficult (often impossible) to roll out an MVP (minimum viable product) when replacing legacy systems. Loss of functionality, i.e., making users lives harder is a tough thing to swallow even for a short period of time. If one team's priorities constantly win over another's, some users will be left feeling like they don’t matter. Rely on your stakeholder committee to sell change to individual teams and listen to their concerns.
If a system owner says a process won't work, see what you can do, maybe partially standardized. Not everything can be standardized ,and that's ok.
Some of your Salesforce orgs will have security configured so that data is segmented by teams or roles, when you merge orgs, you need to understand what data security will look like in a unified org. Even if none of your current orgs have any row/object security whatsoever, that may need to change when that data would now be accessible by whole new groups of people.
If you have very harsh data security/segmentation needs, it may be wise to NOT merge orgs at all. For example, if you currently have a North America Org, a Euro Orga, and an APAC org, and there is no overlap of users and data is not allowed to be shared across regions, there is very little benefit to merging these orgs. Sure, management may want consolidated reporting, but that can easily be handled outside any of the Salesforce orgs (by means of an external BI system, or even within one of the Salesforce orgs via Tableau CRM with cross org connectors).
Now that you understand your new unified processes you can determine which org is best to migrate to. This can be the existing org that most closely aligns to the new unified processes, or it can be a brand-new org.
At this point you should have a solid understanding of what your new Salesforce system will look like. So, it's time to think about data unification and migration. By unification I mean 2 things, a unified standard data model and matching of records across systems (record unification).
Most likely there will be common records at the Account and contact levels (and probably a few other objects such as products) across your Orgs. Those records will need to be merged into a single record in the target systems, then all child records related to merged records will need to be created as children of the new merged record. (Techniques for matching records across orgs is outside the scope of this article, perhaps I'll cover it in a future article.)
Within the individual orgs, you may have custom objects that have been created in the various systems that may or may not have counterparts in the target org. Regardless a new data model needs to be built that takes into account all the needed fields from all the orgs to be merged. This is not something to take lightly, you cannot imagine how often I have seen fields created haphazardly simply because they exist in a source org, without any consideration as to if they are needed, or if they exist under a different name in the target org. You will need to map your fields for every object you are migrating. Keep the following in mind when performing your mappings:
Next up is to make sure you users and management understand how these changes can affect reporting. As you can imagine unifying all the field definitions can mean defacto changing the definition of KPIs. If you salespeople have targets based on Opportunity data or activities, and those definitions change, Management may need to rethink their KPIs. This is often a big topic of conversation with org merges, and it can get heated.
Great! The hard parts done (not really, planning is the easy part, doing is much harder)! Now you need to get this in a project plan. Generally, I recommend two tracks running in parallel, a Salesforce build track and a data migration track. With the data migration track running one or two sprints behind the build track (build objects and automation, then migrate to those objects). You will need a full sandbox, especially if you are merging into an existing Org. Unfortunately, a full sandbox is the only way to fully test your new Org with all the data matched and merged exactly as it will look once you push everything to production.
As mentioned above, going with an MVP approach for these types of projects is often not an option, so be prepared for a "Big Bang" product launch. That means lots (and lots, and lots) of QA and UAT.
You've got your roadmap, all that's left to do is to assemble your team of all stars (or reach ou to us and we'll help you find the right partner!) and get started!