Mobilize

The mobilize phase of migration is a critical step in a smooth transition to the cloud. It involves comprehensive planning and preparation, guided by best practices to maximize success. During this phase, it's essential to establish mechanisms for tracking planned versus actual business benefits and assess your team's skills, implementing training plans where required. Acquire the necessary bandwidth to operate workloads while migrating to the cloud in parallel. Establish a Cloud Center of Excellence (CCoE) responsible for cloud operations, and define a comprehensive Cloud Operations Strategy, covering resource allocation, security, cost management, and governance to streamline the migration process effectively.

MIG-OPS-02: How do you report on planned versus actual business benefits throughout your migration?

We see customers with many drivers for migrating their workloads to AWS, including consolidating or vacating data centers, achieving cost savings, improving security and operational resilience, increasing business agility, and improving staff productivity. Throughout the migration, a wide range of decisions need to be made, such as the target Amazon Elastic Compute Cloud (Amazon EC2) instance type or what type of Amazon Elastic Block Store (Amazon EBS) to use. These micro decisions may have a large impact on achieving the expected business benefits at an organizational level. Defining and measuring KPIs helps make sure that the program remains on track to achieve the target business outcomes, and influences the behavior of stakeholders who are making the decisions throughout a migration. Furthermore, it helps identify when the program is trending negatively against a KPI so that remediating actions can be applied following a deep-dive review.

MIG-OPS-BP-2.1 Define and measure key performance indicators (KPIs) which can be shared with all teams involved in the migration

This BP applies to the following best practice areas: Organization

Implementation guidance

Suggestion 2.1.1: Establish KPIs that support your target business outcomes.

When determining the KPIs, it's crucial to work backwards from your target business outcome. There might be more than one target business outcome for your migration, so you usually need multiple KPIs. It's recommended to socialize the KPIs with your organization's leaders to create alignment towards the goals. For example, if you're migrating to AWS to increase your operational stability, start by determining specific KPIs that measure operational capability. This could include comparing service availability with the agreed service level agreements (SLAs), the number of unplanned outages per quarter, and mean time to resolve issues. Once this is understood, you can define how it is measured in AWS so that comparisons can be made.

For more detail, see The Importance of Key Performance Indicators (KPIs) for Large-Scale Cloud Migrations.

MIG-OPS-03: Have you assessed your team's skills, identified any gaps, and implemented a training plan while tracking progress?

There's no denying that migration entails additional work for your teams. For those responsible for operating and managing the current environment, it necessitates acquiring new skills for migrating, operating, and managing applications effectively in the AWS Cloud. This can result in hesitation or resistance. However, training your teams not only fosters familiarity with the AWS Cloud, but also offers clarity on their roles in this new environment, ultimately boosting their self-confidence in their capabilities.

MIG-OPS-BP-3.1 Invest time and effort to ensure the required migration and operations skills are captured, skills gaps identified, and training plans are implemented and managed

This BP applies to the following best practice areas: Organization

Implementation guidance

Suggestion 3.1.1: Assess your team's current skill level and training needs.

Before embarking on your migration journey, we strongly recommend conducting an AWS Learning Needs Analysis to evaluate the current roles and develop tailored training plans for each individual, aligning their skills with the requirements post-migration to AWS. Once the plan is established, you can identify knowledge gaps and begin preparing your teams. Depending on your team's existing knowledge level of migration, it's advisable to structure your training plan into three tiers: prerequisites, fundamentals, and advanced.

For a large migration project, it is essential that every team member completes the prerequisite-level training, which covers fundamental information about the AWS Cloud and migration concepts. As for the fundamentals and advanced levels, you can use a training plan to assign each workstream a suitable training tier. We recommend structuring training by workstreams rather than job roles and titles, as these can vary significantly across organizations. For more detailed information on training plans, see the following:

• Large migration training – Prerequisites

• Large migration training – Fundamentals

• Large migration training – Advanced

Suggestion 3.1.2: Include references to requirements for on-premises or legacy systems.

Having the requisite skills from day one is paramount to the successful migration of workloads, especially when dealing with the transition from on-premises or legacy estate. This is essential for maintaining and improving the level of service provided post-migration.

Suggestion 3.1.3: Consider engaging with AWS ProServe or a certified AWS Migration Competency Partner to accelerate your migration readiness.

Education is not something that happens overnight in many cases, and if there is a requirement to move faster, engaging with an AWS Migration Competency Partner or AWS Professional Services could be a worthwhile option. For more detail, contact your AWS account manager. Another great way to find individuals with the specific AWS skills you need is through AWS IQ for Experts.

Suggestion 3.1.4: Run an AWS Experience Based Accelerator (EBA).

Running an AWS Experience Based Accelerator (EBA), more specifically a Migration EBA, is another great way to improve your team's experience through migrating non-production or pilot applications, with the comfort of having AWS migration experts working alongside you. For more information, contact your AWS account team.

Suggestion 3.1.5: Leverage other available training resources available.

There are other training resources that you can leverage to improve your team's migration skills. For example, the AWS Migration Immersion Day is a one day workshop that emulates an on-premise migration and allows customers to run a migration to AWS. The migration flow is aligned with Migration Acceleration Program (MAP) best practices and includes steps from the assess, mobilize, and migrate phases.

MIG-OPS-04: Do you have the bandwidth required to operate your workloads while delivering the cloud migration in parallel?

Migration initiatives require involvement and input from various teams in order to be successful. For example, input is required from application owners to determine the move groups (like which servers and applications must be migrated at the same time), as well as shaping the target architecture. This extends to operational teams who are required to support pre-migration, migration, and cutover activities. At the same time, they need to perform the roles they carried out before the migration initiative (like maintaining workloads) and training on the AWS Cloud, so that they are prepared to support workloads once they are migrated. This makes it important to understand if your teams have the bandwidth required to operate your workloads while delivering the cloud migration in parallel.

MIG-OPS-BP-4.1 Build a comprehensive resource model for your migration that reflects the demands of the migration as well as the regular activities

This BP applies to the following best practice areas: Organization

Implementation guidance

Suggestion 4.1.1: Identify a cloud sponsor.

This sponsor serves as a driving force behind the migration, linking key performance indicators (KPIs) and objectives to the organization's overarching business goals. In essence, a migration sponsor helps navigate the complexities of migration, making critical decisions, and ultimately propelling the organization towards realizing the full benefits of the AWS Cloud.

Suggestion 4.1.2: Consider the workstreams, roles and team composition required for your migration.

Review People foundation for guidance on workstreams, roles, and team composition before you start constructing your migration workstreams and teams. When assigning resources to roles from your existing teams, be sure to assess their current utilization and where that demand comes from (like normal business operation or other business initiatives and projects).

Suggestion 4.1.3: Consider augmenting your existing teams with skilled resources from other parts of your organization or from a trusted partner.

You cannot expect to run a large-scale time-bound migration without increasing your teams' workload. If you are not time-bound, and the migration can be spread over a longer period of time, then it may be possible to use the teams you have. However, the higher the migration velocity, the sooner you realize the full benefits of being in the cloud, so it could make sense to engage additional migration resources, such as AWS Professional Services or AWS Migration Competency Partners to assist without impacting your business operations.

Alternatively, you may decide to leverage AWS Managed Services to extend your team with operational capabilities, including monitoring, incident management, AWS Incident Detection and Response, security, patch, backup, and cost optimization for migrated workloads.

MIG-OPS-05: Have you established a Cloud Enablement Engine (CEE) responsible for operating your cloud environment?

A key focus of the Cloud Enablement Engine (CEE) is transforming the information technology (IT) organization from an on-premises operating model to a Cloud Operating Model (COM). These components include the operations, security and control, platform architecture and governance, and infrastructure provisioning and configuration management functions. The target state architecture, as defined by your migration strategies and patterns, dictates the services and platforms that need to be catered for. The Cloud Enablement Engine (CEE), sometimes referred to as Cloud Center of Excellence (CCoE), is defined as a multi-disciplinary team that is assembled to implement the governance, best practices, training, and architecture needed for cloud adoption in a manner that provides repeatable patterns for the larger enterprise to follow.

MIG-OPS-BP-5.1 Build a Cloud Center of Excellence (CCoE) team within your organization as part of your migration planning

This BP applies to the following best practice areas: Organization

Implementation guidance

Suggestion 5.1.1: Review the Foundation playbook for AWS large migrations.

Familiarize yourself with People foundation, which focuses on preparing the people and processes involved in your project for the activities in each stage of the large migration. To build the people foundation, you need to define the workstreams in your project, organize individuals into functional teams, confirm that roles and responsibilities are well understood, and complete training.

Suggestion 5.1.2: Establish a cross-functional CCOE in your organization.

One of the foundational steps that enterprises take as part of their journey to the cloud is establishing a Cloud Center of Excellence (CCoE). The CCoE is a multi-disciplinary team that is assembled to implement the governance, best practices, training, and architecture needed for cloud adoption in a manner that provides repeatable patterns for the larger enterprise to follow. Many companies have found that CCOE can accelerate their migrations to the cloud and broader digital transformations. More details on best practices to creating CCOE be found in Designing a Cloud Center of Excellence (CCOE) blog post.

Suggestion 5.1.3: Define the operational support model during migration.

In a migration to cloud scenario, it is likely you need to maintain a capability to provide operational support to your on-premises environment, as well as your new cloud environment, at least while you exit your on-premises estate. Operational support for the cloud environment may come from the team that currently provides on-premises support, but frequently a new team is created with skills and experience in the cloud services to be consumed to provide operational support in the cloud. For more detail, see Building your Cloud Operating Model.

Suggestion 5.1.4: Define a RACI matrix (responsible, accountable, consulted, and informed).

A clear shared understanding of where the operational support delineation lines are to ensure a consistent and reliable operational support service. A RACI matrix can be used to capture each domain and activity and identify who is responsible, accountable, consulted, and informed in each case. For guidance on creating a cloud operations RACI matrix, see Create a RACI or RASCI matrix for a cloud operating model.

MIG-OPS-06: What is your cloud operations strategy?

When migrating to AWS, you most likely have people, tools, and processes already in place to manage your current on-premises architecture. However, what you have now may not be aligned or best suited to the environment you are migrating to. Before migrating workloads to cloud, you should establish an operational capability in terms of people, tools, and process that provides all the required operational capabilities expected by the business. Initially this may be a minimum viable product (MVP) capability aligned with supporting non-production or pilot migrations, but prior to migrating production or business-critical applications, it is strongly recommended to have a full operational capability in place, serving all necessary operational requirements.

MIG-OPS-BP-6.1 Define Cloud Operations Strategy: understand your current operating model, processes and tools, and explore how to implement them efficiently, securely and reliably in the cloud to create your cloud operations strategy

This BP applies to the following best practice areas: Organization

Implementation guidance

Suggestion 6.1.1: Prepare the people and process involved in your project for the activities in each stage of the large migration.

You need to define the workstreams in your project, organize individuals into functional teams, confirm that the roles and responsibilities are well understood, and complete the necessary training. For more detail, see People foundation.

Suggestion 6.1.2: Check the operations perspective in Cloud Adoption Framework.

The operations perspective focuses on delivering cloud services at an agreed-upon level with your business stakeholders. Automating and optimizing operations allows you to effectively scale while improving the reliability of your workload. For more detail, see Operations perspective: health and availability.

Suggestion 6.1.3: Create your cloud operating strategy and model.

The process of modernizing operations in the cloud involves readiness, automation, and integration. To be operationally ready for your migrated workloads, incorporate tools, people, and process to deliver the various activities that together create a cloud operating model. For guidance on creating a cloud operations strategy and model, see Modernizing operations in the AWS Cloud.

Suggestion 6.1.4: Train operational teams on operational AWS services.

Cloud native tools and services for operational capabilities are built for the cloud, and exhibit increased scalability, reliability, and availability. In many cases, cloud-based tools can be used to manage on-premises environments, so a transition to cloud-hosted operational tools may be a sensible approach to avoid duplication of tooling. However, your operations teams need to be trained on these new tools prior to migration. Complete an AWS Learning Needs Analysis for each member of your team to provide them an education plan to meet their role specific requirements.

Suggestion 6.1.5: Consider using managed service providers or AWS Managed Services (AMS).

If your organization doesn't have enough operational capability to fully cover your cloud operational strategy, consider using managed service providers (MSPs) or AWS Managed Services (AMS) offerings as an initial step. AMS helps you accelerate your adoption of AWS at scale and operate more efficiently and securely. AMS leverages standard AWS services and offers guidance and execution of operational best practices using specialized automation, skills, and experience that are contextual to your environment and application. For a selection of AWS-certified cloud operations managed service providers, see Find an AWS Partner. For more detail on AMS offerings, see AWS Managed Services.

MIG-OPS-BP-6.2 Align AWS operational requirements with your existing tools and identify any gaps

This BP applies to the following best practice areas: Prepare

Implementation guidance

Suggestion 6.2.1: Define your AWS operational requirements and identify operational tools. Mapping your AWS operational capability requirements to your existing operational tools and processes helps identify where there are gaps, allowing you to build an action plan to fill them. For example, you might decide to use AWS Backup to centrally manage and automate your backups on AWS. We recommend reviewing the AWS Well Architected Framework Operational Excellence Pillar for guidance on developing your operational requirements specification and the aligned AWS tools.

MIG-OPS-BP-6.3 Regularly test your operations in the cloud

This BP applies to the following best practice areas: Operate

Implementation guidance

Suggestion 6.3.1: Simulate operational events.

One way to test operational capability is to simulate life-like system failures. An effective way to do this is by running events in your organization, also known as game days. Game days test systems, processes, and team responses, and help evaluate your readiness to react and recover from operational issues. The purpose is to actually perform the actions the team would perform as if an exceptional event had happened. The Build Your Own Game Day to Support Operational Resilience blog from AWS guides you through this process and provides links to further information.

MIG-OPS-07: How many servers do you plan to replicate and migrate in each wave, and what factors have you considered when arriving at this number?

The number of servers that can be included in a migration wave, and the duration required to perform the migration, is generally dictated by the people you have to perform the migration, the applications you are migrating, the migration approach used, and the network bandwidth available between the source location and AWS.

For example, let's assume a customer has 1,000 servers to migrate in order to vacate their source data center. They're planning to rehost all of their servers using the AWS Application Migration Service (MGN) and have calculated it'll take approximately five weeks to complete a migration wave from an end-to-end perspective (including change control, governance, migrating the data, and acceptance testing). On average, their migration waves include 50 servers, so with one migration team it could take approximately two years to complete (100 weeks). However, they have sufficient network bandwidth and people to increase this to four migration teams working in parallel, so their migration could take approximately 25 weeks to complete. During the 25-week window, there's a two week change freeze where all migrations are impacted, which means their total estimated migration duration is 27 weeks, with an average velocity of 200 servers every five weeks.

MIG-OPS-BP-7.1 Calculate your potential migration velocity using both technical and non-technical perspectives (like network bandwidth, team availability, volume of changes, and change freezes)

This BP applies to the following best practice areas: Prepare

Implementation guidance

Suggestion 7.1.1: Determine how many migration waves you need.

When calculating how long your entire migration may take, we recommend first determining how many migration waves you need to perform based on the size of the in-scope estate and how they are migrated.

Suggestion 7.1.2: Assess available non-technical resources.

Assess your human resources to determine how many waves you can run in parallel to achieve the target outcomes, and validate it aligns with the business goals.

Suggestion 7.1.3: Determine technical limitations like bandwidth.

Assess your network bandwidth to estimate how many waves you can run in parallel to achieve target outcomes, and validate it aligns with the business goals. For more detail, see AWS Application Migration Service best practices.

Suggestion 7.1.4: Include process estimations such as change management, testing strategy, and outage and maintenance windows.

Don't forget to include aspects like change freezes, which impact the migration.

Suggestion 7.1.5: Understand the volume of change necessary for each application in-scope for migration.

Your migration velocity is heavily influenced by how well you know your applications. When using rehost to lift and shift your applications to the cloud, there may still be configuration changes required for the application to work as expected after migration. You need to know what configuration changes are required, who can perform them, how long they will take to perform, and if the changes can be automated. This information should be gathered in a discovery exercise during the migration planning phase and should influence the applications that are assigned to each migration wave. You should have the people required to make these changes (ideally with automation) during the migration event so that the cut over can be performed within the expected time frame. For more detail, see Application portfolio assessment guide for AWS Cloud migration.