A surprising amount of migration friction has nothing to do with AWS. It comes from a single word doing too much work: “migrate.” A CFO who says “let’s migrate to the cloud” is usually picturing something closer to moving offices — pack everything up, unpack it somewhere else, done. An engineer hearing the same sentence is already thinking about seven genuinely different strategies, each with a different cost, timeline, and outcome. Neither side is wrong; they’re just not talking about the same thing yet.
AWS calls these strategies the “7 Rs”. Older guides list six; AWS has since added a seventh, Relocate. Understanding them — even at a non-technical level — is one of the highest-leverage things a business stakeholder can do before a migration project starts. It reframes the conversation from “when will we be migrated” to the much more useful “which of these seven things does each system actually need.”
The seven strategies, plainly
Rehost — commonly called “lift and shift.” The application moves to AWS essentially unchanged: same architecture, same configuration, just running on AWS infrastructure instead of on-premises hardware or another provider. It’s the fastest option and requires the least redesign, which makes it a reasonable first move for time-pressured migrations — but it also captures the least benefit, since an inefficiently built application stays inefficiently built, just in a new location.
Relocate — a whole platform moves to its cloud equivalent in one go, without buying new hardware, rewriting applications or changing how they’re run. The typical case is an on-premises VMware estate moved to a VMware environment running on AWS: a large number of servers can move at once, because nothing inside them changes. The same strategy covers moving workloads that are already on AWS to a different account, network or Region. It’s quick and low-risk, but like rehosting, it carries the old design across with it.
Replatform — sometimes described as “lift, tinker, and shift.” A small number of targeted optimisations are made during the move, without a full architectural rebuild. The most common example is swapping a self-managed database running on a virtual machine for a managed equivalent like Amazon RDS — same database engine, same application code mostly unchanged, but now AWS handles patching, backups, and failover.
Repurchase — the application isn’t moved at all; it’s replaced with a different product, usually a SaaS or cloud-native equivalent. A self-hosted CRM migrating to a cloud CRM platform is a repurchase, not a migration in the technical sense — the underlying software changes, not just its location.
Refactor (sometimes “re-architect”) — the application is substantially rebuilt to take advantage of cloud-native patterns: breaking a monolith into services, moving to managed, serverless, or auto-scaling components. This captures the most long-term benefit — better scalability, lower operational overhead, often lower running cost — but it also takes the most time and carries the most execution risk.
Retire — the system is decommissioned rather than moved. Every estate has some of these: an old reporting tool nobody’s opened in two years, a duplicate system left over from a merger. Migration projects are a natural moment to find them, since nobody wants to pay to move something that should have been switched off already.
Retain — the system stays where it is, for now. This isn’t a failure to migrate — it’s a deliberate decision, usually driven by a dependency that isn’t ready to move yet, a compliance or data residency constraint, or simply a system whose migration cost doesn’t currently justify the benefit.
Why the choice isn’t really a technical one
Here’s the part that surprises most non-technical stakeholders: picking between these seven is rarely an engineering decision at its core. It’s a cost, time, and risk trade-off — and it’s made per application, not once for the whole estate. A business with fifty systems will typically end up with a mix of several strategies, not one applied uniformly. Treating “our migration strategy” as a single answer is usually the first sign a plan hasn’t been thought through at the application level yet.
A worked (illustrative) example
Picture a mid-sized business with three representative systems. A legacy CRM, business-critical but running on an outdated on-premises server nearing end of support — a reasonable call is to rehost it first, to get off ageing hardware quickly, then replatform later once there’s headroom to plan a managed-database move without time pressure. An old on-premises file server, mostly holding archived documents nobody actively works from — a strong retire candidate, with anything genuinely still needed moved into S3 instead of a running server. A bespoke finance application tightly coupled to a specific, unsupported operating system version, where the vendor relationship or a rebuild timeline isn’t settled — a sensible retain, revisited once that dependency resolves.
Three systems, three different strategies, one coherent plan. That’s the normal shape of a real migration, not the exception.
What non-technical stakeholders actually need to weigh in on
The useful contribution from business stakeholders isn’t picking AWS services — it’s supplying the inputs that only they have: how much downtime is genuinely tolerable during a cutover for each system, what budget exists for a Refactor-level rebuild versus a faster Rehost now, and which systems the business can least afford to get wrong. Those three inputs, applied system by system, are what actually determine the right mix of the seven strategies — far more than any technical preference.
Working through exactly this categorisation, system by system, is the core output of a Yemberzal Cloud Migration Assessment — turning “we need to migrate” into a concrete, sequenced plan that says which of the 7 Rs applies to each part of the estate, and why.