Since I’m now migrating NodeGraph’s processes to Qlik, I thought it may be a good time to talk about migrating data during a merger or acquisition. There are many aspects to consider. Here are some of my thoughts on why companies merge or migrate data landscapes, common M&A migration pitfalls and how to avoid them, the time and cost involved migrating data during a merger or acquisition, and other topics.
When to migrate or change a company’s data landscape
When it comes to mergers and acquisitions, they are driven by an agenda of growth. You’re often trying to merge departments to increase efficiency and decrease costs. From the data migration perspective, it’s crucial to ensure that the data landscapes are united in such a way where all the data and KPIs follow the same logic.
Common pitfalls in a merger and acquisition migration project
When you merge data landscapes, it’s often extremely complicated. It’s crucial that you, early on in the process, understand what impact the merger is going to have throughout your entire data landscape. This is why it’s entirely necessary to establish a thorough overview of your landscape, including all its integrations, before tackling this type of migration.
It’s also quite common that the companies in question have different ways of measuring, using and calculating data. This presents a further challenge as it is entirely essential that the final landscape adheres to only one type of logic.
From an early stage, before the merger has even taken place, you need to be able to evaluate and validate the figures that are presented to you – so you can properly determine where the KPIs actually come from, how they are connected, how they are calculated and how they are interpreted.
Estimating the cost and time needed to migrate data during a merger or acquisition
This entirely depends on the size and complexity of the data landscapes in question. Another important thing to consider is the innate compatibility of the landscapes. Are the companies using similar systems from the get-go or will further migrations have to take place to achieve the final result (e.g., BI or ERP migrations)? A good place to start is by mapping the landscapes in order to fully understand what it is you are dealing with.
It’s also quite common that an organization has built in-house add-on systems, e.g., time reporting, budget forecasting system, etc. These types of systems can be difficult to identify in advance and often come as a surprise when you are already midway through the project.
It is also important to look at the long-term effect of a project. Data quality, data cleaning, mapping and documentation are key factors for an efficient project. If that is not properly done from the beginning, further problems and costs will occur later.
Discovering bad or outdated data, undocumented data relations or other “surprises” in the process
Unfortunately, surprises like these happen a lot – especially when you are dealing with two or more separate landscapes. Usually, when you choose to embark on any type of migration project, you will use that opportunity to clean your data.
The largest challenge here is to ensure that everything flows smoothly throughout your entire landscape. As you begin to merge your landscapes, you will need to first map the individual data environments in order to fully understand what elements will be affected by the migration and what will need to change to match (i.e., properly integrate with) the new combined landscape. Ultimately, there is a lot of impact analysis that needs to take place before anything can be migrated.
But manually mapping these landscapes and their dependencies is very time-consuming, and you also don’t get a comprehensive overview of the entire solution. So it’s important to have an automated solution that can help you instantly see where all the dependencies exist.This is virtually impossible to do if you are manually recording each data element.
The ROI in migrating data during a merger or acquisition project
IT projects generally tend to become larger than initially predicted. And, I think this applies here as well. Subsequent needs for further investment often stem from bad project management and incorrect prioritization.
But instead of trying to calculate a specific number, you can look at it in terms of the number of resources you were allocating to different BI tools and teams, as well as different data landscapes prior to the migration. This acts as one parameter. But another important thing to consider is the quality of your solution(s). By uniting all the data in one landscape, you can ensure that you are basing your business decisions on the correct KPI (rather than having two or three separate versions to choose from).
Ultimately, I would say the ROI is split between directs savings, less software and manpower costs, and (perhaps most importantly) indirect savings, as well as the quality of your data solution.
Improving the project’s ROI
When it comes to migrating data during a merger or acquisition, it's necessary to start off by understanding and mapping the individual landscapes that are to be merged. How do they work individually and what are the potential challenges involved in ensuring that they will work together? Can the integrations in each of the landscapes remain the same throughout the migration process or will the new environment require additional storage points (e.g., a data warehouses or data lakes) that will prepare the data in the correct way?
Ultimately, I think the key to maximizing ROI and success lies in automating the mapping of your current data landscapes, as well as employing a documentation process that is automated and up to date.
Migration projects – Leaders and roles
The CEO or CFO are typically involved in the early stages of a merger or acquisition, focusing on investigating company figures and the true value of the business opportunity. After the merger has been finalized, you would typically need two CIOs whose primary focus is collaboration. It’s also important that the project is supported by top management because you need to have full transparency into a system when merging and migrating.
Basically, there are a lot of people that need to be involved in a project this massive. And, one of the biggest problems that arise when a lot of people are involved is, of course, human error. That’s why it is very important that the companies in question choose to be data-driven and employ data tools and automation wherever possible.
Top challenges when merging data landscapes
Getting people to collaborate and unite as one is probably the hardest part. Furthermore, companies often lack a strong data governance framework, which can lead to overall data quality and documentation challenges.
Work with trustworthy, up-to-date data
It’s important to ensure that your data is always up to date so it can set the foundation on which to start building your combined data governance framework.
It’s also worth considering the data that led to the merger/acquisition in the first place – and whether this data was actually trustworthy.
Using your BI tool as a data collector
This is not something I recommend. Using a BI tool to collect the numbers will be manual and very time-consuming. If the merger/acquisition is international, this method might also see companies encounter language barriers in the form of country-specific systems, explanations and documentation.
The need for strong governance
When it comes to more long-term wins, ensure you have a strong data governance framework. With the knowledge that your data is always accurate, along with the ability to track your data throughout your landscape, you are able to build a solid foundation for high-quality governance.