Article Migrating to AWS – 6 R’s Migration Strategy
By Ozioma Uzoegwu / 6 Mar 2019 / Topics: Cloud
By Ozioma Uzoegwu / 6 Mar 2019 / Topics: Cloud
In the second phase of the Five Phase Migration Process - Portfolio Discovery and Planning - organisations 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:
Figure 1: The Six Common Migration Strategies
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:
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.
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:
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.
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.
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.
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:
Retained application can be revisited at a later time when it may be potentially be more beneficial to migrate the application.
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.
If you are interested in finding out more, please contact your Insight Account Manager or get in touch via our contact form here.
Why not read part 1 of our Migrating to AWS series - "The 5 Phase Migration Process"
