Accelerate Your Enterprise On-Premises Migration to AWS Cloud

In this blog post, we will explore the top five guiding principles that you need to address before starting a large-scale migration from on-premises to the AWS cloud.

As the AWS Professional Services team, the authors bring their combined experience in leading large migrations involving thousands of applications in datacenter exit projects across Healthcare & Life Sciences (HCLS), Energy (Oil & Gas), Financial Services, and the US Public Sector industries. We recognize migrating to the cloud can be a daunting task, especially for large organizations.

The top five guiding principles were developed in response to common delivery impediments encountered during our large-scale AWS migrations, including, stakeholder misalignment, lack of cloud adoption strategy, inadequate cloud knowledge, tendency to compare cloud cost and ignore the agility cloud offers in terms of reduced time-to-market, service enablement delays, insufficient migration backlogs, migration project false starts, post-migration technical issues, and compliance validation processes. Embracing these principles can yield the benefits of an accelerated and predictable migration timeline, curb migration costs, and reduce your overall cloud migration delivery risk.

Once your application is migrated to AWS, consider modernizing your applications to take full advantage of AWS features and services.

1. Issue a Top-down Executive Directive

The first step in your enterprise cloud migration is obtaining a clear top-down directive from executive stakeholders. The top-down directive is an instruction to the entire organization, a call to action, and provides the organization with a clear goal and success criteria, fostering cross-organizational engagement. The process of obtaining a directive will help organizations develop a shared understanding of their current state and alignment of goals for their cloud journey. This will also pave the way for finalizing resource allocation and funding for cloud migration.

Without a clear mandate for cloud adoption, the migration process can become disorganized, and there may be lack of consensus on direction of the migration.

Goal and Success Criteria

A top-down directive defines the goal, outlining what the organization wants to achieve by migrating to the cloud, and how it benefits the organization. Several examples are:

We need to exit our on-premises datacenter by 2025 so we reduce our IT total cost of ownership (TCO).

We will migrate all of our workloads from on-premises to the cloud by 2026 so we can reduce time-to-market and maintain security posture as we grow.

Issue the Directive

The directives are typically provided through multiple channels starting from customer’s top executives down to business line managers and technology owners. An example we have seen of effective top-down directive is when a customer’s senior VP and CTO championed the cloud-adoption in their company-wide town hall meetings run by their CEO. Their direct reports in turn emphasized the message in recurring monthly meetings. The CTO and business line VPs pushed out recorded short video messages for offline viewing through their internal portals. This helped their employees and IT owners understand the cloud adoption strategy and change their perception on how they viewed cloud adoption within their organization.

Through a goal and success statement with cohesive messaging, leadership can paint a compelling picture of the future state by articulating the benefit of the cloud migration and highlighting how it aligns with the organization’s long-term objectives; therefore, reducing the delivery risks of stakeholder misalignment and lack of cloud adoption strategy.

Once the directive is issued it is equally as important to track the goal and Key Performance Indicators (KPIs) throughout the migration journey. Measuring the directive against explicit and well-defined KPIs curb migration timeline and costs by keeping the effort solely focused on the necessary outcomes, reducing the potential for scope creep.

2. Establish a Learning Mindset and Cloud Center of Excellence (CCoE)

A Learning Mindset

An organization should place an emphasis on adapting practices for cloud, which evolves rapidly and provides unprecedented opportunities for business transformations. Most cloud-savvy organizations offer multi-faceted learning approaches such as instructor-led Immersion Day workshops, Certifications programs offered by AWS or AWS training partners, and an AWS sandbox environment. The sandbox environment is an AWS account for employees to perform hands-on labs to sharpen their cloud skills and experiment with cloud as part of their day-to-day job, without impacting their business applications.

A diverse AWS training program will help address the delivery gaps of inadequate institutional cloud knowledge and realize the agility cloud offers in terms of service offerings through the upskilling of the organization.

Cloud Center of Excellence (CCoE)

Create a small group of five to ten people from different business segments, with cross-functional skills and experience that can take responsibility to develop approaches and procedures for cloud adoption. This small group is your Cloud Center of Excellence (CCoE) and they are critical to building trust, engaging broader organization, and building framework and operational best practices for cloud consumption at scale.

The CCoE members treat cloud as a product and the cloud consumer as a customer. They create mechanisms for their customers to consume cloud effectively in their organization. The CCoE group often evolves as the organization’s cloud consumption increases, and may no longer be required when cloud adoption reaches maturity in your organization.

The CCoE is often tasked with developing a framework for adoption of cloud services and is responsible for identifying, evaluating, and onboarding new cloud services or tooling required for large-scale migrations.

Refer to the AWS Whitepaper on Building a CCoE to transform the entire enterprise for CCoE design and formation guidelines.

3. Identify and enable the required services

The policies and guardrails adopted in large organizations during their early foray to the cloud are often not revised to keep pace with the changes in cloud services and best practices for cloud adoption at scale.

Traditional Allow listing

The original purpose of “allow listing” IT products was to ensure the tools were compatible and integrated into the existing IT landscape and tools, minimize the risk of a harmful security event caused by execution of malicious or vulnerable code, and maintain compliance with relevant industry standards and adherence to vendor use agreements. Many large organizations treat cloud services as “products,” and therefore require each service progress through the same allow listing process as traditional IT products before approving its use within their cloud environment. This usually entails creation of internal service documentation (standard operating procedures, work instructions, checklists), testing activities, and approval from multiple domains (legal, licensing, security, networking, system administration). Therefore, it is important to account for the organization’s allow listing process for discovery tools, migration tools, and AWS services that are currently not enabled within their organization. Additionally, remember to account for lead time necessary to change their current toolsets, operational procedures, and to conform to the organization’s cadence for releasing the approved products.

Refer to AWS Application Discovery service and AWS Prescriptive guidance on Migration tools for details on migration discovery tools.

Start with the Essentials

The number of AWS fully featured services is over 200 and growing. This sheer number of offerings can be overwhelming when deciding which services to prioritize for allow listing within your organization. If the organization is a cloud novice, then ensure the foundational services covering compute (Amazon EC2, AWS Lambda), storage (Amazon S3, Amazon EFS), networking (AWS VPC, Amazon Route 53), database (Amazon RDS, Amazon DynamoDB), and security (AWS IAM) are allow listed and consumable by users throughout the organization, before embarking on your migration journey.

Once the foundational services are enabled and consumable, then you can shift focus to allow listing your migration services. AWS offers a myriad of migration services tailored to various use cases. The staple services to prioritize for enablement are AWS Application Migration Service (MGN) to replicate your servers to Amazon EC2 instances, AWS Database Migration Service (DMS) to convert database workloads to Amazon RDS, and AWS DataSync for moving network attached storage and data to Amazon S3 and other AWS native storage solutions. As your organization matures in its adoption of AWS services, there are additional migration patterns built for optimizing migrations at-scale, such as Cloud Migration Factory on AWS.

Enabling Cloud Services

Often organizations with strong CCoE practices are integrated into the organization’s allow listing processes and may have procedures to fast-track the enablement of essential cloud services through some of the approvals. For example, your organization’s CCoE may setup a cross-functional approval team with representatives from each domain to meet, review, and approve services on a reoccurring two-week cadence. However, modifying an existing allow listing process to incorporate a fast-track approach takes a significant amount of trust from your customer. If your CCoE is newly minted, building the customer’s confidence by enabling cloud services through their existing allow listing process may be the prudent approach.

An understanding of your organization’s “allow listing” approach, and the expectations for cloud service enablement within their environment will reduce the risk of service enablement delays. Furthermore, integrating your CCoE into the allow listing and implementing the fast-track mechanism may accelerate the overall migration project timeline.

4. Build migration candidate queue

Building a healthy queue of migration candidates before starting large-scale migration waves is critical to effectively utilize the migration team resources to drive the customer business objectives at a predictable cost and timeline. A mature migration queue building process must factor in business priority inputs from customer stakeholders, application owners, infrastructure, and business teams.

Establish Prioritization Criteria

Using a prescriptive approach with well-defined prioritization criteria to build your migration queue provides workload owners transparency into the reasons for the ordering of workloads within the queue and groupings into migration waves. The predefined queue of workloads makes the process more understandable and predictable for everyone involved, and sets expectations around the workload priorities and migration timing early on.

A migration queue helps uncover technical constraints and potential issues that need to be addressed before migrations begin, and affords the migration team’s availability to dive deep on technical dependencies and adjust the queue as needed up front. This minimizes the potential of unknown risks becoming realized as issues during migration execution causing costly post-migration re-work or rollbacks.

Perform Wave Planning

Once your healthy migration queue is built, then the migration team will be able to plan migration waves with emphasis on prioritizing less complex applications upfront, apply learnings iteratively from earlier waves, and tackle increasingly complex applications to achieve desired migration velocity without causing undue business risk due to the migration. During the migration wave, sometimes migration schedule and application team availability to support the migration will conflict. Thus, it is imperative there are sufficient application candidates in the queue that can be drawn upon to compensate for applications delayed or dropped from the migration wave. A full migration queue and well-constructed wave plan will directly combat insufficient migration backlog issues and mitigate technical delivery risk which can hinder your migration timeline.

Refer to the AWS Prescriptive guidance Mobilize your organization to accelerate large-scale migrations, and Application portfolio assessment strategy for AWS Cloud migration for detailed instructions on how to build migration candidates queue and other meet prerequisites for your migration journey.

5. Develop Tailored Testing Approach

Communicate early in the engagement that the ownership for the application testing belongs to the application team who owns the workloads in scope for migration. Only focused testing targeting the functional areas altered by the migration process needs to be retested. Extensive regression testing is often not required for applications Rehosted and Replatformed with tools such as AWS MGN and AWS DMS.

Migration Methodology based Testing

The amount of application testing required as part of migration is highly dependent on methodology used for migrating the application to the cloud. Minimal smoke testing is generally acceptable for Rehosted workloads. Conversely, full regression testing is required if an application is Refactored or rearchitected as part of a migration. You should help application teams understand the impact of migration to their workloads based on the migration methodology, and then assist with identifying test cases that needs to be tested. This might include pointed integration testing of functionalities that rely on databases, external storage (Network File System, Server Message Block) systems, load-balancers, cluster caches, and functionalities of any other application sub-systems altered by the migration. Tailoring the testing approach based on the migration methodology avoids costs of unnecessary testing, and reduces the risk of post-migration issues.

Industry Compliance Prescribed Testing

Your organization may be subject to specific post-migration testing requirements based on the industry or country it operates in. For example, life science organizations that make food and medical products are generally subject to GxP compliant testing requirements. In the financial sector, entities that store, process or transmit cardholder data (CHD) are subject to PCI DSS compliance. Understanding your industry’s specific regulations up front will help you proactively plan for any specific testing requirements to maintain compliance.

For applications under compliance regulations, identify, assess, and document areas that are impacted by the migration and develop test cases that validate the impacted areas and ensure the validation method employed and evidence captured adequately meets the regulatory authority guidance. Remember to update the application architecture for infrastructure changes and operational changes from cloud migration, and engage your organization’s designed reviewer to review validation procedures and document the validation results. Validating and documenting industry prescribed testing will reduce the risk of a compliance issue post-migration.

Ready to Migrate!

In this blog, we covered five principles you should address before embarking on your large-scale migration journey. To begin, engage your preferred partner from our AWS Partner Network or work with AWS Professional Services to plan and execute your cloud migration and modernization.

Alas, your journey will not end with the migrations! As this blog site’s title suggests, migrations are only part of a cloud journey. Developing a mature AWS Cloud Operations model will also be crucial to post-migration sustainability and enablement on AWS.

About the Authors