Selecting your first workloads to migrate your organization to Amazon Web Services (AWS).

Introduction

Selecting your first workloads to migrate your organization to AWS is a key stage in delivering a successful migration.

In this blog post we provide guidance on how to select early migration candidates. We cover how selecting these candidates can help to kick-off a successful migration, reduce risk, and build skills inside your organization.

In this post, we define a ‘workload’ to be a collection of resources and code that delivers business value. A workload can be a customer-facing application or a backend process.

AWS recommends a three-phase approach: Assess, Mobilize, Migrate and Modernize. The stages provide a well-defined roadmap for moving applications. It is important to understand that the first two phases (Assess & Mobilize) are more like a cycle than separate steps.

Phase of migration journey

This post is intended for customers that have completed the Assess phase and have gathered or completed the following information:

Approved business case and total cost of ownership (TCO) analysis.
An assessment of your organization’s readiness for the migration.
A portfolio discovery assessment and analysis.

Criteria and Risks to consider when choosing your first workload

A successful migration is one that helps achieve your business objectives while minimizing business impact and risk throughout the migration. Here are key business focused criteria that can be used to evaluate the first workload to migrate:

Impact of migrating the application – In a large-scale migration, certain workloads will present more impactful migration opportunities than others. For example, migrating a workload that has a high run-cost on-premises or one that cannot scale to meet demand due to infrastructure constraints. Prioritizing these applications help organizations realize cloud benefits faster.
Mitigating circumstances – External circumstances will affect how you approach the migration of specific workloads. For instance, evaluating application obsolescence including end of support for software or hardware, data center contract expiration, or licensing agreements. These workloads are often prioritized based on deadline constraints.
Technical team skill development – Technical teams performing the migration are key in delivery a successful migration. If your technical teams are not experienced in cloud migrations, choosing a workload which is deeply understood to migrate first is recommended. This will help the team to focus more on the cloud aspects of the migration over learning about the application.

When considering these points, it is key to consider the risks aligned with migration of applications and how these should be considered alongside the preceding criteria. Here are risk-based criteria that can impact how you choose your first mover candidates:

Business criticality – Migrating business critical workloads naturally increases risk. Any issue that arises during a migration will have a wider and more profound impact on your organization. It’s recommended business critical workloads are not chosen as first movers unless required.
Technical complexity – Migrating complex workloads can introduce more risk to a migration. When early on in the migration, it’s recommended to avoid complex workloads until cloud migration skills and comfort have been built.

Key attributes that add to migration complexity:

Dependencies/integrations – Workloads that have numerous dependencies and are tightly coupled with other internal/external systems. These require significant planning to insulate dependencies from impacted after migration. Attention should be given to the monitoring and observability of these dependencies and integrations before the migration to validate the health of the system post-migration.
Number of servers/components – Large applications with numerous components and large numbers of distinct servers. These often require numerous migration waves that may lead to running the application across an on-premises environment and the cloud.
High SLA and uptime requirements – These applications require more complex migration patterns are addressed such that the migration can be completed while continuing to meet these requirements.
Documentation and internal knowledge – Migrating applications with poor knowledge or documentation introduces risk due to unknowns inside the application. It is recommended to wait until tech teams are both upskilled and have foundational experience in migrating workloads to the cloud.
Software support status – Upgrading operating systems and software components can lead to large amounts of effort and testing. This is compounded when a clear upgrade path is not available. For commercial off the shelf (COTS) applications it may require additional planning with the software vendor.

Key risk mitigations to be considered and applied where appropriate:

Work with an AWS Partner – Cloud Migration skills and experience are the most important risk mitigation strategy for completing a migration. If your teams require additional support, consider an AWS Partner with the AWS Migration Competency to support your team.
Selecting the right migration strategy – Modernizing workloads to be cloud native often helps to garner more benefits from your cloud strategy. However, it is suggested to select a migration strategy such as Rehost or Relocate with a lower impact of changes to the application as a first step. It will then be simpler to modernize your application when it is already in the Cloud.

These criteria and risks will naturally present conflicts leading migration teams to ask: “When should we prioritize a complex workload that has strong business benefits once migrated?” In the next section, we present a way of evaluating and weighing these decisions.

Evaluating Workloads

We recommend evaluating workloads in a data driven way, by ranking a set of important business criteria using a matrix. In creating a matrix, you will select several key criteria and assess each of your workloads against them. This will help you select and prioritize the first-mover workloads.

In this example for AnyCompany, an organization in the supply-chain industry with over 5,000 employees. They are planning to migrate to AWS, but currently have limited cloud skills. They have an expiring data center lease in 24 months and are focused on migrating fast, minimizing risk where possible.

AnyCompany has a mixed level of documentation on their internal applications. Application owners with historical knowledge are no longer with the company.

Building strong technical skills is important to AnyCompany. Increasing skills will help them be increasingly self-sufficient during migrations. We selected business criteria based on the speed of migration, the ability to be self-sufficient during the migration and those with low business risk:

A table showing application names with various scores for migration priority.

Fig. 1. Prioritization table for the application portfolio. We are selecting the application with the highest score to migrate first.
¹ – Business Criticality – (1 Most Critical – 5 Least Critical)
²– Technical Complexity – (1 Most Complex – 5 Least Complex)
³ – Business Impact (1 Low Business Impact/Benefit – 5 High Business Impact/Benefit)
⁴– Mitigating Circumstances – (1 no time pressure – 5 urgent, requiring immediate attention)

In the preceding table, we can identify the first mover as an internal web portal with the highest score of 13. It has relatively low criticality, low technical complexity and the knowledge of the application is high. This aligns well with the organization’s priorities.

However, looking at the Mitigating Circumstances column, we see that other applications like Quality Management System have extremely high urgency. AnyCompany must prioritize these applications.

To emphasize this priority for migration, we can introduce an additional weighting on attributes. In this case, we want to increase the importance of the mitigating circumstances column. We do this by increasing the weight to 1.5x and recomputing the scores. The following table is updated with the new weights:

A table showing application names with various scores for migration priority.

Fig. 2. Prioritization table for the application portfolio with adjusted weighting.
¹ – Business Criticality – (1 Most Critical – 5 Least Critical)
²– Technical Complexity – (1 Most Complex – 5 Least Complex)
³ – Business Impact (1 Low Business Impact/Benefit – 5 High Business Impact/Benefit)
⁴– Mitigating Circumstances (1.5x Weighting) – (1 no time pressure – 5 urgent, requiring immediate attention)

The mitigating circumstance of an upcoming data center contract expiry creates pressure to migrate this application first. These weightings are necessary when assessing these criteria to emphasize key factors during a migration scenario.

Conclusion

In this post, we show you the importance of selecting the and prioritizing workloads to ensure the success of your cloud migration . We discussed the key factors, risks and mitigations that play a part in the selection process. Additionally, we covered a mechanism for comparing applications.

Each organization will likely have additional or different criteria that are important to them. These will be a mixture of business and technical points. The approach discussed in this blog post is useful early in the migration journey and can be extended with new criteria for further wave planning.

Adjusting criteria and their weighting after skills and experiences are gained throughout the migration can also create more value. Once the migration is complete, there are opportunities for modernization of your application portfolio.

The following section identifies further readings with more resources to increase your knowledge in other areas of a cloud migration.