Cloud Migration Strategies (Part 2)

In part one of this series, we discussed AWS programs which provide migration assistance and guidance for organization transformation such as Cloud Adoption Framework (CAF) and Migration Assistance Program (MAP).

In this post, we discuss different migration strategies and AWS services which may improve your experience and effectiveness.

First, let’s review the seven migration strategies recognized by AWS:

1. Re-hosting
2. Re-platforming
3. Re-purchasing
4. Re-factoring
5. Retiring
6. Retaining
7. Relocating

In this post, we will focus on the two most common migration strategies: Re-hosting and Re-platforming.

Lift and Shift (Rehosting)

Lift and Shift is the simplest way to start a migration process. The basic approach here is to take everything from a source and move to the cloud ‘as is’—although additional work is still required, such as preparing Amazon Machine Images, creating VPC, and other tasks.

Here are the pros and cons of the Re-hosting and Relocating migration strategies:

Pros:

• Simplicity – no need to refactor source code of an application
• Speed – this is the fastest way to complete a migration
• Legacy apps – with lift and shift it is possible to migrate legacy apps which could not be refactored for various reasons
• Lower costs – this is the cheapest migration approach compared with others

Cons of Rehosting (Lift and Shift):

• Rate of cost optimization – with Lift and Shift it is not possible to achieve the same rate of cost optimization as we would achieve using other approaches
• Missed opportunities – not all services and potential cloud benefits are available using the Lift and Shift approach

Lift and Shift or Relocate is a good approach to start the migration process while getting a feel for cloud benefits. After initial steps are taken, our customers frequently look at expanding cloud service usage, which brings us Re-architecture.

Re-Architecture

Re-architecture is the most advanced migration approach and is used to fully adopt applications and underlying infrastructure for the cloud. Re-architecture is typically a long process and requires application developer and infrastructure engineer involvement because significant changes (to apps and infrastructure) are required.

However, re-architecture offers the best value to the customer in terms of fault tolerance and disaster recovery. This strategy also allows businesses to capture all benefits provided by AWS—not only in terms of infrastructure, but also with continuous integration and deployment (CI\CD) providing faster time to for new features, improved release processes, and enabling disaster recovery.

Here are the pros and cons of the Re-architecture migration strategy:

Pros:

• Highly scalable – applications built with cloud in mind are extremely scalable
• Faster Time to Market – once correctly implemented, re-architected applications can be easily modified, tested, and released using AWS

Cons:

• Expensive – re-architecture is the most expensive approach to implement since it requires significant changes in infrastructure code, and very often to application code as well
• Business transformation – to effectively use applications in the cloud, transformation (modernization) of some business processes is required

Summary

Rehosting is often the starting point for migration to the cloud, but often (once cloud benefits are experienced) an expansion to Re-architecting strategy occurs given its long-term advantages and benefits.

However, Re-hosting and Re-architecture are not used exclusively in most cases. Often, a mix of strategies is used to address all customer requirements.

For example: While much can be migrated as is, some infrastructure components shouldn’t be migrated at all because they have managed service analogues in AWS. Other times, different components need to be rewritten (or changed entirely) for hosting on a cloud. In such cases—the migration output is a mix of Lift and Shift (Rehosting), Retain (for non-migrated components), and Re-architecture (for rewritten or changed components). This happens to be the most common mix we see with our customers at SoftServe.

In the final installment of this three-part series, we’ll take a closer look at AWS technical services that assist with the migration process.

Stay tuned!