Short answer
The 7 Rs are the seven ways to move each application to the cloud: retire, retain, rehost, relocate, repurchase, replatform and refactor. Do not pick one strategy for the whole estate. Decide per application based on its business value and technical condition, retire what you can, move most applications with rehost or replatform, and refactor only what differentiates the business.
- 7 - migration strategies to choose from for every application
- 1 - decision per application, not one strategy for the estate
- 2 - that cost the least: retire and retain
- 1 - that changes the most: refactor
A cloud migration strategy is a decision, made for each application, about how it will move to the cloud or whether it should move at all. AWS groups the options into seven strategies, known as the 7 Rs. Using them turns a vague “move to the cloud” programme into a portfolio of clear, costed decisions that leaders can govern.
The 7 Rs at a glance
StrategyWhat it meansEffortTypical useRetireSwitch the application offLowestDuplicate, unused or low-value systemsRetainKeep it where it is for nowLowRecently upgraded, regulated or not worth moving yetRehostLift and shift without changesLowFast data-centre exitRelocateMove at hypervisor level, for example VMware to its cloud equivalentLowLarge virtualised estates on a deadlineRepurchaseReplace with a different product, usually SaaSMediumCommodity systems such as CRM, HR or emailReplatformMove with targeted optimisation, such as a managed databaseMediumApps worth keeping that gain from managed servicesRefactorRe-architect to use cloud-native featuresHighestDifferentiating systems that need scale or speed
How to choose a strategy for each application
Score each application on two axes: how much business value it creates, and how healthy it is technically. High-value, healthy systems are candidates for replatforming or, if they differentiate you, refactoring. Low-value systems should be retired or repurchased. Fragile but important systems deserve an honest decision about whether to modernise or replace them, which we cover in our modernise or replace decision framework.
- Business value: revenue, customers or critical operations that depend on it.
- Technical condition: supportability, security posture and how often it changes.
- Risk and compliance: data residency, regulation and integration dependencies.
- Timing: contract renewals, hardware end of life and data-centre exit dates.
Common mistakes that make migrations fail
- One strategy for everything. Refactoring the whole estate takes years; rehosting everything moves your problems and costs to a new bill.
- Skipping retirement. Many portfolios contain systems nobody uses. Switching them off is the cheapest migration there is.
- Treating migration as the finish line. Moving workloads without changing operating practices creates little advantage, as we explain in cloud maturity.
- Ignoring cost after the move. Lifted-and-shifted servers sized for on-premises peaks often cost more in the cloud. Right-size within weeks.
- Migrating dependencies apart. Applications that talk constantly should move in the same wave to avoid latency and data-transfer costs.
A migration plan leaders can govern
Cost control should start on day one, not after the bill arrives. Our FinOps playbook covers tagging, right-sizing and commitments for a freshly migrated estate.
Questions to ask before approving a migration
Is this migration plan ready?
- Has every application been assigned one of the 7 Rs, with a written reason?
- Which applications are we retiring, and how much does that save?
- How are waves grouped around dependencies, and which goes first?
- What is the plan to optimise cost and operations after each wave?
- How will we measure success beyond “percentage migrated”?
Cloud & DevOps
Planning a cloud migration?
We inventory your portfolio, assign a strategy to every application, plan the waves and landing zone, and keep costs under control from the first move.
Sources
- AWS Prescriptive Guidance: migration strategies (Amazon Web Services)
Originally published at phpscientist.com.
Top comments (0)