The 6 R's of Migrating to the Cloud

Introduction

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:

• An application that has 2TB of disk space due to an old logging problem is now in the cloud with 2TB. In reality, it’s a web server that only needs 20GB (remember, you pay for what you use in the cloud!)
• Another application that has a cluster of 10 hosts, each with 128GB of RAM. This was caused by that one time the application had a memory leak. Someone increased it at 2 AM, but then no one went back and reduced the RAM after the fix was applied. That’s now in the cloud using double the necessary RAM!

Examples of Replatforming:

• Moving your message bus from RabbitMQ to Kafka (or AWS MQ!)
• Moving your database from your servers to AWS RDS (many benefits, but you should evaluate the features that are and are not available on RDS for your database engine)
• Static content moved to S3 and CloudFront to reduce storage costs and improve load times for end-users around the world

Example of Re-architecting:

• You have a web service that is React-based and doesn’t need server processing. This site can be moved to S3 using Static Website Hosting.
• You have a 3-tier application that sits on one server. You can move the website to S3 if it doesn’t do any server-side processing. The database can go to a NoSQL (DynamoDB) database. The application layer can move to Lambda and you only pay for the Lambda executions rather than keeping a server up and running.

Examples of Re-Purchase:

• You have a monitoring tool today that isn’t cloud-native. It doesn’t deal well with hosts appearing and disappearing. It thinks a server that disappeared is offline and generates an alert. But in reality, the auto-scaling group scaled down due to inactivity and it was intentional for that host to disappear.
• Your email system takes a lot of administration time, storage, hardware, and you determine it’s time to find a SaaS solution.

Examples of Retain:

• You’re currently using a system that supports a small portion of your application. That application might be on a path to deprecation. So rather than investing the time into that system, you retain the system and revisit it later. Maybe this turns out to be a lift-and-shift, maybe it turns out to be a re-purchase, or maybe it’s also deprecated and no change is necessary.
• The application isn’t prioritized to move to the cloud.
  • If this is the case, be sure to revisit that application in the future!

Example of Retire:

• Your team found a system that’s hanging around that is no longer needed. After determining it is in fact no longer needed, that system can be retired. Remember, you pay for what you use in the cloud. So any system that isn’t in use and can safely be retired, will keep the cloud bill more manageable.

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.

Overall

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:

• RAM
• CPU
• Disk IOPS

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