AWS Cloud Operations Blog

Managing Technical Diversity and Migration Capability in Mergers and Acquisitions

In Mergers and Acquisitions, the need to understand and manage technical diversity and migration readiness is paramount to ensure cohesion and continued success for the combined organization. This blog post discusses some of the considerations in this space and highlights existing AWS Mechanisms that can help organizations through this process across three phases: Assess, Mobilize, and Migrate.

Assess

As an organization considers an acquisition migration, whether they be from on-premise to the cloud; or cloud to cloud, it is important to undertake an evaluation of each organization’s readiness and understanding of their technical diversity. The AWS Migration Readiness Assessment (MRA) is a mechanism to develop a deeper understanding of interdependency between different technical and business domains required for an effective migration as well as co-developing recommendations to address identified gaps and risks. Run as an interactive workshop, this is designed to generate a specific set of actions that are needed to build momentum and capability based on your current state, business goals, and defined objectives. The MRA looks at organizational maturity across the six Cloud Adoption Framework (CAF) perspectives: Business, People, Governance, Platform, Security, and Operations.

By undertaking an MRA with each acquired company, relative maturity, technical diversity, as well as areas of strength and risk can be identified to aid the design of the combined, resulting technology organization.

Operating in a single place enables you to increase operational efficiency, reduce costs, improve security and agility, and allows you to focus on your core business and end users. In addition, removing those migration risks can help ease the transition. There is no one-size-fits-all solution for migrations, but these strategies can help.

After the MRA takes place, your organization needs to consider when, if, and which parts of the technology stack should be consolidated. There are a number of considerations, many of which are specific to the nature of the acquisition and your organization’s strategy.

In terms of technology diversity, it can have both favorable and unfavorable consequences. As you grow, you need to be mindful that whilst technology diversity can boost productivity and developer freedom through low barriers to innovation, it can also start to hold an organization back from scaling. The operational overheads and increased security risk of managing an un-bounded technically diverse platform can erode the benefits. One approach utilized by a number of organizations and coined by Netflix as The Paved Road is to build a balance of governance, whilst supporting innovation. Here you formalize a set of expectations and commitment between teams on technology choice and provide a well-integrated, supported framework to enable developers to focus on delivering their core business value. This approach  can take a number of forms but will often include a Platform team(s) providing the specific tools and technology abstractions to remove cognitive load of stream aligned teams. The investments made to pave the road or elements of it are done in partnership with those teams, resulting in a streamlined developer experience rather than implementing the least common denominator. Standardization provides consistency, interoperability, security, and reliability, as well as supporting rapid development and innovation; By assembling endorsed patterns and components, there is a reduction in copy & paste development and version drift, freeing developers to focus on the outcomes and goals of the development effort rather. Teams can choose not to use the Paved Road, but they make an informed decision to do so rather than accidentally deviating.

As an organization grows, it introduces more process overhead, complexity, and governance, which can become problematic if the response is reactive. This means stretching the existing operating model to cope with demand without consciously evolving the organizational structure and complementing technologies to meet new demands. In such cases, technology diversity can become an issue as it forces the building of facades and control planes that sit over multiple disparate environments, creating higher operational overheads and potentially lowering the technology to the lowest common denominator. It is important to consider these factors, along with staff training and retention, when understanding the cost of technology diversity to an organization over time.

For instance, on-boarding new developers can be challenging as they need to be trained on a bespoke layer on top of multiple clouds, leading to an inability for IT teams to service the business in a growth phase. Additionally, abstracting developers from the cloud can reduce their ability to experiment and utilize new services and features until they are adopted by the overlaying technology, which can stifle innovation and impact staff retention as their cloud skills are diluted.

Mobilize

Detailed discovery in the Mobilize phase is vital for understanding the state of each workload to be migrated. One tool to aid in this process is the Well-Architected Framework, not just suitable for AWS workloads. You can run this framework over existing workloads on non-AWS sources. The Well-Architected Framework evaluates your workloads based on six pillars:

  • Operational Excellence: The ability to support the development and run workloads effectively, gain insights into your operations, and continuously improve supporting processes and procedures to deliver business value.
  • Security: The ability to protect data, systems, and assets to take advantage of cloud technologies to improve your security.
  • Reliability: The ability of the workload to perform its intended function correctly and consistently. This includes the ability to operate and test the workload through its complete lifecycle.
  • Performance Efficiency: The ability to use computing resources efficiently to meet system requirements and to maintain that efficiency as demand changes and technologies evolve.
  • Cost Optimization: The ability to run cost-aware workloads that achieve business outcomes while minimizing costs.
  • Sustainability: The ability to measure and establish sustainability goals and reduce downstream impact of cloud workloads

Understanding your workload across these pillars will provide a clear understanding of alignment to architectural best practices.

AWS has published a blog post on this topic https://aws.amazon.com/blogs/architecture/mergers-and-acquisitions-readiness-with-the-well-architected-framework/ and while it talks more about AWS to AWS the thought process is the same regardless of source.

You can also utilize Well-Architected to help inform your platform evolution to design for a growth phase. As you define the architectural and operational footprint of your AWS Cloud infrastructure, you must continually be thinking about how your environment will be able to support an acquisition. Architects must build a highly agile, frictionless environment that can accommodate spikes in workload onboarding without adding significant operational overhead. The idea here is to allow for an early migration of acquired entities to reduce the security risks, double bubble costs, and operational overheads of running multiple diverse technology environments.

Migrate

For individual workloads, the AWS Prescriptive Guidance provides time-tested strategies, guides, and patterns from AWS and APN Partners to help accelerate your project. For Example, in the case of Azure to AWS, there are a number of migration patterns and tools to help with moving and converting resources, be that for example an Azure VM to Amazon EC2, an Azure Service Bus to Amazon SQS or looking to port .NET to .NET core to allow for existing applications to be run on Linux or within Linux based containers with .NET porting assistant.

Conclusion

Mergers and Acquisitions can be an inflection point for an organization to grow, and by utilizing mechanisms such as the Migration Readiness Assessment, Well-Architected and AWS Prescriptive Guidance technical diversity can be understood and considered to support an organization’s growth. It is crucial to recognize the challenges that come with growth and to be equipped with the necessary tools and mechanisms to navigate this process successfully.

This post provides insight into some of the challenges that organizations may face during the growth process, but it also highlights the available tools and mechanisms to help them navigate these challenges. By adopting a proactive approach and leveraging these resources, organizations can set themselves up for success during mergers and acquisitions and beyond.

About the author:

       Bryn Price headshot

Bryn Price

Bryn Price is a technologist, paragliding pilot, and Senior Specialist Solutions Architect at AWS. With more than 20 years of experience in the technology industry, from telecommunications, banking to software companies. He is now focusing on helping customers modernize their technology and transform their business to SaaS. He loves defying gravity and discussion of any topics from migration to microservices.