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.
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.
If you want to go straight to the full white paper, get it here.
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?
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.
Why migrate stuff you don’t have to? This is like taking some of your unused belongings to the dump before you move house!
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.
If the organization has a compelling event to evacuate a hosting environment, then a fast-paced Rehosting method can be the only option.
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.
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.
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.
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.
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 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.
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:
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:
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:
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.