The 7 Rs of cloud migration: how to choose for each application

The 7 Rs of cloud migration are seven ways to handle an application when you move to the cloud: retire, retain, rehost, relocate, repurchase, replatform and refactor. You pick one for each application, based on its business value, its technical condition and your deadline. Most portfolios end up with a mix, and the best place to start is with the options that take work out of the program.

What the 7 Rs of cloud migration are

The list comes from Amazon Web Services. Its prescriptive guidance for large migrations defines seven migration strategies, and each one describes how much of the application changes on the way to the cloud.

Other vendors name the options differently. Microsoft’s Cloud Adoption Framework, in its guide to selecting cloud migration strategies, lists eight: retire, rehost, replatform, refactor, rearchitect, replace, rebuild and retain. It splits the refactor idea into three levels of change, calls repurchase “replace”, and has no separate relocate option. The decisions are the same. Pick one vocabulary and use it everywhere, so a steering group is never arguing about labels.

Start with the applications you do not have to move

Every application you retire is one you never have to migrate, test or pay to run. So check retirement first. AWS suggests looking at utilization data from your discovery tool. It describes “zombie” applications as those with average CPU and memory use below 5 percent, and “idle” applications as those between 5 and 20 percent over 90 days. An application with no inbound connections for 90 days is another candidate.

Usage data starts the conversation, and the business owner finishes it. Some systems are quiet for eleven months and essential at year end. Ask the owner before you switch anything off, and agree what happens to the data.

Retain comes next. Good reasons to leave an application alone include data residency requirements, a recent upgrade you have not yet paid back, dependence on hardware with no cloud equivalent, or a vendor that is about to release a hosted version. AWS also notes that mainframe and mid-range applications need careful assessment before any move. A retain decision is only safe when it has an owner and a date to look again.

How to choose a strategy for each application

Work through the options in a fixed order. The early questions are cheap to answer and remove the most effort.

1. Build the inventory. For each application record the business owner, the users, the dependencies, the data it holds and what it costs to run today.
2. Can it be retired? If usage is negligible or another system covers the function, plan the shutdown and the data archive.
3. Is there a real reason to retain it? If yes, write the reason down and set a review date.
4. Could a product replace it? For functions such as HR, ticketing or expenses, repurchase often beats moving custom code. A build vs buy framework helps with this call.
5. For what is left, default to the lighter moves. Choose rehost, relocate or replatform according to your deadline and how much operations work you want to hand to managed services.
6. Reserve refactor for the few. Use it where the architecture itself blocks the business and the return justifies the cost.

Give every application exactly one strategy and record why. The reason is what people will question later, and it is what lets you revisit the decision when circumstances change.

Why refactoring usually waits until after the move

AWS is direct on this point. It does not recommend refactoring during a large migration, because you would be modernizing the application and moving it at the same time. It calls refactor the most complex and costly of the strategies and recommends that you rehost, relocate or replatform first, then modernize once the migration is complete. Applications are also easier to rework when they already run in the cloud next to the services you want to use.

There is a counterweight. Microsoft’s guidance warns against rehosting problematic workloads, because a like-for-like move does not fix performance, reliability or architecture issues and carries technical debt forward. It also points out a benefit of rehosting: teams gain early experience with cloud operations, governance and cost management.

Put together, the rule is simple. If the application is healthy, move it and modernize later. If the application is the problem, modernize it as part of the move, but run that work as a separate track so it does not hold up the waves behind it.

What a migration plan should contain

Once each application has a strategy, the plan turns those decisions into work. A plan you can act on includes:

• A strategy, a reason and a named owner for every application
• Waves that group applications by dependency, so nothing moves without the systems it talks to
• A landing zone with identity, networking, logging and guardrails in place before the first wave
• A cost baseline for each application, so savings can be shown later
• Test and rollback steps for each cutover, timed around the business calendar
• A decommission date for the old servers, so you do not pay for two environments longer than planned

The last two items are where budgets most often slip. Cloud cost control is easier to build in from the first wave than to add afterward, and the same discipline now extends to AI workloads, as the guide to FinOps for AI explains.

How YLinkTech helps

Our Cloud & Modernization practice starts with an application portfolio assessment and dependency map, then recommends a strategy for each application with the reasoning behind it. From there we plan and run the move in waves through cloud strategy and migration, and take on the harder rebuilds through application modernization. If you are sorting a portfolio and want a second opinion on the plan, get in touch.

Frequently asked questions

Sources

• AWS Prescriptive Guidance: About the migration strategies
• Microsoft Cloud Adoption Framework: Select your cloud migration strategies

This article is general information, not professional advice. See our Disclaimer.