You will find some good information about migration to the especially about 6R’s and Stephen Orban very good AWS article https://d1.awsstatic.com/Migration/migrating-to-aws-ebook.6f16dabc1b65467039fb565f3af32ea0d091325f.pdf
In the second phase of The 5 steps for a successful Migration to the Cloud – Organizations typically begin to think about what migration strategy to use for each application. In this article, we will cover the 6 common migration strategies which vary in three key areas:
Organizations usually begin to think about how they will migrate an application during Phase 2 of the migration process. This is when you determine what is in your environment and the migration strategy for each application. The six approaches detailed below are common migration strategies employed and build upon “The 5 R’s” that Gartner outlined in 2011. You should gain a thorough understanding of which migration strategy will be best suited for certain portions of your portfolio. It is also important to consider that while one of the six strategies may be best for migrating certain applications in a given portfolio, another strategy might work better for moving different applications in the same portfolio.
- Lead time to migrate
- Cost of migration
- Level of complexity
Application Migration Strategies: “The 6 R’s”
Figure 1-2 : The Six Common Migration Strategies souce AWS.
The 6 most common application migration strategies we see are:
Rehost
In rehost, applications are migrated to the AWS cloud without making any change to the components (application code, database etc.) of the application hence also known as “lift and shift”. In a data centre environment, its similar to moving an application hosted in one data centre to a brand new data centre with no change to the application. It is the most widely used migration strategy as it accelerates migration of application to the AWS cloud, enabling organisations to meet specific business objectives.
Given the “lift and shift” method, rehosted applications are in most cases not fully optimised to run in a cloud environment and will require further enhancement post migration to be fully cloud native. However, depending on the business objectives, some benefits can be realised by just rehosting the application. For instance, GE Oil & Gas saved roughly 30% of its costs by just rehosting without implementing any cloud optimisations. It’s widely used for applications that require quicks wins such as:
- Global reach
- High availability
- Variable traffic e.g. test and development environments
Replatform
In replatforming, organisations implement a couple of cloud optimisations without changing the core architecture of the application. These optimisations are mostly around utilising the managed service offerings provided by AWS, which takes away the heavy-lifting, enabling organisations to focus on driving business value. Another use case is where an organisation decides to move away from using expensive software licenses to a more cost effective software or open-source model.
For example, if an application is currently using Apache ActiveMQ as the message broker service, as part of the migration, the application can be replatformed to use Amazon MQ, which is a managed service for Apache ActiveMQ. This will eliminate the operational tasks of managing the provisioning, setup and maintenance of ActiveMQ.
To replatform with AWS managed services offerings will require a broad understanding of these offerings, and the technical know-how to integrate the existing application using, where available, AWS and third party vendor tools.
Repurchase
This strategy involves moving to a Software as a Service (SaaS) model of consuming software. In an enterprise, it is typical to find an off-the-shelf software by Independent Software Vendors (ISV) used within the organisation that needs to be migrated to AWS.
Simply moving the application using the rehost strategy may not necessarily be the best option due to:
- The current version not optimised to be deployed on a cloud environment
- The current terms and conditions not allowing a bring-your-own-license (BYOL) model to the cloud.
- The underlying datastore not being supported in the cloud
Most ISVs provide a cloud ready version of their application in AWS Marketplace and its recommended to purchase a cloud native version or another software with similar capabilities. Using the SaaS model also ensures the application is always up to date with the latest features and updates.
Refactoring
In refactoring, the application is re-architected and re-built with a new code base in order to utilise cloud native features. This strategy is used primarily where the business objective is to improve agility, scalability and performance of the application that is otherwise not achievable with the current architecture.
This usually comes in the form of revamping a monolithic application, with tight coupling and single point of failure to a micro services architecture using containers. The migration to AWS can be used as the driver to refactor the application to use cloud based services and architecture patterns.
However, given the considerable changes to the architecture and application code base, it will require the most time and resources when compared to other strategies. It is therefore recommended to be used where the emphasis is not on speed of migration but on the long term transformational benefits.
Retire
The data gathered during application discovery can be used to identify legacy applications that are currently dormant or similar applications that perform same function. According to AWS, as much as 10% of an enterprise IT portfolio is no longer useful and can simply be turned off.
This is an opportunity to consolidate and decommission these legacy applications which will eliminate the operational costs (additional cost savings) and enable IT resources focus on critical applications.
Retain
The retain strategy, also known as “DO NOTHING”, is used where there is no current business justification or benefits of migrating the application to the cloud with a plan to review the decision later down the line. For example, applications that fall into the following categories:
- Running on data centres that have just gone through an upgrade/refresh with a long term license
- Need to comply with regulatory requirements on where data can be stored
- Need to comply with security standards not currently supported by the cloud provider
- Business critical
Retained application can be revisited at a later time when it may be potentially be more beneficial to migrate the application.
Conclusion
Planning out your migration to AWS cloud requires making a decision on the migration strategy to adopt for each application. The figure below shows how the 6 strategies vary with respect to project timeline to migrate, cost of migration, and level of complexity.
Figure 2: Migration Strategies – Cost of Migration versus Project Timeline
However, the application characteristics and business objectives should be the key deciding factor. For example, if the business objective is to reduce capex cost of running a virtualised application with a micro-services architecture, rehosting can be adopted. On the other hand, if the business objective is to improve business agility of a monolithic application, refactoring should be the preferred option.
For organisations at the early stages of cloud adoptions, it’s recommended to start with applications that can be rehosted to help build confidence and achieve some “quick wins” while applying the learnings to future migrations.
