Cloud migration strategies: the 7 Rs and planning migration waves
In short: Moving to the cloud is a portfolio decision, not one big move. Each application gets a strategy from the 7 Rs, from retiring it to fully re-architecting it. Work is grouped into waves after a discovery phase, on top of a secure landing zone, with security checks before every cut-over.
Start with discovery
You cannot plan a migration without knowing what you have. Discovery builds an inventory of servers, applications, databases, dependencies, owners and licences. Tools can scan networks and record which servers talk to which, which reveals hidden dependencies such as a reporting job that reads a database every night. Classify the data each application holds, because that decides where it may go and what controls it needs.
The 7 Rs
| Strategy | What happens | Example |
|---|---|---|
| Retire | Turn it off | An old intranet nobody has used in a year |
| Retain | Leave on-premises for now | A system tied to specialist hardware |
| Rehost | Move VMs as they are | A file server copied to cloud VMs with a migration tool |
| Relocate | Move a whole hypervisor environment | VMware workloads moved to a provider's VMware service |
| Repurchase | Switch to a SaaS product | An on-premises CRM replaced by a SaaS CRM |
| Replatform | Small changes to use managed services | Self-managed SQL Server moved to a managed database |
| Refactor | Re-architect for cloud-native design | A monolith split into containers and serverless functions |
Older models list six Rs without relocate. In practice, rehost is fastest, refactor brings the most long-term benefit but costs most effort, and replatform is often the sensible middle ground.
Planning waves
- Group applications that depend on each other into the same wave, so you do not split chatty systems across a slow link.
- Start with a low-risk pilot wave to prove tools, processes and the landing zone.
- Agree a test plan and rollback plan for each application.
- Schedule cut-overs in quiet periods and confirm business sign-off.
- After each wave, record lessons learned and update the plan.
Hybrid connectivity is needed throughout, because migrated systems still talk to those not yet moved. See hybrid connectivity.
Security during migration
- Build the secure foundation first: identity, logging, network and guardrails.
- Do not lift and shift bad habits; fix open firewall rules, shared admin accounts and unsupported operating systems on the way.
- Encrypt data in transit during replication, and check where interim copies are stored.
- Review each workload's new attack surface: anything that becomes internet-facing needs a design review.
- Decommission old servers and wipe data securely after cut-over, so forgotten copies do not linger.
- Update the incident response plan and asset register for the new environment.
Tip: rehosting without any optimisation often costs more than expected. Plan a rightsizing step after each wave, as covered in cloud costs and FinOps.
Practice
A company replaces its on-premises email server with Microsoft 365. Which R is this?
Why group dependent applications into the same wave?
Name one security risk of a pure lift-and-shift.
Key takeaways
- Discovery and dependency mapping come before any move.
- The 7 Rs: retire, retain, rehost, relocate, repurchase, replatform, refactor.
- Migrate in waves of dependent applications, starting with a pilot.
- Build the secure landing zone first and fix bad habits on the way.
- Decommission old systems securely and optimise after each wave.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.