Cloud migrations rarely fail because of the cloud itself. They fail because one strategy — usually “lift and shift everything” — gets applied to a portfolio of workloads with very different economics, dependencies, and risk profiles. A twenty-year-old monolith with a fragile database does not migrate the same way as a stateless API that is already containerized, and forcing them down the same path is how you end up with a migration that costs more than the projected savings and drags on for years. The 6Rs — rehost, replatform, repurchase, refactor, retire, and retain — are a decision vocabulary rather than a single answer. This guide walks through each strategy and a practical framework for assigning the right one to each workload.
Why a single migration strategy fails
A monolithic migration plan usually optimizes for one of two things — speed or modernization — and whichever it chooses, the other half of the portfolio pays for it. Forcing a rehost on a workload that needs refactoring preserves technical debt and keeps the cloud bill inflated, while forcing a refactor on a workload that just needs to keep running turns a six-month migration into a two-year rewrite. The value of the 6Rs is that they let you match the strategy to each workload's age, business criticality, and long-term roadmap. A workload you plan to retire in a year should not be refactored; a workload that will anchor your product for a decade should not be merely rehosted. Strategy selection is fundamentally an inventory problem, and most organizations never do the inventory.
The 6Rs: a vocabulary for migration decisions
The six strategies are usually grouped by how much change they involve. Rehost, or lift-and-shift, moves a workload to the cloud with minimal modification — the fastest and cheapest path, but one that carries existing technical debt forward. Replatform, sometimes called lift-tinker-and-shift, makes a small number of targeted changes, such as moving a self-managed database onto a managed service, to capture cloud benefits without a rewrite. Repurchase replaces a component with a SaaS or managed equivalent, swapping a self-hosted tool for its cloud-native counterpart. Refactor, or rearchitect, is a genuine rewrite of the application to take advantage of cloud-native capabilities, and it is the most expensive and highest-reward strategy. Retire decommissions workloads nobody needs anymore, and retain deliberately leaves a workload in place because moving it is too risky or uneconomical.
- Rehost (lift-and-shift): move as-is — fastest and cheapest, but carries existing technical debt forward.
- Replatform (lift-tinker-and-shift): small targeted changes such as managed databases or containerization.
- Repurchase: replace a self-hosted component with a SaaS or managed equivalent.
- Refactor (rearchitect): rewrite for cloud-native capabilities — the highest cost and highest reward.
- Retire: decommission workloads that no longer have an owner or a reason to exist.
- Retain: deliberately leave a workload in place when moving it is not justified.
The low-effort half: rehost, replatform, repurchase
For stable, well-understood workloads that are not strategic, the low-effort strategies are usually the right economic call. Rehost is the default for legacy VMs that simply need to keep running: you get out of the data center, reduce capital expenditure, and buy time to modernize later. The trap is treating rehost as the end state rather than a waypoint — a rehosted monolith still carries all of its original operational burden, just on someone else's hardware. Replatform captures meaningful wins cheaply: moving a self-managed database to a managed service removes patching, backup, and failover from your team's plate without touching application code. Repurchase is often the fastest way to shed a tool's operational overhead, but it introduces a vendor dependency you should accept deliberately rather than by accident.
The strategic half: refactor, retire, retain
Refactor is where the real value lives, and where the real risk concentrates. A refactor is a product decision, not an infrastructure decision, so it belongs on the product roadmap with a business owner, a success metric, and a stop-loss trigger — not buried inside a migration program. Retire and retain are the two most underused strategies, and both are pure inventory wins. Every portfolio contains workloads with no named owner that can be retired without a single complaint, and every portfolio contains workloads that should not move yet for cost, compliance, or risk reasons. Saying “retain” out loud is what keeps a migration honest, because it forces you to acknowledge that not everything belongs in the cloud right now.
Assigning a strategy: a decision framework
The practical way to assign strategies is to score each workload against a small set of criteria instead of relying on instinct. For each application, answer four questions: how business-critical is it, how much would refactoring improve it, how soon does it need to move, and what does it cost to run where it is today. The answers place each workload into a rough quadrant. High criticality with high modernization value points to refactor; low criticality with low value points to rehost or retire; and anything with a clean managed or SaaS equivalent is a repurchase candidate. Write the result down — a migration inventory is the single highest-leverage artifact of the whole program, and teams that skip it almost always re-litigate the same decisions halfway through.
- Start the inventory: gcloud compute instances list --format="table(name,zone,machineType,status)"
- Find orphaned storage: gcloud compute disks list --format="table(name,sizeGb,type)"
- Inventory every workload with an owner, a business-criticality rating, and a modernization-value rating.
- Flag any workload without a named owner for immediate retirement review.
- Score each workload: high criticality plus high value means refactor; low plus low means rehost or retire.
- Look for managed-service or SaaS equivalents for anything still self-hosted to identify replatform and repurchase candidates.
- Record the chosen strategy, the owner, and the review date so the decision is not relitigated later.
Running the migration without downtime
Whichever strategies you choose, execution has to be boring and reversible. For rehosts and replatforms, move one workload at a time behind a traffic cutover, keep the old environment warm until you are confident, and rehearse the rollback before you need it. For refactors, ship incrementally with feature flags and a parallel run of the old system rather than a big-bang cutover. The same discipline that makes a Kubernetes upgrade safe — version skew awareness, disruption budgets, and a rehearsed rollback — applies to migration cutovers, because a migration is just a very large change with a very large blast radius.
Cost, security, and operational readiness
A migration is also the cheapest moment to fix the operational foundations that otherwise become someone else's problem after cutover. Before you move, decide how the target environment will enforce identity and least-privilege access, because retrofitting them after go-live is far more expensive. Right-size from day one instead of mirroring oversized on-premises capacity, and treat the migration as a forcing function to revisit reserved commitments and autoscaling so the first cloud bill does not come as a shock. And update your incident response playbook for the new environment before traffic actually moves.
A migration readiness checklist
- Every workload has a recorded strategy (rehost, replatform, repurchase, refactor, retire, or retain) and a named owner.
- The target environment's identity, least-privilege access, and secret handling are designed and approved.
- Capacity is right-sized with committed-use discounts and autoscaling reviewed before the first month's bill.
- A rollback runbook exists and has been rehearsed on at least one non-production cutover.
- The incident response playbook covers the new environment, and the on-call engineer can reach it.
- The old environment is kept warm until the new one has survived a full business cycle.
Choosing the right strategy per workload — and executing it as a series of small, reversible cutovers — is the difference between a migration that pays for itself and one that becomes a permanent work-in-progress. If your team is planning a move to Google Cloud and wants a second pair of eyes on the inventory, the strategy assignments, or the cutover plan, Secpros can review your migration approach and return a short, prioritized action plan.