Zscaler Blog

Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang

Produkte & Lösungen

A Tale of Two M&A Journeys

Februar 05, 2018 - 3 Lesezeit: Min

In 2017 there were over 50,000 mergers and acquisitions, marking the third year in a row where this many took place, and making history in the process. CVS acquired Aetna, the Dell-EMC deal closed, and Amazon even bought Whole Foods, just to name a few.

A merger or acquisition may be something that your company is planning, or has already begun. The problem is that it can be, and often is, incredibly challenging for the IT admins responsible for ensuring user connectivity to business-critical applications and the security of sensitive data. Integrating disparate networks is complex in itself. If you're networking, security, or compliance, and have been involved in an M&A before, you know other things can often go wrong as well. The fact is, once your organizations are ready to work together, the difficult task of getting the networks to work together is only beginning - and can take months, or even years, until everything is finalized. 

Journey 1: M&A the Way It’s Been Done For Years

The process begins with getting circuits from the telecom provider, which can take between one and three months. You then try your best to cable things together, only to discover that the internal networks use overlapping IP addresses (horror music begins). At this point, you may decide to re-address everything on your network, which will often bog down the entire deployment. So you look for another way, which could be to use Network Address Translation (NAT). Unfortunately, you then discover a number of issues, including:

  • DNS hostnames for existing servers are pointing to the non-NATed IP address, requiring complicated DNS reconfiguration
  • Some traffic may require exemption from the NAT
  • Applications with hard-coded IPs will break when NAT is applied
  • Some instances will require port forwarding rules to redirect one address/port number combination to another
  • Applications that filter traffic by source IP must all be updated to the new NATed addresses
  • NAT addresses may get overloaded

After months of hard work, you’re only partially done and you have a few grey hairs to go along with it.

Journey 2: M&A When You Use the Software-Defined Perimeter

The process begins with you removing the requirement to place their users on your network, or your users onto the other company’s network, altogether (phew!)). Instead, you deploy connectors that front-end known applications, connecting to a cloud service - Zscaler Private Access (ZPA) - that provides a software-defined perimeter. (These connectors can also enable IT admins to discover new and existing applications running in both company environments.)  You then create access polices which are stored in the Zscaler cloud to provide precision access to internal applications based on user roles, location, and device posture. Integrations with Azure and Microsoft AD help along the way. At this point, you can use ZPA to track user activity, which shows you not only when an application was accessed, but also by which users. Finally, if users are not authorized to access an internal resource, the resource is completely invisible to them. 

When using ZPA, there's no need to merge networks or deal with overlapping IP addresses anymore. Your users are never placed on the network, and you don't have to worry about Shadow IT lurking within your environment. In other words, your M&A just got a speed boost. No extra grey hairs either. 


The next time you find yourself going through an M&A, think back to this tale of two M&A journeys, and consider the SDP approach with Zscaler Private Access. Your organization will thank you for it. To learn more about ZPA take a look at this eBook.

form submtited
Danke fürs Lesen

War dieser Beitrag nützlich?

dots pattern

Erhalten Sie die neuesten Zscaler Blog-Updates in Ihrem Posteingang

Mit dem Absenden des Formulars stimmen Sie unserer Datenschutzrichtlinie zu.