Three of the 7 Rs cover the workloads you actually agonize over: rehost (lift-and-shift), replatform (lift-tinker-shift), and refactor (re-architect). Pick wrong and you either leave the cloud savings on the table or blow your timeline on a rewrite that did not need to happen. This page defines each precisely, scores them on cost, effort, risk, time-to-value, and long-run payoff, and gives you a per-workload framework for choosing — plus the migrate-then-modernize sequencing that lets you defer the hard call. A vetted partner runs the assessment that assigns these (MAP Assess, often AWS-funded) and the migration that follows is frequently MAP-funded too — low or $0 cost to you.
AWS's migration model has seven dispositions — the 7 Rs — but four of them decide themselves once you have discovery data. The real strategy debate, the one that drives most of your migration's cost and risk, is among rehost, replatform, and refactor. This page is the head-to-head on those three.
The 7 Rs are Retire, Retain, Rehost, Relocate, Repurchase, Replatform, and Refactor. (The full set, with the portfolio analysis that distributes them across an estate, lives on the sibling AWS migration strategy page.) Four of the seven are usually obvious after discovery: Retire the apps with near-zero usage, Retain the ones blocked by compliance or an imminent sunset, Relocate a large VMware estate that needs a fast exit, Repurchase a commodity app when a mature SaaS equivalent exists. You rarely lose sleep over those.
The agonizing happens on everything else — the core applications you are keeping and running on AWS. For each of those you face exactly one question with three answers: do you move it as-is (rehost), move it while swapping a few components for managed services (replatform), or rebuild it cloud-native (refactor)? That single choice, repeated per application, is what determines whether your migration finishes in two quarters or drags across two years, and whether the AWS bill afterward is lower than the data center or embarrassingly higher.
The stakes are asymmetric in an instructive way. Choosing rehost when you should have replatformed costs you some ongoing savings you could fix later. Choosing refactor when you should have rehosted can sink the entire migration timeline — because a refactor is a software project, not a migration, and software projects slip. That asymmetry is why the honest default leans conservative: move first, modernize second. The rest of this page makes that concrete, defines each disposition precisely, scores them on five axes, and gives you a per-workload framework for the call.
These three terms get used loosely, and the looseness is where bad decisions start. "We'll replatform it" can mean anything from "move the database to RDS" to "rewrite half the app." Here is what each disposition precisely is, what changes, and what tooling does the work.
What changes: only the hosting. The same operating system, the same application binaries, the same configuration — now running on Amazon EC2 instead of your data center or another cloud. No code changes, no architecture changes. The app does not know it moved.
How it is done: the workhorse is AWS Application Migration Service (MGN). You install a lightweight agent on each source server; MGN block-replicates the server to AWS continuously and keeps it in sync, so the actual cutover is minutes of downtime rather than a multi-day copy. For VMs you cannot put an agent on, agentless and snapshot-based paths exist. The source keeps running until you cut over, which is what makes rollback trivial.
The catch people miss: rehosting on-prem-sized hardware onto equivalently-sized EC2 instances can cost more per month than the data center, because you are now paying cloud rates for over-provisioned capacity. The savings in a rehost come almost entirely from right-sizing during the move (and from Savings Plans / Reserved Instances afterward), not from the move itself. A rehost without right-sizing is the classic way to be surprised by the first AWS invoice.
What changes: the hosting plus a small number of components, swapped for AWS managed services — but the application code stays essentially the same. The canonical replatform: keep the app, but move its self-managed database onto Amazon RDS or Aurora, put it behind an Application Load Balancer, and containerize the app tier onto ECS, App Runner, or Elastic Beanstalk instead of a raw EC2 VM. You stop managing database patching, backups, and failover yourself; AWS does it.
How it is done: MGN still moves the compute, but now paired with managed-service targets. A same-engine database move (self-managed PostgreSQL → Aurora PostgreSQL, self-managed MySQL → Aurora MySQL) is a clean replatform — the Database Migration Service (DMS) handles the data copy and you point the app at the new endpoint. A change of database family (Oracle → Aurora PostgreSQL) is not a replatform; it requires the Schema Conversion Tool (SCT) plus application changes and sits much closer to refactor in effort.
Why it is the sweet spot: replatform captures most of the cloud-native operational savings — managed databases, auto-scaling, load balancing, automated backups — for a fraction of the effort and risk of a full rewrite. For a large share of web and application workloads, this is where migrate-then-modernize lands its first real modernization step.
What changes: the architecture itself. You decompose a monolith into microservices, move to serverless (Lambda, API Gateway, EventBridge, DynamoDB, Step Functions), adopt containers on EKS, or split a single data store into purpose-built databases. This is a software engineering project that happens to target AWS — not a migration of the existing app.
How it is done: by your engineering team (or the partner's), writing and shipping code over weeks-to-months, with its own design, testing, and rollout. Migration tooling barely features; this is application development. Often the rehosted or replatformed version runs in production while the refactored version is built alongside it, then traffic is shifted over.
When it actually pays back: only when the current architecture is the bottleneck — it cannot scale past a wall, it cannot ship features fast enough, or its run cost is structurally high in a way a serverless or elastic redesign genuinely fixes. Refactoring an app that works fine and is cheap to run is wasted money and wasted time. The payoff, when the driver is real, is the largest of the three: lowest steady-state cost, highest elasticity, fastest future feature velocity.
Rehost changes where the app runs. Replatform changes where it runs plus a few components. Refactor changes what the app is. Effort, cost, risk, and payoff all rise in that order — and so does the chance of blowing your timeline.
A good disposition decision weighs five things, not one. Teams that only look at steady-state cost over-refactor; teams that only look at effort forever-rehost. Score each option on all five and the right answer for a given workload usually falls out.
The five axes that matter for the rehost-vs-replatform-vs-refactor call:
Notice the tension: the axis that favors refactor (long-run payoff) is the one that takes longest to materialize, while the axes that favor rehost (cost, effort, risk, time-to-value) are immediate. That is precisely why migrate-then-modernize works — you take the immediate wins first via rehost/replatform, then chase the long-run payoff via refactor on the specific apps where it is worth waiting for. You do not have to choose between "fast and safe" and "high payoff"; you sequence them.
A practical scoring tip the assessment partners use: weight the axes by your actual constraint. If a data-center lease expires in six months, time-to-value and risk dominate — rehost the bulk to hit the deadline. If you have a comfortable runway and a serverless redesign would cut a runaway bill in half, long-run payoff justifies refactoring that workload. The weights are situational; the axes are constant.
You assign a disposition per application, not per company. Here are the concrete signals that point a given workload toward rehost, replatform, or refactor — the heuristics a portfolio assessment turns into a disposition map.
You need a fast exit — a data-center lease expiry, a cloud-renewal deadline, an acquisition cutover — and speed beats optimization. Rehost is the only disposition that reliably moves a large estate inside a few months.
The app is stable and untouchable — a legacy system that works, that nobody wants to risk changing, or whose source code is poorly understood. Moving it as-is preserves behavior exactly.
It is a stepping stone — you intend to modernize later but want to be on AWS first, capturing real usage data before deciding how to replatform or refactor it. Most rehosts in a healthy migration are explicitly stepping stones, not endpoints.
It is commercial-off-the-shelf software you cannot change anyway, or a third-party app where re-architecting is not your call.
The app carries a self-managed database you are tired of patching, backing up, and babysitting — moving it to RDS or Aurora (same engine) is a high-value, low-rewrite win that sheds a whole category of operational toil.
You want auto-scaling and managed load balancing without re-architecting — containerizing onto ECS or App Runner behind an Application Load Balancer gets you elasticity while the app code stays put.
The workload is a standard web/app tier (the bulk of most estates) where the managed-service savings clearly justify a moderate effort but a full rebuild does not.
You are doing a same-engine database consolidation — self-managed PostgreSQL/MySQL onto Aurora — where DMS handles the move cleanly. (If the engine family changes, that is closer to refactor; see the dedicated database-migration siblings.)
The architecture is hitting a scaling wall — a monolith that cannot scale horizontally, a single database that is a bottleneck, a system that falls over at peak. The redesign solves a problem you actually have today.
Feature velocity is the constraint — the monolith is so coupled that every change is slow and risky, and decomposing it into services would materially speed up the roadmap.
The run cost is structurally high in a way a serverless or elastic redesign genuinely fixes — e.g. a workload that idles 90% of the time but runs always-on servers, where moving to Lambda/Fargate would cut the bill sharply.
It is a core differentiator worth the investment, you have the runway, and ideally you are doing it as a scoped, separately-funded follow-on after the app is already on AWS — not as a gate on the whole migration.
The most important insight in this whole debate is that rehost-vs-refactor is rarely a permanent fork — it is a sequencing decision. Migrate-then-modernize lets you take the safe, fast path first and still get the high-payoff path later, on the apps that deserve it.
The pattern is simple to state and disciplined to execute: rehost or replatform to exit the source environment first, then refactor selectively once you are on AWS. The logic is that the cost and risk of running in two places — paying two bills, carrying cutover risk, operating a hybrid network — accrue every day you delay the exit. So the first priority is always to get out of the data center or off the old cloud, using the lowest-risk disposition that achieves it.
Once you are on AWS, three things change in your favor. First, you have real usage data — CloudWatch metrics, Cost Explorer breakdowns, actual traffic patterns — so you refactor based on where the spend and the bottlenecks demonstrably are, not on a pre-migration guess. Second, the refactor becomes a scoped, independently-funded project with its own timeline, decoupled from the migration deadline, so a slip in the rebuild does not delay the exit. Third, your team is now fluent in AWS, having operated the rehosted workloads, so the refactor is built on real operational knowledge rather than theory.
The anti-pattern is coupling the two. Trying to refactor while migrating means you are simultaneously solving "how do we move this" and "how do we rebuild this" — two hard problems whose risks multiply rather than add. It is the single most common reason a six-month migration becomes an eighteen-month one. The discipline is to resist the engineering instinct to "do it right while we're in there" and instead move first, modernize second.
Rehost or replatform now to exit and start saving. Refactor later, as a scoped follow-on, only on the apps where real usage data proves the payoff. Never gate the migration's exit deadline on a rewrite — that is how migrations slip by quarters.
| Dimension | Rehost (lift-and-shift) | Replatform (lift-tinker-shift) | Refactor (re-architect) |
|---|---|---|---|
| What changes | Where it runs (VM → EC2) | Where it runs + a few components | The architecture itself |
| Code changes | None | Minimal (config / managed-service swaps) | Significant (re-architecture) |
| Primary AWS tooling | Application Migration Service (MGN) | MGN + RDS/Aurora + ECS/App Runner + DMS | Lambda / EKS / DynamoDB / API Gateway |
| Upfront cost | Lowest | Moderate | Highest |
| Effort | Low | Moderate | Highest (a software project) |
| Risk | Low (rollback to source) | Moderate (DB/connection changes) | High (scope creep, slips, new-code bugs) |
| Time-to-value | Fastest (days–weeks) | Fast (weeks) | Slowest (months) |
| Steady-state cost | Source-like (lower if right-sized) | Lower (managed services + right-sizing) | Potentially lowest (serverless/elastic) |
| Long-run payoff | Low (no architectural gain) | Solid (ops savings, no rewrite) | Highest when justified (scale + agility) |
| Best for | Fast exit; stable apps; stepping stone | Most web/app workloads; the modernize sweet spot | Apps where the architecture is the bottleneck |
Almost every disposition mistake is a version of one of two errors: refactoring too much too early, or never modernizing at all. They are mirror images — over-ambition and under-ambition — and both are expensive in different ways.
Strip away the theory and the decision for a single workload comes down to a short cascade of honest questions. This is the framework a good assessment applies per application — and the one you can apply yourself before the partner ever runs discovery.
Walk each workload through these in order; the first one that clearly applies is usually your answer:
The honest meta-point: the right migration plan is almost always less ambitious than engineering instinctively wants and more ambitious than finance instinctively fears. Engineering gravitates to refactor (it is the interesting work); finance gravitates to forever-rehost (it looks cheapest on a one-line move cost). The framework above lands between them — rehost/replatform the bulk to move fast and safe, refactor the genuine few where the payoff is real and provable.
This is exactly the judgment a vetted partner brings, and where the funding hook lands. A migration partner runs the MAP Assess phase — AWS Application Discovery Service plus a 2–6 week portfolio analysis — and applies this framework per application against real utilization and dependency data, producing a disposition map you can trust rather than argue about. Under the AWS Migration Acceleration Program (MAP), that Assess phase is frequently AWS-funded (often free), and the Mobilize + Migrate phases that follow are credited a large share too. For qualifying migrations — typically those carrying a meaningful post-migration AWS-spend commitment — this brings the customer's net migration cost to little-or-nothing. Where a migration does not qualify, the value is a vetted partner who de-risks the cutover. CloudRoute tells you which of the two you are looking at, up front, and routes you to the partner — you pay $0 to CloudRoute either way.
Beyond the per-dimension comparison, it helps to see the three through the migrate-then-modernize lens: what you get on day one versus what you get over the following year. This is the framing that resolves most rehost-vs-refactor arguments.
| Question | Rehost (lift-and-shift) | Replatform (lift-tinker-shift) | Refactor (re-architect) |
|---|---|---|---|
| Get off the source environment in… | Days–weeks (fastest) | Weeks | Months (slowest) |
| Savings on day one | Only if right-sized | Yes — managed-service ops savings | No — you are paying for the build |
| Risk to the exit deadline | Lowest | Low–moderate | High (couples move + rewrite) |
| Cloud-native agility gained | None yet | Some (managed services, auto-scaling) | Most (serverless/microservices) |
| Reversibility if it goes wrong | High (roll back to source) | Moderate | Low (it is new software) |
| Right role in the sequence | The exit step — do it first | The first modernize step — often during | The deep modernize step — do it later, scoped |
Situation: The engineering team had decided to refactor the entire estate into serverless and microservices as part of the AWS move — a plan that modeled out to roughly 14 months. Finance wanted a flat lift-and-shift to cut the bill fast. The two sides were deadlocked, the cloud-renewal deadline was eight months out, and nobody had scored the workloads individually or modeled whether AWS funding applied to any of it.
What CloudRoute did: Routed within 24 hours to an AWS Advanced partner with a migration + MAP track record. The partner ran a 3-week MAP Assess (AWS-funded, $0 to the customer) and scored each service on cost/effort/risk/time-to-value/payoff: ~24 services → rehost via MGN to hit the renewal deadline (right-sized on the way in); ~12 services → replatform (self-managed PostgreSQL → Aurora PostgreSQL via DMS, app tier → ECS) to shed database toil with no rewrite; and exactly 3 → refactor, flagged as scoped, separately-funded follow-ons — including the always-on batch service, which a Lambda/Fargate redesign would cut sharply. The full 40-service rewrite was retired in favor of migrate-then-modernize.
Outcome: Exited the old cloud with seven weeks to spare on the renewal deadline. Right-sized rehosts plus the Aurora/ECS replatforms landed an estimated ~31% steady-state cost reduction before the refactors even started. The three refactor candidates were sequenced as funded follow-on projects against real post-migration usage data — the batch-service redesign alone is projected to remove a five-figure annual line item. MAP funded the Assess phase and credited a large share of the Mobilize + Migrate cost against a post-migration spend commitment — net migration cost was minimal. CloudRoute's commission was paid by the partner; the customer paid $0 to CloudRoute.
assess phase: 3 weeks · services scored: ~40 · original plan: 14-month rewrite · delivered: exit in <8 months, ~31% cost cut, 3 scoped refactors · assessment cost: $0 (MAP-funded)
CloudRoute routes you to a vetted AWS partner who runs the MAP Assess (discovery + per-app scoring + disposition map + wave plan), then executes the migration with the right disposition per application. Qualifying migrations are MAP-funded — low or $0 cost. Customer pays $0 to CloudRoute. No procurement theater.