Cloud Migration Strategy: The Six Ways to Actually Move, and Why Most Companies Pick the Wrong One First
"We're moving to the cloud" is a sentence that hides a lot of very different projects underneath it. Lifting a legacy application straight onto a virtual machine is a cloud migration. Rebuilding that same application as a cloud-native, containerized service is also a cloud migration. The two projects share almost nothing in cost, timeline, or risk, and companies that treat "cloud migration" as one strategy instead of six distinct options routinely pick the slowest, most expensive path for a workload that needed the fastest, cheapest one.
The Six Strategies (The "6 Rs")
Rehost. Move an application to the cloud with minimal changes, essentially the same server, now running on cloud infrastructure instead of on-premises hardware. Fastest option, lowest short-term cost, and the default choice when the goal is exiting a data center contract or hardware refresh cycle on a deadline. The tradeoff: it inherits whatever inefficiencies the application already had, and doesn't take advantage of cloud-native cost or scaling benefits.
Replatform. Make targeted optimizations during the move, swap a self-managed database for a managed cloud database service, for instance, without rearchitecting the application itself. This is the middle ground: meaningfully more benefit than a straight rehost, without the cost and time of a full rebuild.
Repurchase. Replace the existing application with a SaaS alternative entirely, moving from a self-hosted CRM to Salesforce, for example. This isn't really a migration in the technical sense, it's a decision to stop maintaining the old system and adopt something already built. Often the fastest path to modern functionality when the underlying workflow isn't a competitive differentiator worth custom-building.
Refactor/Re-architect. Redesign the application to be cloud-native: microservices instead of a monolith, containerized, built to take full advantage of auto-scaling and managed cloud services. Highest upfront cost and longest timeline of the six, and also the option that unlocks the deepest long-term cost and performance benefits. Worth it when the application is core to the business and expected to scale significantly.
Retire. Some applications, once inventoried, turn out to be barely used or fully redundant with something else already in the stack. Retiring them isn't a migration outcome so much as a migration side effect, but it's a real one: enterprise cloud migrations routinely find that a meaningful share of the existing application portfolio doesn't need to move anywhere at all.
Retain. Not everything moves. Some workloads stay on-premises deliberately, for regulatory reasons, because the app is being sunset anyway, or because the cost of migrating exceeds any benefit for a system with a short remaining lifespan. A retain decision is a legitimate strategic outcome, not a failure to migrate.
Why Most Companies Default to Rehost, and Why That's Often the Right First Move Anyway
Rehosting is frequently criticized as the "lazy" migration, and sometimes that criticism is fair. But there's a real strategic case for starting there deliberately: get out of the data center or legacy contract on schedule with a rehost, then replatform or refactor specific workloads afterward, once the team has real cloud operating experience and isn't trying to learn cloud architecture and hit a hard deadline simultaneously. The mistake isn't rehosting. It's rehosting everything and never coming back to optimize the workloads that actually warrant it.
The Assessment Question That Should Come Before Any Strategy Gets Picked
The strategy decision shouldn't happen application by application in isolation. It starts with a portfolio assessment: what does the business actually run, how business-critical is each piece, how much technical debt does it carry, and what's the realistic cost of leaving it exactly as it is for another two years. Applications with high business value and high technical debt are the strongest refactor candidates. Applications that are stable, low-change, and not a competitive differentiator are usually the strongest rehost or even retain candidates. Skipping this assessment and defaulting to the same strategy for every workload is one of the most consistent sources of migration cost overrun.
What Actually Drives Migrations Over Budget
Underestimating dependency mapping is the recurring theme. An application rarely stands alone: it talks to other internal systems, has undocumented integrations, or depends on a data format nobody's touched in years. Migrations that skip a real dependency audit tend to discover these connections mid-project, which is the expensive way to find them. Amorisoft's cloud migration engagements start with this mapping exercise specifically because it's where the majority of schedule risk actually lives, not in the infrastructure provisioning itself, which has become largely commoditized across the major cloud providers.
Choosing Between AWS, Azure, and GCP Isn't Usually the Hard Part
Companies spend a surprising amount of strategic energy on cloud provider selection, when in practice the three major providers are more similar than different for most standard workloads, and the choice often comes down to existing enterprise agreements, team familiarity, or specific managed services one provider does better than the others for a particular use case. The harder, more consequential decisions are the migration strategy per application and the sequencing of the migration itself, not which logo ends up on the invoice.
A Realistic View of Sequencing
Migrating everything at once is rarely the right call, even when the deadline pressure makes it tempting. A phased approach, starting with lower-risk, lower-complexity workloads to build team capability and prove the process, then moving toward the more business-critical and technically complex systems, tends to produce fewer surprises than a single cutover involving the entire application portfolio. The lower-stakes early migrations also surface process gaps, security review bottlenecks, change management friction, while the cost of getting something wrong is still contained.
The question worth asking before any migration plan gets finalized isn't "how fast can we move everything." It's "which of these six strategies does each part of the portfolio actually need," followed closely by "what order minimizes the risk of learning that the hard way, on the workload that can least afford it."