Gluon Digital

Offical carrier of the Strongforce

Planning a Salesforce-to-Salesforce Data Migration (Or Salesforce Org Merging)

Planning a Salesforce-to-Salesforce Data Migration (Or Salesforce Org Merging)
David Masri         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.

Step 1: Assemble a stakeholder committee

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.

Step 2: Understand the landscape and roadmap of each team

Once you have your committee in place, work with them to fully understand the current system landscape, ask the following questions:

  1. How many systems are out there?
  2. Who are the users?
  3. Are these users doing CRM work in other systems (i.e. HubSpot, MailChimp)?
  4. Maybe we need to unify those too.
  5. What custom apps are installed?
  6. How much custom code is there?
  7. What integrations are in place (both inbound and outbound)
  8. What functions are they using the system for? Is it Sales, Marketing, Customer Service, all three, Others?
  9. You also need to understand what's on the roadmap for these systems, if there are major or even minor releases/upgrades planned.

This list is by no means exhaustive, but you get the idea.

Step 3: Determine your process unification strategy

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.

Step 4: Understand individual teams data security needs

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

Step 5: Decide on a target Org

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.

Step 6: Determine your Data unification strategy

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:

  1. When corresponding records exist in multiple systems, how do you handle conflicting data?
  2. Who becomes the new record owner?
  3. What record type conversions are needed?
  4. How does specific field values impact workflows, triggers, and process builders?
  5. What about things like Opportunity Stages and Activity Types? These all should be unified
  6. For numeric fields, how are they used in formulas, and do they mean the same thing in the various orgs? Simple things like Opportunity amount can mean very different things in different Orgs. Does it mean customer Lifetime value? Contract Value? Monthly recurring value? Annual recurring value?
  7. Picklist values should be unified, do not create multiple values that mean the same thing.
  8. When there are conflicting 3rd party apps that do the same thing, you will need to pick one and then learn how to migrate the data from one to the other.

Step 7: Understand the impact on reporting

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.

Step 8: Assemble your Roadmap

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.

Step 9: Assemble your Implementation Team and get started

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!