Cloud Migration Strategy and the 7 Rs

Part 1 ended on the decision that governs every cloud migration: how much to change each workload as it moves. A strategy is what turns that single decision into a plan across an entire estate — dozens or hundreds of workloads, each needing its own answer. The industry’s framework for this is the 7 Rs: seven named moves, ordered from least to most invasive, that give you a vocabulary for treating each workload differently. This part walks all seven, what each costs and buys, and how to assemble them into a strategy rather than a wish.

Why seven moves, not one decision

The most common strategy mistake is to make cloud migration a single, estate-wide choice: we are lifting everything to the cloud, or we are re-architecting everything cloud-native. Both are wrong for the same reason — an estate is never uniform. Parts of it are dead weight nobody has switched off. Parts are commodity functions a SaaS product does better. Parts are stable and fine exactly as they are. And a minority — usually a small one — are where the business genuinely needs capability the current design can’t deliver.

The 7 Rs exist so you can give each of those parts the move it actually needs. They are not a menu where you pick one and commit the estate to it. They are a way to make a per-workload decision, then add the decisions up into a plan.

The seven moves

R	What it changes	Relative cost	Best when
Retire	Removes the workload	Lowest	Nobody actually uses it
Retain	Nothing, for now	None	It’s stable and the cloud adds nothing
Rehost	Infrastructure only	Low	You need out of a data center on a deadline
Replatform	Infra + light adaptation	Low–medium	Managed services cut real operating pain
Repurchase	Swaps for a SaaS product	Medium	The function is commodity, not a differentiator
Refactor / re-architect	Internal structure	Medium–high	The business needs new capability the design blocks
Rebuild	Everything	Highest	The code is genuinely beyond saving

Retire — the cheapest move is the one you skip

Most large estates carry workloads nobody uses: superseded reporting jobs, abandoned internal tools, modules kept alive out of habit. Retiring them — confirming they are genuinely dead, then switching them off — shrinks everything downstream. Fewer workloads to migrate, less data to move, less to test, a smaller cloud bill at the end. It is unglamorous and routinely skipped, which is exactly why it has the best return of any move on this list.

Retain — deciding to stay, on purpose

Retain keeps a workload where it is — deliberately, not by neglect. A stable, low-change system the business asks nothing new of often has no business case for moving. Latency-sensitive or compliance-bound workloads may need to stay on-premises regardless. The distinction that matters: retain is a documented choice you revisit when the facts change, not a failure to decide.

Rehost — lift and shift

Rehosting moves the workload to the cloud with as few changes as possible — same code, same architecture, new infrastructure underneath. It is fast and low-risk, and it is genuinely the right call when a data center is closing or a hardware contract is ending and you need out on a deadline. Its limit is equally clear: it changes where the system runs, not how hard it is to change. The coupling and the lost knowledge come along for the ride. Rehost relocates the legacy condition; it does not cure it.

Replatform — adapt as you move

Replatforming is rehost with targeted changes: swapping a self-managed database for a managed one, containerizing the app, moving files to object storage. You don’t rewrite the application, but you adapt it enough to capture real operating benefit — less infrastructure to babysit, better scaling, lower run cost. Its ceiling is the same as rehost’s, a little higher: the internal structure is untouched, so the deep changeability problems remain.

Repurchase — buy instead of move

Repurchasing replaces a custom workload with a commercial SaaS product that does the same job. For commodity functions — CRM, payroll, expense management, generic workflow — a bought product is maintained by someone else and usually cheaper to own than a bespoke system you keep alive. The trade is exact fit and control for integration work and vendor dependence. For functions that are not a differentiator, that trade is almost always worth it.

Refactor and re-architect — change the inside

This is where cloud migration becomes modernization. Refactoring restructures internal code without changing behavior; re-architecting goes further — breaking a monolith into well-bounded services, adopting event-driven data flows, making the system actually elastic — while preserving what it does. This is the band that addresses the legacy condition directly: it makes the next change cheap and safe, which is the entire point of moving at all. It is also where the risk lives, because the behavior you must preserve includes the edge cases nobody documented.

Rebuild — start from a clean sheet

Rebuilding re-implements the functionality from scratch on a modern, cloud-native stack. It is the most powerful move and the most dangerous — right only when the existing code is genuinely beyond saving. Done as a big-bang rewrite, replaced at one future cutover, it is also the most reliable way to fail; BCG found up to 70% of digital transformations miss their objectives (BCG, 2023), and big-bang shape is a leading cause. The fix is not to avoid rebuilding — it is to rebuild incrementally, behind a facade that lets old and new run side by side.

Containing the risk in the expensive Rs

Refactor, re-architect, and rebuild are where the value is and where the danger is. Disciplined migration contains that danger with one structural move: change the system one slice at a time, and prove each slice behaves identically to the original before it carries live traffic. We call that proof a parity gate — functional parity, data integrity, and non-functional parity (performance, security) verified against the legacy’s actual behavior, often on shadow traffic, before promotion. Re-architecting without that proof is how migrations quietly introduce the bugs that surface months later. With it, the expensive Rs become safe to use.

Assembling the strategy

A cloud migration strategy is the output of running the seven Rs across an inventoried estate, then sequencing the results:

• Retire the dead weight first — it shrinks everything after it.
• Retain the stable, low-value-to-move workloads, documented and revisited.
• Repurchase the commodity functions a product does better.
• Rehost or replatform the workloads that need a new home but not new logic.
• Refactor, re-architect, or rebuild the minority that need new capability — incrementally, with parity proven at each step.

The output is not “we are moving to the cloud.” It is a map: this workload retires, that one becomes SaaS, these three re-architect slice by slice, the rest are rehosted to hit the data center deadline. Sequencing follows value and dependency — prove the approach on something low-stakes, migrate the workloads that unblock others, and leave the hardest, highest-value systems until the team has earned confidence on smaller ones.

Sequencing in practice: a worked example

The framework is easier to apply with a concrete run-through. Consider a typical mixed estate: an internal wiki nobody has opened in over a year, a home-grown expense-reporting tool, a nightly batch job that feeds a reporting warehouse, a billing job running on physical hardware whose vendor stopped selling replacement parts, a customer-facing web app under real growth pressure, and a decade-old order-management monolith the business wants to give real-time order status, a capability its current design cannot support.

Workload	The signal	R assigned	Why
Internal wiki	No meaningful usage in a year	Retire	The cheapest workload to migrate is the one you delete first
Expense-reporting tool	Commodity function, not a differentiator	Repurchase	A SaaS product does this better and someone else maintains it
Nightly reporting job	Stable, no new requirements, low change rate	Retain, revisit at next hardware refresh	Nothing about it is under pressure to change yet
Billing job on aging hardware	The hardware, not the logic, is the actual deadline	Rehost	Needs out fast, and the internal structure isn’t the problem
Customer-facing web app	Needs to scale for a launch, but deploys are manual and fragile	Replatform now, re-architect hot paths later	Buys headroom immediately without a full rewrite
Order-management monolith	Business needs a capability the coupling blocks	Refactor / re-architect, incrementally	This is where the real coupling lives, and it earns the expensive move

The sequencing follows from the table, not from a separate decision. Retire the wiki immediately, it costs nothing and frees attention. Repurchase and retain proceed in parallel, both low-risk and low-effort. Rehosting the billing job is time-boxed to the hardware deadline. Replatforming the web app happens next because growth is the pressing constraint. The order-management refactor becomes the multi-quarter program, run one slice at a time behind a facade so the business keeps transacting throughout, with the other five moves already banked as evidence the team can execute before it takes on the hardest one. That ordering, cheap and low-risk first, the hard re-architecture last and de-risked by practice, is the actual output of a cloud migration strategy. The 7 Rs name the moves. A sequence like this is the plan.

A framework isn’t a judgment

The 7 Rs organize a decision; they do not make it. The framework will not tell you which R a given workload needs — that judgment requires understanding what the workload does, how the business depends on it, and how hard it actually is to change, none of which a spreadsheet column supplies. A team that maps every workload to an R without that underlying analysis has produced a tidy artifact and learned nothing. The Rs are the vocabulary; the assessment is the work.

Where this leads

In practice, the seven collapse to a few decisions you will genuinely wrestle with. Retire, retain, and repurchase are usually clear once you understand a workload. The hard, recurring choice — the one that drives cost, risk, and payoff more than any other — sits in the middle of the spectrum: do you lift this system as-is, or change how it’s built? Part 3, Lift-and-Shift vs Refactor, turns that into a decision framework you can apply to a real workload.