Post number 7 in a series of 12 from one of our provider partners, NTT.
My current position exists because of an acquisition. The original company I worked for, Dimension Data, was acquired as a wholly owned subsidiary of NTT Communications. Mergers, acquisitions and spinoffs can add some additional complexity to many of the issues I have been talking about in my recent posts. There are typically legally binding agreements for how and when things need to be done. Add to that the disruption these events cause to employees, and you are talking about an extremely risky time for a company. Mergers and acquisitions also become tricky depending on the type of merger. There are several different scenarios, each with their own set of challenges. A company can:
- Acquire another company as a wholly owned subsidiary while the subsidiary remain an autonomous unit
- Acquire another company as a wholly owned subsidiary and roll it into the company
- Purchase a company outright and rename it
- Purchase a division or part of another company
- Acquire assets and some intellectual property of another company
- Consolidate by combing with another organization to form a new enterprise, with neither of the previous companies surviving independently
- Spinoff a unit to form a new company
In looking at this list of scenarios, things could be as simple as changing the name of the new company or as complex as purchasing completely new hardware for operations. I have worked on a few different types, each of which had nuances, most of which were written into the legal language of how the company was to come together or separate from the original parent. Most mergers have a time frame where one or both corporations need to transition from one company to another. From an IT standpoint, this may mean dealing with collapsing mail servers, the merging or separating of domains, consolidating hardware, combining redundant applications, etc. It may mean closing facilities and retiring hardware, and lots of work is involved. It may even go down to the application layer where users have to go into applications and change names. Most likely there is also a time frame written into legal documents that expresses when a company has to be running as the new entity. This imposes deadlines on the business at a time when people may be uncertain about their future and resources may be scarce.
The first merger I experienced involved a company that was buying the assets and a division of a second company. During this migration we needed to complete several key tasks:
- Take inventory of the assets that were purchased
- Analyze the programs for dependencies on the old company
- Look at back end infrastructure that supported the old company (email, active directory, trouble ticketing systems, etc.)
- Analyze assets to determine their relevance to the new enterprise and decide on a methodology for migration
- Migrate all applications from the old company’s AD domains to new domains. We also had to make sure the domains were compatible because the acquiring company had an older Domain Controller than the acquired.
- Create an entirely new network that ran in parallel to the old one during the transition phase
- Reimage and test applications and desktops with new company logos
- Shut off access to people who were no longer part of the organization post-merger
- Etc. I say etc. here because there were numerous changeovers, tests and failbacks, meetings galore, and all sorts of other activities that took place in order to finish the project
Spinoffs have some of the same issues. They may require that an organization builds an entirely new environment and that they transition some of the assets from the original company to the new entity. A spinoff that I was part of was a little bit simpler because we only had to build up the new services and migrate them from the old company. We had the full backing of their former company and were able to use application architectures built from their template. Exact replicas of the hardware for the new company were purchased to make the migration easier, yet we still had to go through the applications and purge data that was not to be part of the new organization.
Public and Hybrid clouds can play a key role in standing up a new infrastructure and in eliminating some of the risk by providing:
- Swing environments for movement between one company and another
- Test and development environments that can be used for application compatibility testing between the old and new companies
- Whole new domains that can be set up in the cloud to help make transition easier
- Rapid standup of resources on tight time frames
- The ability to collapse and remove cost of infrastructure once the project is completed
If a spinoff’s new space and infrastructure are needed to support the new company, cloud and colocation providers offer. And like I mentioned in other posts, using cloud providers during merger activity helps to mitigate the risk in a very risky time.
Next Post: Moving Enterprises to the Public or Hybrid Cloud Part 8 – Space Constraints
Contact StrataCore to learn more about NTT America Cloud services (206) 686-3211 or stratacore.com
About the author: Ladd Wimmer
Ladd Wimmer is a valuable member of the NTT Communications team. He has over 15 years of experience implementing, architecting, and supporting enterprise servers, storage and virtualization solutions in a variety of IT computing and service provider environments. He worked as Systems Engineer/Solution Architect in the Data Center Solutions practice of Dimension Data, most recently serving as technical lead for the roll out of Cisco’s UCS and VCE vBlock platforms across the Dimension Data customer base. Ladd has also run two IBM partner lab environments and worked for an early SaaS provider that created lab environments for Sales, QA testing and Training.