AWS Migration Considerations: Migration Methodologies

Welcome to the fifth article in our AWS Migration Considerations Series. You can find the start of the series here.

Determining a migration strategy is often put into one of seven options. There is a large decision tree around this, and a lot of learnings that inform it. We typically reference the 7 R’s approach:

• Rehost: use cloud as another data centre with individual EC2 VMs
• Re-platform: use a combination of EC2 VMs and platform services, such as RDS
• Repurchase: remove the current solution, and use something new, perhaps even a SaaS subscription
• Refactor: if you have source code, update your application to either integrate against cloud service (e.g.: use S3 instead of POSIX local file store), or run from Lambda
• Retire: turn it off!
• Retain: keep it as is for the moment, for one of many reasons
• Relocate: use VMWare on cloud to help evacuate a facility quickly

In 2016, this was published as the 6 R’s, with the debut of VMWare on AWS, they get their own R: Relocate.

Rehost

A vanilla VM for VM swap is rarely a cost or capability savings. Rehost does not take into consideration options around managed databases, AutoScale for fault tolerance, CI/CD for maintenance updates.

Rehost is an option if you are looking for an emergency evacuation but give it a few weeks and you will be looking at a cost that will need the next phase of optimisation.

Rehost: Automatic Rehosting: image copying

Much has been said about magic solutions that can migrate entire VMs from on premise to on cloud. Then you start reading the exceptions and realise it will not work without some pre-work.

Firstly, all VMs in cloud must be using DHCP for their address assignments. They will generally have new IP address in cloud; particularly if your Virtual Private Cloud is going to be connected to your existing private networks (via a Virtual Private Network, or a dedicated fibre connection). If your existing host has a defined static address, then you are going to have to set up a DHCP server in your existing environment, create a specific DHCP reservation, update your existing deployed host to use DHCP for it to get the SAME IP address it previously had, and then be imaged and migrated.

Rehost: Manual rehosting: reinstall

In this situation, you are starting form a base image, but still using the VM as the basis for everything you do. It will work, but for some component (database) there is probably a better option.

Re-platform

In this scenario, you try and use AutoScale for deploying your EC2 instances, deployed form a CloudFormation Template. Platform services that remove undifferentiated heavy lifting, such as RDS for databases, are also leveraged. This is the typical migration for COTs products that are classic 2/3 tier applications.

Repurchase

In this case, we agree the current solution is not worth saving, but the functionality it does is still needed. Your options are then varied:

Repurchase: move to SaaS

I love SaaS, as the operational details, backups, maintenance, are Someone Else’s Problem (SEP). However, you then must evaluate the Service produce for the SaaS offering, and determine if their procedures and policies, security, and activities are up to the standards and requirements you have. If you have a particular regulated workload, then you may find that the SaaS offering does not meet the requirements.

Repurchase: another COTS solution

In this case, there may be a competing option that has better cloud native support. Sometimes it is as simple as an alternate offering that does not require a USB dongle for licence validation – or other license restricting requirements from the vendor. Some COTs solutions within AWS are available via the ASW Marketplace service; the cost of the licensed software is often backed into the AWS billing mechanism.

Repurchase: Open-Source Software Stack

One of our favourites is to find a well maintained, curated and reputable open-source solution that fills the needs of our service. The regret spend is zero, and if it does not meet your needs, you can always then evaluate commercial software options.

Refactor

If you have source code to your solution – such as a bespoke or in-house service – then editing the code to make it use cloud services directly may save you a lot of complexity, risk, and cost. The investment in development time, may be a real benefit to you.

You can also refactor into deploying your service in a Serverless environment, removing your operational overheads of VM management and maintenance. In Serverless, you must configure your desired language runtime version and update your code (and libraries within your codebase).

Retire

Sadly, the exiting worlds, where VMs are not billed by the hour, three is no up-front incentive to make service teams tidy up and remove unused services. Take an image, back it up, and remove the VM.

Retain

Sometimes the retain decision is based around sweating an existing asset, or not being ready to replace/refactor something. What we have seen is that Retain often becomes “retain for now, revisit later”. As time goes on, the existing limits, real or perceived, disappear.

Relocate

Running VMWare on cloud is a great solution to evacuate a data centre very quickly, but it will cost you dearly. Most Relocate migrations also start to re-platform over time, after the pressing need to exit a data centre has passed.

Modis has been an AWS Consulting Partner since 2013. You can learn more about our AWS Practice and services here.