A 6 step approach for enabling large scale migrations on the cloud

Context and objective:

Enterprises often have different maturity levels of cloud adoption within their application base.  Some applications are huge monoliths (i.e., huge server workloads) and are running on virtualized set ups or as containerized microservices. These create enormous datasets and workloads over a period and makes the process of migration highly complicated without a well-defined approach. In this POV, we will discuss about a 6-step approach that needs to be practised to enable large scale migrations of such workloads.

Figure 1: A methodology for enabling large scale cloud migrations

Stage 1: Discover workloads and finalize migration goals

Understanding business drivers to plan your migration goals

It is imperative to discuss and understand the drivers behind a cloud migration and what business wanted to achieve in the first place. For instance, business drivers could often shape up a migration strategy on whether a business wanted to rewrite the monolith into discrete services and then migrate these over to cloud or take up a monolith to the cloud first and then start thinking about decomposing components into microservices architecture. The latter is the preferred and called as lift-and-shift versus other strategies. The Business drivers can often help us to determine if we can remain invested on these applications, as they can strategically benefit in the long run.

It is essential to pin down the different migration goals, as described below.

• Invest

In this approach, we keep long term benefits in mind and remains invested in the applications that we choose to migrate.

• Sustain

Here, we can come up with a plan to lift-and-shift all workloads that are classified as IaaS. Similarly, we can choose to migrate the workloads on PaaS or SaaS platform. The most modern cloud providers support us on all three categories.

• Exit

For applications with fewer benefits, it is better to exit from the migration plan or objective.

Other factors can also influence the migration approach:

• Applications on a particular tech stack that need to be sustained.
• Applications using a DB engine at the end of its life that need to be replaced.
• Business apps considered ‘super critical’ that won’t be considered for migration.
• Applications with such a high technical that it would be better to invest in better technology.

Stage 2: Identify migration paths

The decision on IaaS, PaaS or SaaS platforms can influence your migration strategies. We can potentially come up with a plan to lift-and-shift all workloads that are classified as IaaS. Similarly, we can choose to migrate the workloads on PaaS or SaaS platform. The most modern cloud providers support us on all three categories. The following figure broadly illustrates how to identify the ideal migration path.

Figure 2: Identify a migration path

Stage 3: Prepare use cases and choose a migration strategy

When it comes to Migration Strategy, the most popular strategy is 7R migration strategy.

The below decision tree approach can be used to determine the right 7R strategy for your organization’s needs.

In a nutshell, start with defined goals and create a decision tree according to your migration path using the 7R strategy.

Figure 3: Decision tree to help choose a migration strategy

The 7 different migration strategies discussed above are:

• Retire
• Retain
• Rehost
• Relocate
• Repurchase
• Re-platform
• Rearchitect

The most adopted strategies in large migrations are ‘rehost’, ‘replatform’, ‘relocate’ and ‘retire’. ‘Rearchitect’ would not be recommended for large migrations as it involves modernizing the application during the migration. The below graph shows which migration strategy can yield maximum benefits at the cost of innovation.

Figure 4: Migration Strategy providing quick wins

Stage 4: Identify common migration patterns

What determines a migration pattern?

A migration pattern is unique and based on the preferred choice of a migration journey. The pattern clearly states what is needed in terms of skills, costs, and resources/assets. For each infrastructure component (App or DB) to be migrated is it important to:

• Determine the migration objective/goal and its path
• Pick the right ‘R’ from the 7R migration strategy
• Select the right target state cloud service based on ROI cost, business benefit and skillset needed

Figure 5: A migration pattern

The above combination will form a unique migration pattern. There are multiple migration journeys for each application that are grouped by common characteristics and each journey could form a reusable pattern.
A migration pattern can be influenced by factors such as business benefits, cost of migration, skillset, or people requirements.

Figure 6: Factors influencing migration pattern

The different migration patterns offer a way to create a plan by grouping applications using similar technologies or characteristics.

Figure 7: example of a set of migration patterns

Stage 5: Prepare a business case and plan a migration roadmap

A migration business case must be compelling for a migration pattern and should clearly outline its benefits. It should also include a clear roadmap to achieve those benefits. This roadmap might even create new opportunities such as:

• Building a cloud platform for simple patterns
• Building an iterative plan for rolling out more complex patterns next.

The migration business case should also include the different waves to complete the migration journey. Typically, it will start with highly automated migration patterns, followed by partially automatable ones and finally with limited automation, requiring a higher level of human skills.

• Wave 1: Rehost – Highly automated
• Wave 2: Re-platform – Partial automated
• Wave 3: Refactor – Limited automation. Requires Human skill.

Planning and mobilizing the required resources is essential. Experience with large-scale migration shows that it is better to start simple to then progress to more complex applications and requirements, while consistently delivering business value.

Figure 8: Migration Wave Planning

Stage 6: Set up a migration work factory

To increase the scale and speed of migrations, factories must be set up. The standardization (skill set, commonalities in migration strategies, from current state to target state) and automation potential (based on choice of target state cloud services) of migration patterns determine the composition of these factories.

Some of them can be highly automated. For example, rehosting applications to Amazon EC2 can be conducted in a largely automated manner, using the AWS server migration service and by converting source servers from physical, virtual, or cloud infrastructure to run natively on AWS.

Migration factories for re-platform patterns will be partially automated. For example, the AWS Schema Conversion Tool (AWS SCT) automatically converts the source database schema and most of the database code objects to a format compatible with the target database. For those patterns with partial or limited automation, we must establish a standardization process by creating runbooks and considering automation scripts for repetitive tasks.

The migration factories operate by building assets such as:

• Runbooks
• Automation scripts

The migration factories can be constituted based on the required skillset and complexity of implementing the migration pattern.

Conclusion:

The 6-step approach thus discussed helps both the Enterprise’s business strategy and technology office to prepare for large scale migrations and acts as a key primer for your migration journey. The strategy or Business teams can influence the decision-making process by clearly stating their priorities, migration goals and help choose the appropriate migration strategy. And the Technology team can then lay out all the applicable migration patterns and create a migration wave planning and an execution roadmap.