Moving to the cloud is rarely a single decision. A typical business runs a mix of applications: a customer-facing website, an accounting package, a few internal tools, perhaps an old system that nobody quite dares to touch. Each one deserves its own cloud migration strategy. The most widely used way to think about those choices is the "6 R's", a framework popularised by Gartner and later adopted and extended by AWS. This article explains each option in plain language, with the trade-offs that actually matter when you pick one.
Why you need a cloud migration strategy per application
Treating every workload the same is the most common cause of disappointing migrations. Lift an old monolithic application into the cloud without changes and it may cost more than it did on your own hardware. Rewrite a stable, rarely used tool from scratch and you spend months of developer time for little benefit. The 6 R's give you a vocabulary for deciding, application by application, how much change is worth paying for.
Before choosing, build a simple inventory. For each application, write down who uses it, what it depends on (databases, file shares, other services), how critical it is, and whether it is still actively developed. Those four facts usually point clearly to one of the options below.
The 6 R's at a glance
| Strategy | What changes | Effort | Typical fit |
|---|---|---|---|
| Rehost | Nothing in the app; it moves to cloud virtual machines | Low | Deadline-driven moves, data centre exits |
| Replatform | Small changes to use managed services | Low to medium | Apps that benefit from a managed database or runtime |
| Repurchase | The app is replaced by a SaaS product | Medium (data migration, training) | Email, CRM, HR, ticketing |
| Refactor | The app is redesigned for cloud-native services | High | Core products that need to scale or change quickly |
| Retire | The app is switched off | Low | Duplicated or unused systems |
| Retain | The app stays where it is, for now | None | Recently upgraded, regulated or hard-to-move systems |
1. Rehost ("lift and shift")
Rehosting copies a server, more or less as-is, onto a cloud virtual machine. The operating system, application and configuration stay the same. Tools such as AWS Application Migration Service or Azure Migrate can replicate disks continuously and let you cut over with a short outage.
Rehosting is fast and low risk, which is why it is common when a data centre lease or hardware support contract is ending. The downside is that you carry your old inefficiencies with you: servers sized for peak load run at that size all month, and you still patch the operating system yourself. Many teams rehost first and optimise later, which is reasonable as long as "later" is actually scheduled.
2. Replatform ("lift, tinker and shift")
Replatforming keeps the application's core code but swaps a few components for managed services. The classic example is moving a self-managed MySQL server to a managed database such as Amazon RDS or Azure Database for MySQL, so backups, patching and failover are handled by the provider. Another is moving a PHP or Java application onto a managed runtime instead of a hand-built VM.
This option often gives the best return for the effort. You remove routine operational work without rewriting business logic. The main risk is version or feature differences: a managed database may not allow certain plugins or superuser access, so test before committing.
3. Repurchase ("drop and shop")
Some applications should not be migrated at all; they should be replaced by a software-as-a-service product. Self-hosted email servers are the obvious case, but the same logic applies to CRM, helpdesk and HR systems. The work here is in exporting data, mapping fields, retraining staff and adjusting processes, not in servers.
Check contract terms, data export options and where the provider stores data before signing. Switching away from a SaaS product later can be harder than leaving your own server.
4. Refactor or re-architect
Refactoring means changing how the application is built so it can use cloud-native features: containers, serverless functions, managed queues, object storage, auto-scaling. It is the most expensive option and the one with the biggest potential pay-off, but only for applications that genuinely need it, such as a product with unpredictable traffic or a platform the business is actively growing.
A practical approach is incremental refactoring, sometimes called the "strangler" pattern: put the existing application behind a proxy or load balancer, then move one feature at a time into new services until the old code can be removed. This avoids a risky big-bang rewrite.
5. Retire
Inventories routinely uncover servers that nobody uses: an old intranet, a test environment left running, a reporting tool replaced years ago. Retiring them is the cheapest migration of all. Before switching anything off, check access logs for real usage, take a final backup, confirm any data retention obligations, and announce a shutdown date so hidden users can speak up.
6. Retain
Retaining means deliberately leaving an application where it is. Valid reasons include hardware bought recently, software licences tied to physical machines, latency-sensitive equipment on a factory floor, or regulations that require data to stay on premises. Retain is a legitimate choice, not a failure; just revisit it at a set interval rather than forgetting about it.
What about the seventh R?
AWS's current guidance adds Relocate, which moves whole virtualised environments (for example VMware clusters) to a cloud-hosted equivalent without converting each VM. It matters mostly to organisations with large existing virtualisation estates. Smaller businesses can usually treat it as a variant of rehosting. The AWS Prescriptive Guidance on migration strategies describes all seven in detail.
How to choose: a simple decision path
- Is anyone using it? If not, retire it.
- Is there a good SaaS replacement that fits your process? If yes, consider repurchasing.
- Is there a hard reason it cannot move now? If yes, retain it and set a review date.
- Is it a core product that must scale or change often? If yes, plan a refactor, possibly after an initial rehost.
- Otherwise, replatform where a managed service clearly removes work, and rehost the rest.
Write the chosen strategy, the owner and the target date next to each item in your inventory. That list becomes your migration plan and makes progress easy to track. If you want an outside view on the trade-offs, our cloud solutions and software consulting pages describe how we approach assessments.
Common mistakes to avoid
- Forgetting dependencies. Moving an application but leaving its database on premises can add latency to every query. Map connections first.
- Copying peak sizing. Right-size virtual machines after a few weeks of monitoring instead of matching old hardware.
- Skipping a rollback plan. Every cutover should have a documented way back, tested in advance.
- Ignoring DNS timing. Lower DNS TTLs before cutover so traffic moves to the new environment quickly.
Key takeaways
- A cloud migration strategy is chosen per application, not once for the whole company.
- Rehost is fastest, replatform often gives the best value, refactor suits only applications that need cloud-native scale.
- Retire and retain are valid outcomes and often save the most money and risk.
- Start with an inventory of usage, dependencies and criticality; the right "R" usually follows.