The IT M&A Playbook

Introduction

M&A integrations are often painful. In this article, I’ll suggest ways to alleviate some of IT’s M&A integration stress by offering methodical guidance to make your IT M&A efforts smoother and more efficient. Through the hypothetical example of Alpha Inc. acquiring Bravo LLC, I’ll demonstrate practical strategies and best practices to ensure a seamless integration process. Whether you’re an IT professional or a business leader, this article will provide you with valuable insights to help you manage the technical challenges and achieve a successful merger.

Activate the M&A Team

The cross-functional teams below should be organized well before active mergers and acquisitions, and the IT product manager (or enterprise architect) should serve as the directly responsible individual (DRI) for the overall technical integration roadmap. The M&A product manager represents IT with a permanent seat on the M&A team and is privy to information that mustn’t be shared beyond the M&A forum. However, the product manager must provide ongoing forewarning to the IT team of target metadata, such as the size and geographic location of potential acquisitions. This “anonymized T-shirt sizing” strikes a balance between protecting confidential information while keeping IT informed of future M&A endeavors.

In the figure above, we see only four basic IT “tracks.” Each track has a technical leader from the acquiring company, and another lead from the company being acquired. In the real-world, you’re likely to see closer to 7-12 tracks. Additional teams may include business intelligence, security, compliance, help desk, and so forth. Also, we see the G&A and GTM vertical track leads working directly with their business stakeholders, while the horizontal IT functions such as network and systems are not. This too can vary. Yet IT needs to be mindful of having too many points of contact with the business. For instance: a go-to-market leader will likely want to communicate with his or her primary IT liaison; not every IT track lead across both companies. 

Determine the M&A Archetype

The type of M&A activity will determine the integration pattern. Therefore, it’s important to understand the business goal of the endeavor, then plan integration types accordingly. 

1. Complete acquisition – a complete acquisition means the company being acquired will become part of the acquiring company and will no longer operate as a separate company. Product names and other assets may remain for some time, but the acquired company itself will inevitably be legally dissolved and logically absorbed by the acquiring company. Put simply: all employees and assets are now assigned to the acquiring company. This is the most straight-forward integration type and integration decisions should skew towards using acquiring company assets. 

2. Subsidiary – Wholly and partially owned subsidiary companies often retain their operating status as a unique entity separate from the acquiring company. This lends complexity when the subsidiary will maintain systems separate from the parent company. The focus on subsidiaries thus shifts to integration conversations centered around assets that must be shared. For example, a child subsidiary may opt to maintain their own marketing systems yet must use the parent company’s ERP solution for the sake of unified financials. Identity and access management quickly becomes complicated as subsidiary employees must either have two sets of credentials or a federation model whereby the parent company grants access to accounts in a completely separate child domain space. 

3. Merger – Mergers are the most complex, as two companies come together to form a completely new company. Much of the same acquisition analysis applies to mergers due to the fact that systems from both company-A and company-B will likely be reused. For example, company-A may sunset their ERP in favor of the solution used by company-B. What makes mergers technically difficult is the rebranding that must touch every system and identity from both companies.  

It may seem obvious to identify the M&A archetype up-front. Yet in the real-world, executives will have “plans” that aren’t well communicated or are overly-complex. An example would be executives from the acquiring having concerns over employee churn, and thus allowing the acquired company to retain its brand and function as a standalone entity (a de facto subsidiary) for some time. This leaves the integration in limbo which in turn creates poor user experience and accumulates technical debt.

Focus on Business Goals and M&A Success Metrics

Immature M&A technical integrations lead with a “systems-first” approach. In other words, M&A team members ask employees which applications are crucial for day-1, which leads to a bottom-up view of the world whereby many employees request many applications to be live on day-1. This approach is both unrealistic and inefficient.

The criticality of an application should be tied to M&A business outcomes; not maintaining status-quo operational needs. Let’s examine this with an example. Suppose the following M&A business goal and success measure has been solidified:

• Goal: Retain Bravo clients
• Success Measure: Provide unified customer experience across sales, marketing, and support under the Alpha brand and Alpha customer touchpoints by Q2 of this fiscal year.

If the target Alpha company standard for customer support is Salesforce, we would be wasting time providing access to the legacy Bravo LLC’s Zendesk system. Furthermore, IT shouldn’t be judged on the performance of system integration alone. Trying to integrate or migrate too many systems will take too long and will reflect poorly on IT. Likewise, even if IT could migrate hundreds of systems overnight, such efforts may not align to business goals whatsoever which means IT has wasted time.

As shown above, business goals should have a goal, a success measure, and a business owner. Simple examples are exemplified below:

Remember: without business goals, M&A integrations will fester forever as the goal post of success will arbitrarily ebb and flow. Stick to goals, and let the systems integrations follow. 

Determine the Trust Level of Acquired Assets

Regardless of the M&A archetype, there may be a period of time whereby systems from two companies must coexist in a hybrid state. Fundamental trust levels include:

1. Full trust – Source and target systems meet the same level of security requirements, and the comingling of networks and endpoints is permitted. While possible, this is seldom realistic. 

2. Partial trust – Source and target systems have similar, but varying security postures. Limited network connectivity may be permitted between networks of lower sensitivity levels, and source endpoints may be used for web browser and/or VDI-based access to these lower environments. 

3. Zero trust – Source systems are untrusted and are essentially treated like Internet users. Access to target systems is restricted to locked-down VDI environments and/or accessed from target company endpoints only. 

In practice, the breadth of the entire acquisition won’t fit neatly into these buckets. For example, you may have full or partial trust of the product development infrastructure, but zero trust of the corporate network being acquired. Once again, the important thing to remember is to classify the categories at hand so that stakeholders understand IT’s approach and expectations are managed accordingly.

Process Mapping and Migration

Before jumping into technology migration, we must address a critical step in the future-state operation of merged and acquired organizational cohesion, and that is process mapping and migration. Put simply: moving from one tool to another doesn’t equate to a successful migration. Commodity utilities such as cloud storage migrations may be simple enough to lift-and-shift. Training and process changes must also be considered. 

Training

Even “simple” migrations such as Dropbox to OneDrive or Smartsheet to Asana will require some degree of end-user training. Many SaaS solutions offer free online training or “academies” which any user can attend. For simple / day-to-day knowledge worker tools, this may be sufficient. Yet for complex systems such as CRM and ERP systems, these systems require deeper dives; especially when they’ve been customized to enterprise-centric processes. As such, be sure to include systems training tracks into your migration plan. 

Process Mapping

Corporate platforms such as procurement systems, customer relationship management managements, and support tools are highly complex; and operation of these tools varies widely from company to company. Rather than explaining such complexity in broad theory, let’s jump into two hypothetical use cases: the procure-to-pay process (procurement) and the lead to quote process (sales) across Alpha and Bravo companies.

1. Procurement – Bravo LLC uses Order.co for procurement, and every manager is allowed to make purchases with simple managerial approval. In contrast, Alpha Inc is a publicly traded company with stringent financial controls. Purchasing in SAP Ariba requires a corresponding purchase order within the S/4 HANA ERP system. Requesters and approvers must be separate entities to ensure segregation of duties for SOX controls. Finally, the Ariba procurement system is highly customized with unique, company-specific fields required for each transaction. 

2. Sales – Bravo LLC is a small company with a small sales team of just 12 sales reps. The Bravo team uses a simple kanban board to track and forecast deals, and sales opportunities are organically generated from rep-to-rep. On the other hand, Alpha Inc has 500 business development representatives. Alpha sales teams tackle the addressable market with a complex sales structure that factors in both geographical region and business segment. Opportunities are tracked in a highly customized Salesforce instance, and there are strict guidelines for how and where to update CRM fields to ensure proper sales forecasts. 

As shown above, there are both process maturity and systems complexity gaps between these two companies. Simply turning Bravo LLC employees loose on Alpha systems would immediately fail without retraining Bravo employees how to navigate the complexities of Alpha business process. 

So why does business process matter from the IT perspective? It’s because IT’s M&A success is linked to business outcomes, not technical migrations. If IT onboards users into tools they don’t understand, those business goals will never come to fruition. Obviously, IT isn’t obligated to train every employee across every complex platform. But just know that training and process adaptation is on the critical path to success. Therefore, it is IT’s job to ensure training and process adjustments are socialized, included in the migration plan, and have adequate business contribution towards those goals.  

Tying it all Together: Building the Migration Roadmap

Thus far, we’ve assembled the players of the M&A initiative across IT and the rest of business itself. We’ve determined the M&A archetype, the trust level of the integration, and have prioritized business goals over applications. It’s now time to put the first iteration of the roadmap together!

Roadmap v1.0

The first cut of the roadmap is really a draft to show more of the “what” rather than the “how.” More specifically: we want to see the breadth and totality of the integration so that we can get a high-level T-shirt size of duration and effort. This first draft is often eye-opening as it shows exactly how much work is actually required to achieve the business objectives at hand. 

The first draft should be presented during an executive checkpoint meeting to ensure expectations and reality coalesce. Once stakeholders see the real estimates of the work ahead, they may decide to reprioritize certain business goals. Therefore, we don’t want to jump straight into project planning, work sequencing, and staff allocation until this crucial step is complete. 

The application list above is simplified for brevity. Real-world migrations will include many other assets such as various web properties, proprietary homegrown tools, and vertical-specific solutions in spaces such as manufacturing or logistics. 

ABOUT DAY-1: During M&A endeavors, we often see the terms day-1, day-2, and so on. Unfortunately, these terms are not used consistently across organizations. Technically speaking day-1 should be defined as the day the acquisition is officially (and legally) executed as a closed deal. In other words, day-1 doesn’t necessarily equate to all users harmoniously integrated into a friction-free working environment. Regardless of what other companies do, the important thing is to clearly define what day-1, day-2, etc. actually mean in terms of goal achievement and IT deliverables. Once those milestones are defined, aggressively socialize them to reduce ambiguity and erroneous expectations.

At this point, version 1.0 of the roadmap should be completed and agreed upon, and the team can commence to enhancing the plan towards version 1.1 discussed in the next section.

Roadmap v1.1

Once executives have examined v1.0 of the roadmap and generally agree to its scope, it’s now time to start logically sequencing the work. Like building a house, sequencing ensures a foundation is set before framing can start, and framing needs to finish before the roof is installed. 

Sequencing across different IT domains is challenging and is one of the primary reasons having an enterprise architect on the team is so important. Someone on the team needs to be able to view the world cross-functionally rather than focusing deep on individual IT functions. Real-world examples of logical integration sequencing challenges include:

• IAM – The identity and access management team configure all acquiree users in the acquirer IAM suite; only to realize client-side certificates are required for authentication. Hence, client devices are a prerequisite for IAM and endpoints must be provisioned before IAM testing can begin. 

• ERP – ERP systems are generally classified as a transactional processing system. But it’s quite common for ERP to depend on data platforms for their inbound and outbound integrations. More specifically: many ERP data flows depend on extract-transform-load (ETL) middleware and complex data warehouses to “massage” data in and out of ERP. Unfortunately, ERP and data engineering teams are often distinct entities, and these cross-team dependencies mustn’t be overlooked.

• Network Engineering – When most people think of networks, they think of connectivity to the Internet. In reality, the network is the crucial fabric of the enterprise that securely connects literally everything. It’s also an integral part of the end-user experience. As an illustration, take an American company that acquires a smaller company in Japan. If that American company has all of its corporate assets hosted in America, and also uses an Internet proxy solution hosted in the United States, Japanese-based employees must “hairpin” their traffic back and forth from the US all day; even when visiting Japan-local websites. Therefore, intelligently re-shaping geo-specific traffic patterns is crucial for global acquisitions. 

Once logical sequencing has been established, the roadmap tracks can now be sequenced into Gantt format as shown below:

At this stage, we’ve enriched the roadmap to include properly sequenced workstreams and have refactored the roadmap into a user-friendly Gantt chart format. In the following sections, we’ll build on version 1.1 to formalize effort, cost, and time. 

Estimating Level of Effort, Cost, and Time for Migrations

Assessing the level of effort and cost of integrations are covered in the following sections. Yet I want to take a moment to talk about the importance of time. 

All too often, M&A activities are piled on to already busy IT teams, and the primary demand from IT is to get the acquired company employees productive on “day-1.” M&As are thus treated like projects, where day-1 is somewhat clear, and subsequent phases are increasingly ambiguous. Consequently, IT is never really finished with the core integration work, and the lines between M&A completion and keep-the-lights-on operations becomes blurry. One thing is for certain in this scenario: such acquisitions are a perpetual drain both on IT productivity and IT reputation.

Completing M&As on time means the definition of done must be clear. Phases and deliverables within those phases must be enumerated and socialized. And finally, decisions should be formally signed-off on so that there is a historical record of who made decisions and why. 

Financial Analysis and the True Cost of Tech Debt

Application migrations are hard. And as we’ve seen even in the simple roadmap we’ve created thus far, there are many of them! It’s tempting to leave legacy systems as-is, and in certain cases, this is the right decision. Purpose-built platforms or systems which cannot easily be migrated come to mind. 

However, cost analysis goes well beyond balancing the cost of migration versus the dollars saved from sunsetting a legacy system. To be clear: keeping systems around is expensive, and here’s why:

1. Direct subscription & maintenance costs – The most obvious issue with keeping systems around is cost. More software licenses equal more cost.
2. Security challenges – More systems with enterprise data in them means a broader attack surface and compliance challenges.
3. Indirect costs – Related to security challenges is the costs associated with securing these additional systems. If an organization has a legal hold system designed for Office365 and now you have to maintain Google Gmail for business, you need additional licenses or perhaps a different tool altogether. 
4. Poor user experience – SaaS solutions go viral within the enterprise, and we see “tribes of preference” with respect to certain tools. If you’re a project manager who prefers Asana and I prefer Smartsheet, that’s great in theory. But when we have to share project plans, there’s a good chance I need to get into Asana to see your plans, and you need to get into Smartsheet to see mine. This fosters the trajectory of “everyone needs access to everything” which adds a lot of operational overhead for staff who now need to operate 2-4 project management solutions just to get daily work done. 
5. Administrative overhead – More technology means more skills, and this goes for both IT and businesspeople. If the parent company has standardized on Palo Alto Networks firewalls, yet a subsidiary insists on keeping their Checkpoint firewalls, how do you pool IT resources to manage these firewalls globally? This creates pockets of expertise, which in turn creates human single points of failure. This ultimately leads to more enterprise downtime. 
6. M&A completion lag – Last but not least is that of the overall M&A initiative taking longer to finish. It’s not uncommon for executives to ask that systems stay around for “a while” during the initial stages of M&A, then balk at legacy systems being maintained a year later. The perception is that IT hasn’t completed the migration, when in reality, the definition of done was unclear. Either way, this reflects poorly on IT. 

Thinking about the overall lifecycle and user interaction of these legacy systems is a crucial part of articulating the true total cost of ownership. It’s the job of executives to ultimately make decisions which trade off time, efficiency, and money. It’s your job as an IT leader to ensure executives understand all variables in that decision.  

A Word About Vendors

During an acquisition, the acquiring company will inherit the assets (and associated contracts) of the acquired company. Some of the vendors may already have active contracts with the acquiring company, and some of the vendors will be new as shown in the figure below. 

Obviously, it’s important for the legal and compliance teams to examine the master service agreements as well as the scope of work and subscription contracts to ensure congruence with the parent company’s guidelines. What isn’t always obvious are some of the “gotchas” associated with acquiring existing contracts, such as:

• Certain software contract fees are based on the total number of employees within a company; regardless of whether employees use the software directly. Other contract fees may be based on revenue generated within a company. (These are often called cost-of-goods-sold or “COGS” software models, which are common in both the manufacturing and software as a service subscription sectors.) These terms may be manageable for a small company of 500 employees with $100M in revenue. Yet a 10,000-employee company doing over $5B in revenue will have a shockingly high software true-up to deal with when the contract renews.

• Many software contracts have an auto-renew clause and require many days of notice prior to termination. Failing to terminate the contracts in a timely manner may equate to expensive shelfware for solutions intended to be sunset. 

• Some of the net-new (acquired) vendors may actually be competitors to the parent company.

Roadmap v1.2

At this point, we should enhance the roadmap to include refined target migration dates taking the additional dimensions of training and process mapping into account. Furthermore, financials should be solidified to include not only cost savings, but also the true cost of ownership of maintaining legacy solutions. Finally, the M&A plan should include key software contract renewal dates to ensure applications intended for sunset are terminated with adequate lead time. 

Measure and Report

Traditional status reporting of M&A activities goes a little something like this: a product (or project) manager whips up a dashboard, shows the red/yellow/green bubbles to executives, and that one-way status update blasts its way to stakeholder inboxes. This approach is not ideal. A more upleveled approach is to treat M&A activities as dynamic products that require real-time cadences, conversations, decisions, and adjustments. 

PIVOTING AS NEEDED: The deal room is very different from the boardroom. When planning integrations, we often see the world through rosy “best-case” lenses and assume everything will go to plan. Yet in reality, integrations often lag due to unforeseen technical challenges, staff churn, and many other hurdles. In a real-life scenario, we may learn that the subscription management system can’t go live without ERP. A decision to push subscription management out or pull ERP in will need to be made. Likewise, you may discover that acquired endpoints cannot be managed by acquirer management infrastructure, facilitating an expedited deployment of new laptops to thousands of employees. If we view acquisitions from the same perspective of software development, we need to embrace changes and pivots. The goal is to achieve a business outcome, not check the box on an integration. Getting creative and trying a different means to achieve the same business end should be standard practice, not taboo.

Throughout the lifecycle of the integration process, there must be a routine cadence where stakeholders are treated like team coaches who make strategic calls for the players on the field. Stakeholders aren’t team owners far removed from the action, and yet they aren’t micromanaging quarterbacks with their hands on the ball every play of the game. The product manager provides updates, blockers, and alternative courses of action. The stakeholders then make decisions when new information or challenges arise. Those decisions should be logged for historical traceability, and decisions should be disseminated so that everyone understands the rationale behind why things are executed in one fashion or another. 

Closing the Project

As mentioned previously, having a solid definition of done is the lynchpin in transitioning from acquisition project work to daily operations. And also mentioned many times at this point is that the definition of done should revolve around a measurable business outcome; not how many users have been onboarding to a target system. 

Beyond achieving closure to the acquisition effort, another valuable milestone is the post-acquisition assessment or retrospective. Understanding what went well, and what could have been done better is key to continuous improvement. These learnings should be incorporated into your M&A playbook so that each acquisition’s velocity and efficiency improves incrementally over time.