Now that you have decided to take on a data migration project as part of your tech stack consolidation effort, and thought through how to prepare for the initiative, let’s talk about what the actual data migration process entails. Note again that data migration is often only one piece of a comprehensive tech stack consolidation effort.
There are four foundational elements to every data migration effort:
For some companies, a data migration project into a target Salesforce instance is all that is required (i.e. the acquired company shares a similar process as the acquiring company, or the acquired team will conform to the process of the acquiring company.) However, if you are seeking to true up the difference between different processes, build a newer and better set of processes for all teams involved, or accommodate multiple ways of handling business in one Salesforce instance, we’re talking about a full blown tech stack consolidation project. Sometimes, your company is on such a growth spurt that you’re looking at multiple sets of data at a time, as in the case of multiple acquisitions. You’ll want experienced experts on your team. OpFocus’ team of business growth experts stand at the ready to help. We’ve overseen dozens of mergers and migrations, and can help you avoid the pitfalls.
When you begin your data migration project, the first step is configuring the system. To start, you’ll want to assess the architecture of the receiving Salesforce instance, which involves reviewing the Objects in use, Record Types, Page Layouts, Validation Rules, the data structure of the migrating system, and whether the migrating system is a Salesforce instance or other structured database.
In addition to conducting an inventory of Fields and Objects, reviewing overall security, strategy, and policies is essential during this phase. For data security, Salesforce provides great visual content to better understand its data model.
As an overview, there are 3 basic structures to how Salesforce stores data:
To complete the data mapping portion of the project, review each level of the data model for each system, and then compare/contrast where the data access is different. Your data migration team will need to thoroughly understand the visibility of the components above, and determine which dataset requires transformation to fit into the other system’s data structure.
Here is another way to understand the different layers of the onion.
Once this work is complete, you should have a solid understanding of the types & format of data you’re working with. This will also give you the opportunity to decide how to set up security and permissions in the combined tech stack. Once completed, it’s time to review your Tech Stack & Custom Integrations.
After determining the delta between the two data structures, you’ll want to look at external apps that write or read data in your system. Start by creating an inventory of all the applications and Managed Packages that make up your tech stack. This inventory should capture all the tools your team is actively using, and validate whether you plan to bring those same tools and integrations over to the target system.
During an engagement with OpFocus, we will make recommendations to consolidate and retire certain items in pursuit of a streamlined, non-duplicative tech stack. You may want to create an Excel/Google Sheet with labels for each “product,” “install date,” “current version,”and “comments” for how each team is using each tool. You’ll also want to consider whether it is necessary to maintain those tools and integrations as part of the migration.
*There could be scenarios where we are unable to migrate all data due to limitations with the Managed Package. It is critical to understand the limitations early on in the process.*
There are many resources online for the analysis of your tech stack. Even a Google Sheet or Excel file to track the dependencies would work if your systems aren’t overly complex. However, visualizations are a great way to help your stakeholders understand the interdependence of the tools. Cisco and Scott Brinker have done a great job sharing their methodology. Image and link to their blog is below:
After this assessment, your team will have a complete inventory of the tools that make up your tech stacks. This information will prove useful when you arrive at the decision of determining which tools to carry over to the new tech stack and which to retire. After this evaluation is completed, you’re ready to move on to the State of the Data portion of the data migration project.
You’re now ready to evaluate the current state of your data. This process involves the actual records that are in the system we are extracting from, and can come from systems like Salesforce, Pardot, Hubspot, Marketo, Dynamics 365, or even a custom CRM! Each of these systems have different data structures, data types, and naming conventions. Depending on where it’s stored and how it’s stored, the process can be more or less challenging.
We recommend reviewing an excellent article Salesforce put together on 5 Ways to Measure the State of Your Data.
When thinking about the data, it’s important to understand how your objects have been set up. This analysis takes a slightly different perspective than the process we described in the data visibility section.The point of the object design review is to raise awareness around the structure/data design.
Some of these design aspects are:
You are only as efficient and as good as your data. This step is critical in enabling your Users to have data that is easy to understand & work with in the target system. Failure to do so results in a lot of User frustration. Some examples we’ve heard include Users asking, “Why is this missing?” “This field used to have data.” “Why is _____ data missing from my Opportunity records?”
Understanding & cleaning your data is a collaborative effort. This step of the process is a great time to understand what has historically made your system data inaccurate or error prone.
As we like to say: fix bad data today! For more trustworthy and dependable data, build in parameters within Salesforce to prevent duplicates and poor data quality. Properly deployed, Validation Rules and Required Fields on the Page Layout (we don’t recommend universally requiring a field unless absolutely necessary.. and times are few and far between) will save you data headaches down the road. Once your database is clean and you’ve set up your target org for data success, you’re ready to begin the process of Data Mapping.
At this point, you are well on your way to completing your data migration project! The next step is data mapping, which will require the most active involvement from your stakeholders. Even though this is #5 on our list, we typically start this process on day one due to how labor intensive this process is.
In short, data mapping is the process of taking inventory of all system fields and making decisions on how those Fields will be named and behave in the new environment.
Data mapping helps to determine what Fields are the same between the two (or more) org(s), which Fields are different, and the specific values within the Fields. If you’re working on a project with OpFocus, we will provide worksheets that help your team review and consider the future state of all Fields, and to ensure that your key business processes and metrics are available once the consolidated tech stack goes live.
When mapping the data, you can decide between using more simplistic tools such as Excel to do a database extract or sophisticated (paid) tools. Which approach should you take? These questions will help you determine the best path forward:
Once you have determined your needs for the mapping, you can think about the 2 options we mentioned above. There are Excel templates out there for data mapping, or you can create your own. As far as purchased tools go, we have used a number that worked for different customers’ needs, including:
Needless to say, using a tool can help simplify the process of data mapping when working with more complex organizations.
During data mapping, there are 5 steps per object you’ll want to create columns/sections for:
Data mapping is one of the most important aspects of the Data Migration process and will set the foundation for your new organization to build off of. Ensuring your data is cleansed and mapped appropriately will provide a clean environment for your new organization. If you need help with any of these elements, reach out to our Tech Stack Consolidation experts to chat about how we can support this critical initiative. We’ve worked with many rapid-growing SaaS teams and can help you avoid pitfalls with these complex projects!
Sign up for weekly OpFocus blog updates!