AWS Migration Considerations Series: Migration Methodologies

By James Bromberger, VP Cloud Computing, Akkodis Australia Choosing your cloud migration strategy involves seven key options, guided by a complex decision tree and extensive insights.

5 minutes

13th of June, 2024

This article is the fourth of a series of blog posts showcasing Akkodis’ experience with AWS Cloud Migrations. 

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

  • Rehost: just use cloud as another data center with individual EC2 VMs 
  • Re-platform: use a combination of EC2 VMs and platform services, such as RDS 
  • Repurchase: ditch 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. 

This was published as the 6 Rs in 2016; with the debut of VMWare on AWS, they got their own R: Relocate.  

The 7 R's of Cloud Migration 

We’ve extended this process to follow a little to account for change over time, but the primary choices remain the same. 


A vanilla VM for VM swap is rarely a cost or capability savings. Rehost does not consider options around managed databases, AutoScale for fault tolerance, or 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 likely need the next optimization phase. 

Rehost: Automatic Rehosting: Image Copying

There is much about magic solutions that can migrate entire VMs from on-premise to on-cloud. Then, you start reading the exceptions and realize it will only work with some pre-work. 

Firstly, all VMs in the cloud must use DHCP for their address assignments. They will generally have new IP addresses in the cloud, particularly if your Virtual Private Cloud will be connected to your existing private networks (via a Virtual Private Network or a dedicated fiber connection).  

Suppose your existing host has a defined static address. In that case, you must set up a DHCP server in your existing environment and create a specific DHCP reservation. Then, update your existing deployed host to use DHCP to get the SAME IP address it previously had, and then image and migrate it. 

Lastly, if you have long-lived hosts with years of configuration drift, you’ll be trying to unpick them for some time.  

Rehost: Manual Rehosting: Reinstall

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


In this scenario, you try to use AutoScale to deploy your EC2 instances, which are deployed from a CloudFormation Template. Platform services that remove undifferentiated heavy lifting, such as RDS for databases, are also leveraged. This is the typical migration for Commercial-off-the-shelf (COTS) products that are classic 2- or 3-tier applications. 


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, and maintenance are Someone Else’s Problem (SEP). However, you then have to evaluate the Service produced for the SaaS offering and determine if its 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 with better cloud-native support. Sometimes, it is as simple as an alternate offering that does not require a USB dongle for license validation or another 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. Of course, AWS takes a cut in running the Marketplace, but the vendor still gets their revenue and can usually support you directly.  

Repurchase: Open-Source Software Stack

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


If you have source code for your solution—such as a bespoke or in-house service—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 to deploy your service in a serverless environment, removing your operational overheads of VM management and maintenance. In Serverless, you only have to configure your desired language runtime version and update your code (and libraries within your codebase).  


Sadly, in the existing worlds, where VMs are not billed by the hour, there 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.  


Sometimes, the 'Retain' decision is based on sweating an existing asset or needing more time to replace/refactor something.  

We have seen that 'Retain' often becomes “retain for now, revisit later.” As time passes, the existing limits, real or perceived, disappear.  


Running VMWare on the cloud is an excellent solution for quickly evacuated data centers, but it will cost you dearly. Most Relocated migrations also re-platform over time after the pressing need to exit a data center has passed.  

The Next Challenge

The next step in the puzzle is to build a roadmap and a schedule. We will cover that in the next post.  

Akkodis has been an AWS Consulting Partner since 2013. Learn more about our AWS Practice and services.