Companies engage in mergers, acquisitions, and divestitures. In most cases, a lengthy due diligence process happens. At some point in the process, “technological compatibility” between the impacted organizations is considered. What happens when the companies merging have entirely different IT architectures?
Consider this fictional scenario: Company “BlueCascade” divests a subsidiary business unit called “AquaPure.” Company “GreenLeaf” buys “AquaPure” from “BlueCascade.”
The technology used by the new owner, GreenLeaf, is on-prem and is modern hyper-scaler-based infrastructure. All applications are web-based and built on Kubernetes, an open-source system for automating deployment, scaling, and management of containerized applications.
The technology used by the acquired business, AquaPure, is legacy midrange IBM servers running AIX and IBM i. Most of the applications were built over 20 years ago and written in Cobol and RPG. In addition, AquaPure has ancient x86 servers running outdated operating system versions. The software running on these older x86 systems has never been tested using updated OS versions. On top of this, the older components based on x86 have precise latency requirements when talking to the midrange systems running AIX and IBM i. The x86 systems can’t have more than 3ms of latency, or transactions will fail with errors.
Once the merger is complete, the data from AquaPure must be wholly removed from the systems of the previous owner, BlueCascade. If the data is not removed within six months, AquaPure must pay a monthly fine of $200K until the data is removed. The regulatory provisions of its industry stipulate this. Also, the data center hosting the IT infrastructure for AquaPure will be closed in six months as part of the divestiture.
The setup is this:
- GreenLeaf and AquaPure must merge their IT operations, but the technologies are not directly compatible.
- There is a substantial fine if legal data custody is not completed within a specified time frame.
- The data center hosting AquaPure will be closed at the end of the transition period. No extension is possible.
What are the options? The obvious one is to pack up everything from AquaPure and move it into the data center of GreenLeaf, the new owner. Here are just some of the problems with this scenario:
a) There is no physical space in the GreenLeaf data center for the additional equipment and insufficient electrical or cooling infrastructure. A new data center or expansion would have to be procured. This takes time and is expensive.
b) The applications from AquaPure are ancient and rely on hard-coded IP addresses that can’t be changed.
c) There is no time to refactor the older legacy applications of AquaPure into the modern infrastructure of GreenLeaf.
d) During the due diligence process, it was discovered that there are several security and compliance incompatibilities between the two organizations. (aging AquaPure x86 servers and operating systems with security problems.)
e) AquaPure has a substantial and loyal customer base. The large market share was part of its attractiveness to GreenLeaf, the new owner. The integration of the two companies must take place so that the existing customer base is not disrupted.
So what should GreenLeaf do?
All the problems described above can be resolved or mitigated by leveraging the cloud. The technical assets of AquaPure should be moved to the cloud instead of being moved to GreenLeaf on-prem. The option of using the cloud in this scenario might seem complicated, but the process can be very straightforward. Let’s take each point of contention and explore the cloud option.
1) The systems of AquaPure are legacy-based (IBM i, AIX, outdated x86).
Resolution:
Several major cloud providers now have options for running IBM Power in the Cloud. This takes care of AIX and IBM i. The migration process would be a straight “lift and shift.” The Power server images called “LPARs” can be copied over, or a backup/restore process can initially be used. The migration can be done in parallel while the existing systems stay up and running. The cloud-based Power systems now become the temporary “mirror” site for AquaPure on-prem. Using replication software, everything stays in sync until a final cut-over is executed. Servers can be migrated in mass and in parallel based on available resources and time. The strategy and pattern are similar to how a Disaster Recovery site is implemented.
Skytap makes it possible to move these workloads to Azure using the process described here. Cloud providers like Skytap support IBM Power and x86 operating systems in the same network “environment.” The coexistence of Power and x86 in the same cloud data center provides a low-latency solution for migrating legacy systems via a straight lift-and-shift. This allows for the 3ms latency requirement to be met. Some Power cloud providers don’t host x86 in the same data center as IBM Power. In those cases, it is doubtful that the 3ms requirement could be met so choose your cloud provider wisely..
2) IP addresses that are hard-coded.
Resolution:
Some, but not all of the major Power cloud providers, allow you to provide any valid RFC 1918 address range when creating virtual networks. This will enable you to keep the existing IP address scheme even after it moves to the cloud. In addition, using network address translation (NAT) can help hide those IP addresses if they conflict with on-prem. Lastly, it is possible to use L2 (“subnet stretch”) types of solutions in the cloud to assist with migration. The same network subnet can exist “in the cloud” and “on-prem” simultaneously without conflict. This allows you to do a safer phased migration over time instead of being forced into a big-bang, all-or-nothing migration, which is risky.
3) No time to refactor to a different on-prem technology stack or directly to cloud-native.
Resolution:
The merger strategy should be a straight “lift and shift” as much as possible—same host names, same IP addresses, no application changes, etc. The goal is to get it out of the data center as soon as possible and into the cloud. The cloud becomes your initial “safe harbor.” An important requirement is to do so in a way that does not require the applications to be changed in any way. Once migrated and stabilized, you can then take your time to consider the next move. Your next move could be to just leave it in the cloud as-is, or over time convert those AquaPure legacy applications to be on-prem compatible with GreenLeaf’s current technology stack or possibly be converted to cloud native.
4) Security and compliance issues.
Resolution:
By lifting and shifting to the cloud instead of on-prem, two possibilities exist for security of the AquaPure legacy systems. It could be that your Power cloud provider has better security than you did on-prem. Possibly your security exceptions could go away. If this is not true, then when you migrate to the cloud you might also be migrating your security and compliance issues, but there is a path to resolution. Once you are running in the cloud, you can isolate those legacy components from the rest of on-prem. By using additional appliances like firewalls or implementing more fine-grained controls and access policies, you might be able to create more security controls than the original system.
For our merger of GreenLeaf buying AquaPure, the security incompatibilities of AquaPure can be isolated in the cloud so that they do not impact the existing on-prem systems of GreenLeaf. More restrictions and controls could be added so there is no possibility of infection or side effects if all of AquaPure’s equipment was somehow merged into the same data center of GreenLeaf.
The cloud solution
In this scenario, we described how seemingly incompatible organizations at a technical level can complete their merger to avoid financial penalties and allow for a predictable “Time to First Value” for the newly combined organization. Using the cloud as an “intermediate step” also sets up nicely for the future. The legacy-based systems of AquaPure can either remain in the cloud and continue to run “as-is” or, over time when resources are available, they can be slowly refactored to be in line with the long-term IT strategy of GreenLeaf, the new owner.
Use the cloud to help accelerate mergers, acquisitions, and divestitures. Don’t let seemingly incompatible IT architectures be the reason why a merger fails. “Insufficient Due Diligence” is often cited as one of the reasons why mergers fail. Any oversight in technical due diligence might be solved with a little “cloudification.” This is even true when the systems involved are more specialized or legacy based.
Learn more about Skytap on Azure.
