The Four Rs of Cloud Migration: Choosing the Right Path for Legacy Systems
Rehost, replatform, refactor, or rearchitect — the wrong choice for a given system usually costs more than any of the four done well.
Every legacy migration conversation eventually runs into the same tension: the business wants speed, and engineering knows that the fastest path (lift-and-shift) often creates the most expensive long-term outcome (a cloud bill for an application that still behaves like it's running in an on-prem data center). The four Rs framework exists to make that trade-off explicit, system by system, instead of applying one strategy to an entire portfolio.
Matching the strategy to the system, not the deadline
Rehosting — moving a workload to cloud infrastructure with minimal changes — is the right call for systems nearing end-of-life, low-value applications not worth further investment, or migrations under genuine time pressure, like a data center exit. It's fast, but it rarely reduces operating cost on its own.
Replatforming makes targeted changes — swapping a self-managed database for a managed cloud service, for example — to capture some cloud-native benefit without a full rewrite. It's often the best return on effort for applications that are stable and well-understood but not strategic enough to justify a rebuild.
Refactoring and rearchitecting — restructuring code or redesigning the application around cloud-native, often microservices-based patterns — deliver the largest gains in scalability, resilience, and development velocity, but require the largest investment. They're worth it for systems that are core to competitive differentiation and where the current architecture is genuinely constraining the business, not just for the sake of modernization.
The portfolio view matters more than any single decision
The organizations that get the most value from cloud migration rarely pick one strategy for everything. They run a structured application rationalization exercise — assessing business criticality, technical complexity, and total cost of ownership across the whole portfolio — and then apply a mix of all four Rs deliberately, retiring what shouldn't have been running in the first place along the way.