Mergers and acquisitions take time and energy.

Take Virgin America and Alaska, for example. After buying Virgin America in 2016, Alaska has spent more than two years merging Virgin’s operations, employees, and IT with its own.

The integration process is nearing completion and could be finalized this year.

While it appears this has been a smooth process so far, it isn’t always with other mergers & acquisitions. Without proper planning and execution, M&A poses a risk. When you combine IT systems that weren’t built to work together, it can be tricky, and issues can arise.

Unfortunately, airline outages are growing more frequent. Sometimes it’s the weather or airport issues that ground flights, but all too often it’s airlines’ IT that fails. Check-in systems go dark, leaving employees with pencil and paper. Apps and booking systems fail, leaving customers frustrated. Crew scheduling apps falter, potentially leaving flights grounded.

Mergers are sometimes the cause of these mishaps, especially when they’re rushed. The most resilient companies get ahead of those issues before they become embarrassing outages in front of unhappy customers.

That goes for any companies merging their IT, not just airlines.

Here’s a look at what these organizations should consider to weather M&A while minimizing the chance of outages and other disruptions.

The choice you need to make during a merger

Nearly every merger includes a meshing of IT systems to some degree. There are several options for how to do this, and the choice should be made with customers, partners and employees in mind.

Sometimes companies keep systems separate if there’s a potential issue with them not working well together (at least initially taking a gradual path toward integration). While this may be an opportunity to implement a new system from scratch post-merger – by doing away with whatever each company brought to the table – that option is typically most expensive and involves migrating from two systems.  

Most companies fall somewhere in the middle, picking and choosing the best systems from each organization. If one company has a better CRM system while the other has better back-end systems, they’ll integrate the two along with the best elements of each system.

Of course there’s always risk when integrating existing systems with new and unfamiliar ones when the two aren’t necessarily designed to work together. The dependencies and compatibilities of the new system might not be clear, and could hinge on assumptions made years ago by the original developers. Bringing a second company’s volume of traffic into a database, for example, can be problematic unless it’s upgraded to handle the new workload – especially under peak conditions.

How to minimize the chances of IT outages after a merger

When you merge IT systems, you’re asking parts of the infrastructure applications to communicate in ways they probably weren’t designed to. What’s worse, changes to those applications often go undocumented. During a merger, with added time pressure and more interest and visibility from the board and executives, shortcuts are all the more likely.

How do you uncover these areas of risk during a merger? In the end, resilience comes down to planning and testing. There are four components to this:

  1. Align IT with long-term goals and strategies. Is this a one-off acquisition or the first in a series? How you merge IT environments depends on and should be aligned with your overall strategy. If you’re considering a phased approach to merging IT, make sure you follow through on the future phases. It can be easy to let a temporary fix stand, but it becomes an ongoing risk for failure.

  2. Map application dependencies. When you tie together systems from multiple companies, you can’t rely on the documentation of different applications’ dependencies. Sometimes documentation doesn’t exist. Sometimes the time pressure of a past merger forced shortcuts that could become a pain now. Invest in the effort to properly map applications, understand their interdependencies and tier them based on their importance to your business. Leveraging automated discovery technologies and consultants or providers with experience in mapping dependencies, may be a more effective approach to addressing this need.

  3. Test, test, test. The more you can plan out the integration, the more you’re able to test it before it goes live. The more you test it, the better your chances of finding and fixing issues in production systems before they become embarrassing public failures.

  4. Make sure DR planning is part of the process from the start. Don’t wait until a later phase as you rush to complete the integration. Making DR part of the plan from the start can aid in mapping dependencies, not to mention that it provides a failsafe in case anything goes wrong -- whether an issue with the integration, a natural disaster, a cyberattack or some other kind of outage. But don’t just set it and forget it. Be sure to test your DR plan at least twice a year and update it throughout the integration process as systems and dependencies change.

Mergers and acquisitions can create economies of scale, and unified IT systems are one of the benefits. But with two systems not designed to get along, mergers can create as many issues as opportunities. By focusing on planning and testing and integrating DR from the beginning, any organizations working to merge their systems can enter the market as a unified company more resilient to the outages and issues that can accompany M&A.

Related Articles