A Practical Guide to Understanding the 6Rs for Migration to AWS
When an organization is considering migrating an existing application to AWS they have six options to choose from – known as The 6Rs – for each application. That's right: you need to choose the right tool for the job! But how?
Cloud migrations are anything but straight-forward. Learning on the job will be slower, more error prone and error-prone than using an experienced partner like Cloudsoft. For one thing, you have to make sure your target AWS environment is well-architected before you start. Even a well migrated application will run badly (cost more, poor security, low resilience, poor responsiveness) in a badly configured AWS environment.
This is the first post in a five-part series that takes you through practical advice on migrating applications to AWS. Follow @cloudsoft on Twitter or use our blogs RSS feed.
- Part 1 – A Practical Guide to Understanding the 6Rs for Migrating to AWS
- Part 2 – Migrating to AWS Method 1 – Repurchasing, aka Drop-and-Shop
- Part 3 – Migrating to AWS Method 2 – Rehosting, aka Lift-and-Shift
- Part 4 – Migrating to AWS Method 3 – Replatforming, aka Lift-and-Shape
- Part 5 – Migrating to AWS Method 4 – Refactoring, aka Cloud Native
In this first post, we leverage Cloudsoft experience in migrating, running and evolving applications on AWS to unearth the real practical advice to help anyone on this journey.
- Why are some applications not migrated to AWS?
- What drives applications to be migrated to AWS?
- How do you decide on a migration method per-application?
- What are the magic qualities to look for in a migration partner?
If you want to go straight to the full white paper, get it here.
1. Why are some applications not migrated to AWS?
Two of 6Rs – Remain and Retire– are decisions to not migrate an application to the cloud. Why do organizations choose not to migrate to the cloud?
Three reasons to Retain applications outside AWS
- Existing, significant sunk cost for non-cloud which necessitates the business to sweat existing assets and practices.
- Legacy OS and applications are not supported in the cloud
- The business justification for migrating is insufficient
Note: In the 2018 Rightscale State of Cloud report, cloud "beginners" talk about "security" as being a serious "challenge" to going to the cloud. Security is NOTa reason to Retain an application and not migrate: security today is a reason to move to the cloud, unless you have uniquely special niche security reasons not to do it. These should be challenged firmly.
Four reasons to Retire applications and avoid migrating them to AWS
Why migrate stuff you don't have to? This is like taking some of your unused belongings to the dump before you move house!
- Applications found during a Discovery project are no longer required (sometimes the fact they are still running is a “surprise” to the organization, and just turning them off can yield significant savings).
- Applications may be duplicated in the organization so some can be retired
- There may already be a decommissioning or consolidation project in progress, and the application is that scope
- The application might be redundant, such as an old cluster or DR setup
2. What drives applications to be migrated to AWS?
The remaining four choices for migration -- Rehost, Replatform, Refactor and Repurchase-- are selected according to a wide range of drivers in play in the organization at the time that migrations are being considered.
These drivers are usually uncovered in the Business Case process and provided as inputs to the migration strategy in the form of compelling events, pain points, application availability, skills available to do the migration, and what the future state of the application needs to be post-migration.
Driver #1 - Is there a Compelling Event or Pain Point?
If the organization has a compelling event to evacuate a hosting environment, then a fast-paced Rehosting method can be the only option.
Driver #2 - Is the application available in a Marketplace?
If an application can be Repurchased, then it can be a short-cut to AWS. But if the application is not on AWS Marketplace, then this path may not be possible.
Driver #3 - Do we have the Skills, can we afford a Partner?
Have the skills to manage the application on-premises diminished? Is this a business risk? And if the organization doesn’t have the skills to Replatform or Refactor, and they can’t afford to partner, then their options are limited to Rehost and Repurchase.
Driver #4 - What is the application’s desired Future State?
If the plan is to evolve the application over several years, then Refactor might be the best path. While this is often the initially slowest method, it ultimately delivers the greatest agility and ability to exploit cloud innovation, but it requires deep skills.
3. How do you decide on a migration method per-application?
The four remaining migration methods from the 6Rs are best understood on a spectrum from left-to-right, ordered by the effort, cost and complexity of achieving the migration. It is also true that this left-to-right arrangement also implies, at a high-level at least, the complexity and uniqueness of the application to the organizations.
Fig 1: Cost, Effort, Skills and Time are all vectors that affect your choice of method
Before anyone jumps straight in and starts building an AWS account and shifting bits over the internet, there are some non-optional, essential prerequisites to be covered before deciding on Migration Method.
The organization must have a migration business case
The business case document should be the result of a process to analyse the current state and desired future state. The resulting gap analysis and the remediation plan will provide executive guidance on the direction and velocity of the Migration Program. No matter what size of organization, making a unilateral decision to “go to the cloud” will miss out some important analysis that may result in an organization selecting the wrong migration method.
The organization needs to have a well architected AWS target environment
Well-designed applications can run in poorly designed AWS environments. Deploying and managing a well architected AWS environment is a highly trained and skilled activity. The organization and its partners must be well versed in AWS Well Architected Framework and the AWS Cloud Adoption Framework to ensure the best-deployed target AWS environment.
To decide on a migration method, it’s important to understand the nuances between them, so in a follow-up of this five-blog series, we will explain each of the remaining 4Rs by going into detail for each:
- Defining the method
- Why do organizations choose the method?
- What are the benefits of the method?
- What are the risks of the method?
- How to use the method
- What you need, including costs
4. What are the magic qualities to look for in a migration partner?
A partner who specialises in one migration method is likely to recommend that one method as the primary, sometimes only, migration method. In these cases, it’s important to limit their involvement to the execution of migrations and not the decision-making step.
It is also important to choose a partner that provides staff that understand applications, automation and AWS: not just AWS systems administration. Successful migration of applications requires this complex mix of skills.
The alternative of “rolling your own migration” carries risk inversely proportional to your own staff experience of deploying and operating well architect AWS clouds and performing migrations. Some organizations leverage partners to “get the ball rolling” and transfer skills in an initial phase.
In summary, the critical capabilities of a Migration Partner are:
- Expert in applications, automation and AWS.
- Focused on customer experience and outcomes during migration.
- Capable of multiple migration methods.
- Ability to help operate the migrated applications.
- Ability to evolve migrated applications to further exploit cloud for better business outcomes.
Summary
Migrating applications is complex but can be the right answer depending on the business drivers and goals. Understanding the 6Rs is one thing, using them effectively is another. Choosing a partner like Cloudsoft can make a huge, positive difference to your migration experience and outcomes.
If you want to get the big picture straight away and not wait for the rest of the blog series:
Click here to get the free Practical Guide to Cloud Migration white paper from Cloudsoft right now.
If you need to talk through how to migrate to AWS -- from wherever you are today, even if you are already in AWS but not having a great time -- then contact us any time for a chat.