Moving to the cloud is rarely one decision. It is dozens of small ones: which applications go first, which should be changed on the way, and which should not move at all. Getting these right matters more than any single technology choice, because a migration that copies every problem from your server room into AWS, Azure or Google Cloud simply moves the bill somewhere else.
This guide explains the seven common migration strategies, often called the 7 Rs, and a step-by-step plan for using them.
The 7 Rs in plain language
AWS describes seven strategies for each application or workload. The same thinking applies on any cloud.
- Retire. Switch it off. Most organisations find applications nobody uses any more. Retiring them is the cheapest migration there is.
- Retain. Leave it where it is, for now. Some systems are too risky to move, are due to be replaced, or have licensing or latency reasons to stay on-premises.
- Rehost ("lift and shift"). Move the server as it is to a cloud virtual machine. Fast and low risk, but you keep the same design, so you also keep its inefficiencies.
- Relocate. Move a whole platform without changing it, for example VMware workloads moved to a VMware environment in the cloud. Useful when time is short and the platform itself is not the problem.
- Repurchase. Replace the application with a software-as-a-service product, for example moving a self-hosted email or CRM system to a hosted one.
- Replatform. Make a few targeted changes while moving, such as switching a self-managed database to a managed database service, or moving an app into containers. You get real benefits without a rewrite.
- Refactor (or re-architect). Redesign the application to use cloud-native services. This has the biggest long-term payoff and the biggest cost and risk, so save it for systems where the business case is clear.
There is no single right answer. A typical migration uses most of these strategies across different applications.
A step-by-step migration plan
1. Take an inventory
List every application, server, database and dependency: what it does, who owns it, how important it is, and what talks to what. Dependencies are where migrations go wrong. A small reporting server that quietly reads from the main database can break the day you move one without the other.
2. Decide a strategy for each workload
Go through the inventory and assign one of the 7 Rs to each item. A good rule of thumb is to start with retire and retain decisions, because every system you do not move is time and money saved. Then group the rest by risk and effort.
3. Build the landing zone first
Before moving anything, set up the cloud foundations: account structure, networking, identity and access, logging, security baselines, backup and cost controls. This is often called a landing zone. Doing this first means every workload lands in a secure, consistent environment instead of being fixed up later. We build these with infrastructure as code so they can be reviewed and repeated.
4. Plan waves, starting small
Move workloads in waves. Start with something low risk that still teaches you something real, such as an internal tool or a non-critical website. Each wave should improve the playbook for the next one.
5. Test, cut over and keep a rollback path
For each workload, test it in the cloud before switching users over. Plan the cutover for a quiet period, agree success checks in advance, and keep a rollback plan ready so you can switch back if something unexpected happens. Data migration deserves particular care: decide how you will keep data in sync between old and new until cutover.
6. Optimise after you land
Once a workload is running in the cloud, review it. Right-size servers based on real usage, turn on autoscaling where it helps, move suitable storage to cheaper tiers, and set budgets and alerts. Many of the savings from cloud come from this step, not from the move itself.
7. Decommission the old environment
Switch off and remove the old servers once you are confident. Paying for two environments for longer than planned is one of the most common hidden costs of a migration.
Common mistakes to avoid
- Moving everything as is and expecting lower costs. Lift and shift is a valid first step, but plan the optimisation that follows.
- Skipping the landing zone, then retrofitting security and networking under pressure.
- Ignoring licensing. Some software licences change cost or terms when moved to the cloud. Check before you move.
- No owner for each application. Someone needs to sign off that it works after the move.
- No rollback plan. Hope is not a cutover strategy.
Where to start
If you are considering a move to the cloud, or you have already moved and the bill is higher than expected, an hour spent on the inventory and strategy is the best investment you can make. If you would like help with the assessment, the landing zone or the migration itself, book a free consultation and we will look at your situation with you.