We believe empowering engineers drives innovation.

The 6 R's of Migrating to the Cloud

By Nick Kitmitto
August 3, 2022


Migrations are one of the primary focuses for a company when they’ve decided to move to the cloud. Not only is it a shift in who is hosting your data and applications, but is also a phenomenal opportunity to modernize, optimize, and fundamentally improve the technology stacks that support business processes. This blog post details some of the benefits of moving to the cloud along with some tips to make the move as cost-effective as possible.

Starting The Process

When starting a migration, it’s imperative to start your application portfolio assessment and application rationalization effort. Start by creating a live document/spreadsheet and grant your team edit access, then gather the team around (order some lunch, everyone likes food!) and identify every single application you have today. This process likely won’t finish in your first meeting, and it could even take a few weeks or even months. The first meeting is the kick off, where you have teams add their applications to the live document. As you go through your day and are managing the infrastructure, you can all quickly add each component, tool, application, or server to the list.

Let’s talk about the actual migration and strategy itself. With most migrations, I’ve seen companies choosing from the 6 R’s: Refactor, Replatform, Rehost, Retire, Repurchase, and Retain.

The 6 R’s Explained

Refactor: Refactoring the application to potentially using serverless, maybe introducing microservices, swapping to containers, or otherwise a new architecture for that application

Replatform: Replatforming the application to use different technology; whether that’s going to AWS RDS for the database, S3 for static storage, or changing your message bus from using Apache MQ to RabbitMQ (or, check out Amazon MQ)

Rehost: Rehosting aka “lift and shift.” We’re copy/pasting our server from on-prem (or the current provider) to the cloud. Installing an agent (AWS provides CloudEndure for this), and swapping over the DNS or IP’s when you’re ready to move it to the cloud

Retire: Retiring an application that’s no longer needed. Maybe it’s an old application that stuck around over the years, or a tool that was used to support another application that was otherwise Refactored

Repurchase: You have a tool that you pay the licensing for, but need a more cloud-centric tool. Identifying which tools are not cloud-centric and identifying new tools to purchase instead

Retain: Retaining an application. This could be an application that’s on the path to deprecation, or you can revisit it later in another iteration to determine what happens As you’ve probably read, there are many different blog posts on the Internet about a company’s endeavor to the cloud. Some say it is much more cost effective than on-prem; others say it was much more expensive and went back to on-prem. There’s a good answer as to why their experiences were so different, and it all comes down to this decision: “Which R do we apply to each application?”

The Actual Work

You likely don’t want to just copy/paste your problems into the cloud – as your bill will reflect it. Take the opportunity to assign the right number of resources to your servers. Upon doing some research, you might discover a few of your servers potentially only need half, or even a quarter of what is dedicated to it. See if you can get to that ~70% resource utilization on average for your servers as they migrate to the cloud.

After you have the list of applications in your environment:

  1. Start categorizing them so you know the importance of each application.
    1. How you categorize is up to you. For example, it can be the tier of application (tier 0, tier 1, etc), or it can be the number of users that use it each day.
  2. As a team, start determining which of the 6 R’s can apply to each application. This is where you find a great opportunity! It’s not often that companies can get a holistic view of their environment and the opportunity to re-architect it.
  3. Review the document as a team and make sure the majority is on board with the process for each application. Encourage and discuss disagreements. You never know what a team member knows without discussing it.
  4. Start migrating the applications according to the schedule agreed upon by your teams. If an application is set for re-architect, have a technical owner for that application propose a proof-of-concept or architecture diagram for how it’ll operate in the cloud. As always, don’t forget to loop business stakeholders in with the plans! They don’t need the nitty gritty, but customer support should have an idea that something is happening in the event calls come in.

Some Examples

Examples Rehost:

Examples of Replatforming:

Example of Re-architecting:

Examples of Re-Purchase:

Examples of Retain:

Example of Retire:

What about that service an engineer wrote years ago that’s still in the environment, but no one really knows what it does (you know, the one written in Perl…)? What do you do with that? Now might be a good time to investigate retiring it. Dig into what it does, where it’s running, why it exists, and see if you can retire it. No need to bring unnecessary applications or tools over to the cloud. Remember, we’re trying to reduce our operational load, and trying to not copy our bad habits or misconfigurations into the cloud, which in turn also reduces our cloud bill.


You can see how this part of the process is make or break for the migration in terms of cost. You can really focus on each individual application and improve its efficiency, availability, and performance. This is the perfect opportunity to look at what each server is doing and whether you can refactor it or not. Refactoring potentially has the biggest cost savings (CapEx and OpEx) in the long-run. But if you don’t have the time to refactor, replatforming would be the next best thing. Keeping the AWS bill lower also helps keep your AWS support bill.

If you choose to rehost, replatform, or retain, be sure to right-size your resources. Use your system monitoring tools to look at the historical view for metrics to identify what they should be in the cloud. Some of these metrics can include:

Don’t Forget!

Revisit on-premise applications regularly to determine whether they can move to the cloud. Cloud providers release more new products and features in one day than most businesses release in a year. Therefore, it’s important to revisit applications left on-prem to see if there’s a new feature or service that can help with the migration, or replace the function of that server entirely to remove the management overhead. Don’t forget about the SaaS providers out there as well. They may have just the solution you need!

You’re moving to the cloud. Embrace it. Re-architect, use autoscaling, serverless, reduce your operational load so your team can focus on important things like improving applications rather than managing them. And as always, if you need assistance with your migration, or cloud related tasks, the Rearc engineers and architects are here to help!

References: 6 Strategies for Migrating Applications to the Cloud