Effective cloud migration strategies for your business: the 7 Rs and how to choose
Consultant Manager
Six Sigma White Belt (AIGPE), Internal Auditor - Integrated Management System (ISO), Gold Medalist MBA, 8+ years in cloud and cybersecurity content
An effective cloud migration strategy decides, workload by workload, whether to retire, retain, rehost, relocate, repurchase, replatform or refactor it: the "7 Rs". Most businesses mix them, rehosting or replatforming the bulk quickly and refactoring only the few applications where cloud-native design pays back. The choice follows business value, risk, deadline and skills.
Key takeaways
- Choose a strategy per application, not one for the whole estate. A portfolio usually ends up with several of the 7 Rs.
- Retire and retain first: removing or parking workloads that should not move cuts the scope before any work starts.
- Rehost and replatform are fastest and lowest risk; AWS guidance advises against refactoring as the default in large migrations.
- Run a pilot wave on low-risk systems, then migrate in waves grouped by dependency, with a tested rollback plan for each cutover.
- Budget for running costs after the move, training and a period of dual running. These are the costs most often missed.
What is a migration strategy?
A migration strategy is the approach you take to move one workload (an application with its data and infrastructure) to a new environment, usually the cloud. AWS defines it as "the approach used to migrate a workload into the AWS Cloud".
The overall migration plan is the sum of those decisions, plus sequencing, people, budget and risk controls. Getting the per-workload choice right matters most, because it sets cost, duration and what you gain afterwards.
The 7 Rs of cloud migration
The AWS Prescriptive Guidance lists seven strategies. Microsoft's Cloud Adoption Framework uses a similar set (retire, retain, rehost, replatform, refactor, rearchitect, rebuild, replace).
| Strategy | What it means | Good fit | Main trade-off |
|---|---|---|---|
| Retire | Switch the application off | Duplicate or low-value systems | Needs data archiving and owner sign-off |
| Retain | Keep it where it is for now | Recently upgraded, hard-to-move or soon-to-be-replaced systems | You keep running the old platform |
| Rehost (lift and shift) | Move servers as they are to cloud VMs | Stable applications, deadline-driven exits from a data centre | Little cloud benefit until optimised later |
| Relocate | Move a whole platform, such as VMware, to the same platform in the cloud | Large VMware estates that must move fast | Keeps hypervisor licences and the old operating model |
| Repurchase | Replace with SaaS | CRM, HR, email, ITSM and other commodity systems | Data migration, process change, vendor lock-in |
| Replatform | Move with targeted changes, such as a managed database or containers | Applications that benefit from managed services without a rewrite | Some testing and code or configuration change |
| Refactor / re-architect | Redesign for cloud-native services | Core, differentiating applications that need scale or speed of change | Highest cost, time and skills requirement |
AWS notes that common strategies for large migrations are rehost, replatform, relocate and retire, and that refactor is not recommended for large migrations because of the effort involved. Refactor selectively, after the move or for a handful of applications that justify it. For a deeper look at each R, see our 7 Rs explainer.
How do you choose the right strategy for each workload?
Score each application against a few questions. The answers usually point to one or two Rs.
- Does the business still need it? If not, retire it. If it will be replaced within a year or two, retain or repurchase.
- Is there a hard deadline? A data centre contract end or hardware end-of-life favours rehost or relocate now, with optimisation later.
- Is a SaaS product good enough? For commodity functions, repurchase usually beats running your own software.
- Would managed services remove real work? Moving a self-managed database to a managed service, for example, removes patching and backups. That points to replatform.
- Is it a core, changing application? If release speed or scale limits the business, refactor may pay back. Check that you have the skills.
- What are the constraints? Licences tied to hardware, data residency, latency to factories or other systems, and regulatory rules can rule options in or out.
What can you learn from well-known migrations?
Two public examples show that the right answer depends on the workload.
Netflix refactored. According to Netflix, its move to AWS began in August 2008 after a database corruption stopped DVD shipments for three days. It finished in early January 2016, after seven years. Netflix chose the cloud-native approach, rebuilding almost all of its technology as micro-services instead of moving systems unchanged. That choice explains much of the seven years.
Dropbox moved part of its storage back. Dropbox had always run a hybrid setup, with file content on Amazon S3 and metadata in its own data centres. At its scale it built its own storage system, Magic Pocket, and by October 2015 served over 90% of user data from in-house infrastructure. For a very large, steady storage workload, retaining or repatriating made sense. For most companies it does not, but the point holds: decide per workload.
A step-by-step migration plan
- Assess: inventory applications, servers and data, map dependencies, collect utilisation and costs, and record owners. A structured cloud migration assessment gives you this baseline.
- Decide: assign one of the 7 Rs to each workload and build the business case, including running costs after the move.
- Prepare the landing zone: accounts or subscriptions, networking, identity, logging, security baselines and cost tags before the first workload arrives.
- Pilot: migrate a few low-risk applications end to end to test tools, runbooks and the team.
- Migrate in waves: group applications that depend on each other, schedule cutovers in agreed windows and keep a rollback plan for each one.
- Optimise and operate: right-size, buy commitments for steady load, decommission the old environment and hand over to day-to-day operations.
What should you budget for?
Migration cost has three parts, and the third is often forgotten.
- One-off migration cost: assessment, tooling, engineering time, testing and partner fees.
- Dual running: for weeks or months you pay for both the old and new environments.
- Run cost after the move: compute, storage, data transfer, licences, support and operations. Without right-sizing and commitments, rehosted workloads can cost more than the business case assumed.
Add training, process changes and the internal time of application owners. A business case that compares only server prices will be wrong.
How do you keep data secure and compliant during migration?
Treat the migration as a change to how you process data, and plan controls before the first copy.
- Encrypt data in transit (TLS, VPN or private links) and at rest in the target, with keys you control.
- Use temporary, least-privilege credentials for migration tools and remove them after cutover.
- Keep personal data in the right Region (for example within the EU or India) and update your GDPR records of processing.
- If you fall under NIS2, include the migration in your risk assessment and incident procedures.
- Validate data after each move with counts, checksums and application tests before the source is switched off.
A replatform example: Branäsgruppen
Swedish ski resort group Branäsgruppen ran its websites and booking systems on VMware ESXi on premises. Scaling for the December to April season was manual, and deployments meant taking the environment down.
The Branäsgruppen case study describes a replatform approach: the application logic was kept, while the VMware-hosted servers and databases were swapped for AWS-managed equivalents with auto-scaling and multi-AZ deployment. The case reports a 40% improvement in average page responsiveness, a 40% reduction in total cost of ownership, 99.9%+ application uptime, and a mean time of two days to identify and resolve critical issues.
How Opsio helps
Opsio is an AWS Advanced Tier Services Partner with the AWS Migration Competency, with offices in Karlstad, Sweden and Bangalore, India. We run assessments, assign strategies per workload, build landing zones and carry out AWS migrations and replatform projects, then operate the result. See our cloud migration services for how a project runs.
Frequently asked questions
What are the main types of cloud migration strategy?
The 7 Rs: retire, retain, rehost, relocate, repurchase, replatform and refactor. The first two reduce scope, the middle ones move workloads with little change, and refactor redesigns applications for cloud-native services.
Which migration strategy is fastest?
Rehost (lift and shift) and relocate are the fastest, because applications move without code changes. They suit deadline-driven moves. Plan an optimisation phase afterwards, or the cost and operational benefits stay small.
What is the difference between rehosting and replatforming?
Rehosting moves servers as they are to cloud virtual machines. Replatforming makes targeted changes on the way, such as moving a self-managed database to a managed database service, without rewriting the application.
How long does a cloud migration take?
A single application can move in days or weeks. A full data centre exit typically runs for months, depending on the number of applications, dependencies and how much refactoring you choose. Netflix's fully re-architected move took seven years, which is an extreme case.
Should every application move to the cloud?
No. Some should be retired, some replaced by SaaS and some retained on premises for licensing, latency or cost reasons. A good plan says explicitly what does not move.
Related reading
Related Articles
About the Author
Consultant Manager
Debolina works at the intersection of IT operations, quality management, and compliance at Opsio. She focuses on practical, data-driven insights around operational efficiency, governance, and continuous improvement — helping organisations streamline complex systems while maintaining standards.
Editorial standards: This article was written by a certified practitioner, named in the byline above. We revise it when the technology or regulation it covers changes; the dates above show the latest update. Opsio maintains editorial independence — we recommend solutions on technical merit, not commercial relationships.
