The 7 Rs of Cloud Migration: Choosing the Right Strategy Per Application

The biggest mistake we see in cloud migrations isn't a technical one — it's treating "move to the cloud" as a single strategy applied to every application. Different workloads have different constraints, and the right move for your CRM is rarely the right move for your legacy batch-processing job. The 7 Rs framework gives you a decision model per application instead of a single answer for everything.

1. Rehost ("lift and shift")

Move the application as-is onto cloud infrastructure — same architecture, new host. Fastest path to the cloud, useful when you need to exit a data center quickly or the app isn't worth re-architecting yet. The tradeoff: you don't get cloud-native benefits like auto-scaling until you revisit it later.

2. Replatform ("lift, tinker and shift")

Make targeted changes during the move — swap a self-managed database for a managed service, containerize an app without rewriting it. Most of our migrations land here: enough improvement to reduce ops burden, without a full rebuild.

3. Refactor / re-architect

Rebuild the application to be cloud-native — microservices, serverless, managed queues. Highest effort, highest long-term payoff. Worth it for core, frequently-changing products; rarely worth it for a stable internal tool.

4. Repurchase

Replace the application with a SaaS equivalent instead of migrating it at all. If you're running a self-hosted ticketing system or CMS, this is often cheaper than any migration.

5. Retire

Some applications, when you actually map dependencies, turn out to be unused or redundant. Retiring them is free — it's the fastest win in any migration assessment, and the reason discovery comes before planning.

6. Retain

Not everything needs to move. Compliance constraints, recent investment, or a pending replacement can all be valid reasons to leave a workload where it is — for now.

7. Relocate

Move infrastructure (often VMware-based) to the cloud without changing the underlying architecture — a middle ground between rehost and staying on-prem, common in large enterprise estates.

How we apply this

Every migration we scope starts with a discovery phase: inventory applications, map dependencies, and assign each one a strategy from the list above. That's what turns "we want to move to AWS/Azure/GCP" into an actual plan with a realistic timeline and budget — which is also why we offer this as a free initial assessmentrather than charging upfront for it.