In the rush to close a deal, identity and access management (IAM) becomes the single most overlooked risk in M&A, putting millions in expected synergies on the line. While the C-suite focuses on strategic growth, the failure to properly integrate the new users and applications is where post-merger plans most often break down. Before you map out data migration, you must first align your technology plan with the core business driver of the acquisition
When thinking of the integration, this is where the branding and culture fit begin to take center stage. To the extent that any form of tech get involved, it is how to migrate the data into our ecosystem. If there is any special software, the synergy conversation starts with: do we need it, and if so, how do we bring it over quickly without touching it?
From a business perspective, this makes sense. We need to ensure the corporate culture fits for those coming on-board so they can be happy and productive. We also need to ensure the migrated customers are reassured for retention while wowing new prospects. The IT stack is there to facilitate the rest otherwise it gets in the way.
Yet, I am willing to bet that tech stack post-acquisition will have the greatest impact on the synergies you are planning to realize in addition to the other primary focus.
Let me break this down:
- Data migration will impact the users both employees and customers
- The app migration will definitely not be a “lift and shift” operation
- Cost savings can be realized by consolidating apps and functions, but be prepared for some work
Bear in mind, I will be addressing these points from the user migration and interaction standpoint. There will be other facets to consider, but the underlying premise should be the same.
First, a warning
Before addressing the above list, we must make sure everyone is on the same proverbial page when it comes to the purpose of the merger or acquisition. The reason being that this strategy will dictate not only what data and apps get migrated, but how.
For the clients I help, they are very inexperienced at this part and they will start looking at how to migrate the users, data, and apps first starting with user counts, tech stacks, and spending millions of dollars on infrastructure.
This is how you negate any savings and ensure the acquisition stays in the red long after the deal is done. Both in time and money.
The focus will be on the how and not the why let alone the what.
For example, if you are looking to grow by acquiring talent and customer base versus buying a company for the IP, then that radically changes where your focus will be, and on what questions you should ask next. Both will involve migrating data, but the type of data will be different. Additionally, to the extent that major infrastructure needs to be brought online, it would be to handle the influx of new customers.
Very different from entering into a new market vertical where you will want to bring over as much as you can (including the apps) and have a dedicated transition plan for the customers.
With the warning out of the way, here are the spots that could have positive impact on the synergies
Focus 1: Mitigating User and Customer Disruption
While everything is data, user’s fit into a special bucket of actionable data. Additionally, they can be grouped into at least three buckets:
- Your employees
- Your customers (clients)
- Your partners (vendors, contractors, etc.)
Depending the intent of the merger or acquisition will determine:
- If these users will need to be migrated
- Where will they be migrated to
- How to handle their transition
For the employees, there will be the ERP and payroll systems as the obvious first systems. Then there is the user management system that handles access to all of the various applications. For the custom apps, they will normally live in some kind of database like Oracle. Note that I’m not including data lakes or warehouses in this write-up as they serve a different purpose, but they will also need to be accounted for.
For the clients or customers, they will usually reside with the applications d, but sometimes will be in their own cloud or on-prem database like Okta.
For the partners, they are more of a hybrid class where they could be treated as both an employee and vendor (in the case of contractors), distributor and vendor (independent sales channel such as Shopify or Amazon). Some of these will be treated as independent users, others could be a common user corresponding to sales channel, and the rest could be programmatic access.
Each of these types will have their own systems that determine what gets migrated an how. The costly mistakes:
- Bringing over the custom apps and users that you don’t need because it doesn’t fit the focus of the acquisition
- Not taking the user experience into account (for each group) resulting in gaps on how the users will continue to access their apps or be on-boarded to your ecosystem
- Not accounting for the initial on-boarding experience (first time events such as everyone logging in for the first time or first major milestone)
However, when done correctly, you will have minimized your maintenance costs (using what you already have instead of “lifting and shifting” everyone), minimized your license costs (bringing over just what you need), and minimized your reputational impact with a rough day 1 experience.
So now we return to what ultimate goals are for the merger or acquisition. This will help identify which systems these users live in, and what to do about them.
When it comes to transitioning them, this will either being migrating the users directly into your systems where you will export them and re-import them, or you will migrate them with their custom apps.
The common approach for handling at least the user migration case is to dump them into a spreadsheet and then re-import them. However, there maybe times where you will need to import them to get things ready for the big announcement. In those cases, you may need a more complex import tool. These days, you can use Generative AI to create the script to extract these users, translate the various attributes from the old system into yours, and then handle the importing.
The challenge, and the part that needs to be considered, is given some of the user permissions, they will be used for not just accessing files, but other systems. The question that your integration team will need to tease out is, which of the systems will be brought over, or replaced with what you already have (this is the first cost optimization point).
Focus 2: Strategic Approach to App Consolidation
As the users are being accounted for, then it is time to look at the apps from the acquired company. Whether it is the off the shelf software or the custom apps, there should be a compatibility matrix created looking at each of the apps and their core functions. Not their tech stack mind you, but just the functionality. There will be a heavy push to “lift and shift” the apps for expediency.
Here’s what happens when you answer the siren’s call: unless you are deliberate about which apps to migrate, you will more than likely take a huge hit up front to migrate the apps, duplicate what you already have doubling your costs, and increasing the risks of when things happen due to taking care of unfamiliar tech.
This initial migration cost will more than likely be dependent upon the infrastructure (process, policies, tools) of the acquired company, and depending on what is acquired and how, you may not have access to this infrastructure going forward so you will need to build it out from scratch, or work around it. Both of which are very expensive and will take a considerable amount of time, even if you were to rely on generative AI to code up a solution around it. Here is where the culture can come into play as well.
The compatibility matrix I mentioned earlier will come in along with the the previous point of ensuring everyone is aligned on what the ultimate goal is for the M&A. This will help you determine what capabilities you need to bring over to support your ultimate goals, determine what you already have and work out a transition path consisting of migrating the data or that you may need to bring their apps over.
It will also act as your guide post for determining whether you can migrate just the data or if you need to bring everything over. It shouldn’t be said that this will also be your greatest point of cost and time savings during and after the integration phase.
If you still need to convey the applications, then this, more than anywhere else will make or break your budget and timelines. Thing is, most assume that lifting and shifting will be quick and easy. Just like rebranding the user-facing apps to match your new look and feel for day one.
And that is where the third focus comes in…
Focus 3: De-Risking the Cut-over
The challenges will usually include:
- Underlying infrastructure that was a part of the acquired organization that will not be migrated requiring a workaround, new purchases, or outright rewrite.
- Depending on what is powering these apps, they may require being physically moved on-prem or between cloud providers. Also, this will differ from what you already in your organization, but will now be expected to support.
- There will be an expectation that these apps remain available throughout the transition. This means users and data will be out of sync during this rework requiring a mechanism to ensure the data is constantly refreshed until you are ready for the transition.
None of these are insurmountable, but this is why the pre-integration design/planning is so important. Especially when you start looking at what the cut-over activities look like.
This can start by looking at the customer and partner flows into your current apps, and for the users coming over, how will their flows change? What can you do to make it an easier transition (think not just the cut-over on day 1, but leading up to and several weeks afterwards as your work continues).
How much of this pre-work can be staged, and what mechanisms do you have in place before flipping the proverbial switch?
Lastly, and most importantly, can your current infrastructure handle the one-time increase in activity? For example, I’ve had a client in the past, and was also impacted by this when Oracle bought Sun Microsystems, where the attempting to send more than a couple thousand on-boarding emails crashed their systems.
In this case, there are more questions than answers, and it is pretty fuzzy. However, this also highlights how much of knowing what to do about the users and the apps can factor into the consolidations. After all, any late discoveries here (missing infrastructure dependencies for example) will be very costly.
Summary
For business leaders driving growth through acquisition, the promise of synergy often overshadows a critical risk: technology integration. While culture and branding are key, the acquired company’s tech stack—specifically its users, applications, and data—holds the greatest potential to either realize or destroy the deal’s value.
A successful post-merger integration hinges on a strategy that prioritizes three areas:
- Mitigating User and Customer Disruption: Ensuring a seamless Day 1 experience for employees and customers is paramount. Mismanaging user migration creates friction, kills productivity, and damages reputation.
- Strategic Approach to App Consolidation: A “lift and shift” approach to software often duplicates costs and introduces unfamiliar risks. A strategic analysis of application functionality is required to decide what to consolidate, migrate, or retire.
- De-Risking the Cutover: The final cutover is where hidden dependencies and infrastructure gaps become costly emergencies. Proactive planning is essential to ensure your systems can handle the transition without disrupting the business.
Ultimately, optimizing for synergy requires looking beyond the org chart and into the architecture. A deliberate, user centric approach to integrating technology is the foundation for capturing the full value of your acquisition.
Getting post-acquisition integration right is complex, but the risks of getting it wrong are far greater. If you are preparing for an integration and want to ensure you capture the full value of the deal, let’s talk.