Cloud Migration 6 Rs Framework

The six Rs give a shared vocabulary for per-workload decisions. They range from minimal change to full redesign, and each has a different cost, time, and benefit profile.

Many organizations add a seventh option in practice, relocate, for moving virtualized workloads wholesale, but the six categories suffice for most portfolios. What matters is that each choice is explicit, owned, and tied to a business reason such as a contract expiry or compliance deadline.

How it works

Rehost moves servers as-is to virtual machines. Replatform makes small optimizations, such as a managed database, without changing architecture. Repurchase replaces the application with SaaS. Refactor redesigns for cloud-native services. Retire decommissions what nobody needs. Retain leaves the workload in place for now, due to latency, regulation, or poor return. A scoring model picks the R and a dependency graph defines the order.

Implementation steps

1. Discover assets and dependencies using agents or network flow data.
2. Interview owners to capture business criticality, user count, and roadmap.
3. Score each application on value, complexity, risk, and compliance.
4. Assign an R, and identify retire candidates early to cut scope.
5. Build the landing zone: accounts, network, identity, guardrails, and logging.
6. Run a pilot wave of low-risk workloads to validate tooling and process.
7. Execute waves with cutover plans, rollback criteria, and hypercare periods.
8. After migration, optimize cost and revisit retained and rehosted workloads.

Plan the people side alongside the technical side: train operations staff on cloud tooling before the first production wave, and agree who carries the pager for migrated workloads during hypercare.

Common pitfalls

• Migrating servers without moving the data gravity and dependencies they use.
• Underestimating network egress and licensing costs.
• Rehosting everything and calling modernization complete.
• Missing hidden dependencies, such as hard-coded IPs and shared file systems.

Metrics to watch

Percentage of portfolio per strategy, applications migrated per wave, cutover incident count, run cost per workload before and after, decommissioned server count, and the share of workloads later optimized after rehost.

Track cost per workload from the first wave. Early data on rehost and replatform run costs calibrates estimates for later waves and shows which workloads deserve a second optimization pass.

Example workload decision record

application: claims-portal
owner: insurance-platform
score:
  business_value: 4
  technical_debt: 3
  compliance_risk: 2
decision: replatform
rationale: Move database to a managed service, keep application code unchanged
wave: 2
dependencies: [identity-service, document-store]
cutover:
  window: sunday-0200-0600
  rollback: restore dns to on-prem within 30 minutes

Key takeaways

• Decide per workload and record the reasoning.
• Retire first; it is the cheapest migration.
• Pilot to learn, then scale with waves ordered by dependency.
• Plan optimization after cutover, not instead of it.