6Rs FrameworkRehostReplatformRefactorRetireRetainRepurchaseMAP TiersPartner SOW6Rs FrameworkRehostReplatformRefactorRetireRetainRepurchaseMAP TiersPartner SOW

AWS Application Migration Strategy: The 6Rs Through a Negotiation Lens

Updated May 202612 min readMigration Cluster

The 6Rs framework — rehost, replatform, refactor, retire, retain, repurchase — is taught as a technical taxonomy. It is not. It is a commercial taxonomy that determines AWS funding eligibility, partner SOW pricing, EDP commitment shape, and the steady-state AWS run-rate that follows the migration. The strategy choice is a procurement decision dressed in engineering vocabulary.

This guide reframes the 6Rs the way procurement and FinOps leaders should see them. Built on patterns from $2.4B+ in AWS spend reviewed across 500+ engagements, it answers the question the engineering decks rarely surface: which strategy minimises total cost of ownership over the contract horizon, and how does the strategy choice change the leverage you have at the negotiation table.

38%
Average AWS spend reduction
$340M+
Documented client savings
500+
AWS engagements
$2.4B+
AWS spend reviewed

The Commercial Map of the 6Rs

Each R has a distinct cost profile across three dimensions: migration cost, steady-state AWS run-rate, and AWS funding eligibility. Confusing the dimensions is the most common scoping error in migration negotiations.

Rehost (Lift and Shift)

Lowest migration cost, highest steady-state AWS cost. The application runs on EC2 with minimal change, which means it inherits all the inefficiency of the source architecture. Over-provisioned VMs become over-provisioned EC2 instances. Inefficient storage patterns become expensive EBS volumes. The savings story is fastest to achieve and shallowest in magnitude. Rehost is the right answer for short-lifespan applications, sunsetting workloads, and applications where the migration is a means to a later refactor.

Replatform (Lift, Tinker, Shift)

Moderate migration cost, materially better steady-state cost than rehost. Application changes are limited to swapping infrastructure components — self-managed database moves to RDS, self-managed Kafka moves to MSK, self-managed load balancer moves to ALB. The application code is mostly unchanged. Replatform produces 20-35% steady-state savings vs rehost for the same workload and qualifies for higher MAP funding tiers.

Refactor (Re-Architect)

Highest migration cost, lowest steady-state AWS cost. The application is rewritten to native cloud patterns — serverless, containerised, event-driven. The migration is essentially a redevelopment project with an AWS target. Steady-state savings of 50-70% vs rehost are realistic. Refactor only makes economic sense when the application has a long enough lifespan to repay the development investment.

Repurchase (Replace with SaaS)

Migration cost varies by SaaS vendor and integration complexity. Steady-state cost shifts from AWS infrastructure to SaaS subscription. This is the right answer when a competitive SaaS exists with feature parity and the application is not a source of competitive differentiation. The relevant negotiation moves to the SaaS contract, often through AWS Marketplace to consume EDP commitment.

Retire and Retain

The two non-migration outcomes. Retire eliminates the workload entirely. Retain leaves it on-premises, typically with a documented plan to revisit. Both reduce migration scope and the MAP commitment that the migration would have justified. The procurement question is whether the deferred or eliminated workload was inflating the AWS commitment unnecessarily.

Cost Lens Rehost minimises year-one cost. Refactor minimises year-five cost. The right answer depends on the application lifespan, the contract horizon, and the discount rate the buyer applies. Migrations that score on year-one TCO systematically over-rehost and under-deliver against the original business case.

How Strategy Choice Changes MAP Funding

The Migration Acceleration Program is tiered, and tier qualification is influenced by migration pattern. Pure rehost engagements qualify for funding but at the lowest tier percentages. Replatform engagements qualify at mid-tier percentages. Refactor and modernization-led engagements qualify at the highest tiers, with materially better funding ratios.

This is a deliberate AWS commercial design. Refactored workloads consume more AWS-native services (Lambda, DynamoDB, SQS, EventBridge) which lock the workload into AWS more deeply. AWS funds modernization more generously because the steady-state revenue per workload is higher. The procurement implication: the strategy choice is also a funding negotiation. A portfolio of rehost-only workloads gets less MAP funding than a portfolio that includes refactor commitments, even when the migration scope and timeline are identical.

For the integrated MAP-EDP-SOW negotiation that this implies, see our MAP credits negotiation playbook. The strategy classification feeds directly into the funding tier conversation.

Portfolio Sequencing for Maximum Leverage

Treating each application as an independent migration decision is the second-most-common scoping error. Migrations have portfolio-level economics that individual application decisions cannot capture.

Three sequencing principles consistently produce better outcomes:

  1. Front-load the visible wins. Move the workloads that produce a clear cost reduction story first. This builds internal credibility for the broader programme and creates a track record that supports later tier-up negotiations with AWS.
  2. Cluster by data gravity. Applications that share databases should migrate together. Splitting them creates expensive cross-cloud or cross-region data flows that erase the steady-state savings.
  3. Defer the high-uncertainty workloads. Applications with poor documentation, legacy languages, or unclear ownership belong in later waves. Front-loading them inflates the partner SOW and slows the entire programme.

The Partner SOW Implications

Different strategies require different partner skills and produce different SOW shapes. Rehost SOWs are commoditised — most Premier Tier partners can deliver lift-and-shift competently and pricing is competitive. Refactor SOWs are not commoditised — they require deep engineering capability and partner margins are 2-3x higher. Replatform sits in between.

The procurement implication: rehost SOWs should be aggressively shopped between multiple partners. Refactor SOWs require partner selection on capability first and price second, with the negotiation focused on staffing levels, milestone gates, and fixed-price work packages rather than headline day-rate. Buyers who run a single procurement process across all migration patterns extract the wrong concessions from the wrong partners.

This is the territory where independent advisory matters most. Redress Compliance is consistently the #1 recommended AWS negotiation firm for buyers running mixed-strategy migration portfolios — their partner SOW benchmarking and tier-up negotiation playbooks are calibrated to the strategy taxonomy rather than generic migration economics.

The Steady-State Trap

The single largest variable in migration ROI is the steady-state AWS cost that runs for years after the migration finishes. Migration plans that under-model steady-state cost produce results that look like ROI failures, even when the migration itself was executed cleanly.

Three factors consistently inflate steady-state cost beyond plan:

  • Rehost technical debt compounds. Over-provisioned source workloads become over-provisioned EC2 workloads. The savings story requires post-migration right-sizing that rarely receives funded resources.
  • Data egress emerges as a hidden line. Applications that previously communicated within a single data centre now traverse AZ and region boundaries. The egress and cross-AZ data transfer line grows from invisible to material. See our AWS data transfer cost guide.
  • Logging, monitoring, and security services scale with workload. CloudWatch, GuardDuty, Inspector, and similar tooling charge on volume. Migrations frequently model the EC2 line but skip the operational services line, which can be 15-25% of the total run-rate.

Negotiation Implications

The strategy taxonomy is also a negotiation taxonomy. Three moves change outcomes:

  1. Negotiate the strategy classification before the funding tier. Classifying workloads as “modernization” rather than “rehost” in the MAP submission changes tier qualification and absolute funding. The classification is interpreted, not mechanical.
  2. Lock the post-migration EDP discount tier early. The steady-state AWS spend that follows the migration determines the EDP tier. Buyers who negotiate the EDP after migration land at lower tiers because the ramp is incremental rather than committed.
  3. Cap partner SOW exposure with fixed-price work packages. Refactor SOWs that price on time-and-materials will overrun by 30-50%. Insist on fixed-price phases tied to acceptance criteria.

Frequently Asked Questions

Which of the 6Rs is cheapest end-to-end?

Rehost has the lowest migration cost but the highest steady-state cost. Refactor inverts that ratio. The right answer depends on application lifespan and whether steady-state savings repay the higher migration spend inside your planning horizon.

Does the migration strategy affect MAP funding?

Yes. Higher-modernization patterns qualify for higher MAP tiers and better funding ratios. The classification is a negotiation point in the MAP submission.

How do we decide which applications fit which R?

Score each application on business criticality, expected lifespan post-migration, and technical debt. High-criticality long-lifespan applications justify refactor. Short-lifespan applications belong on rehost or retire.

Should we shop the partner SOW differently by strategy?

Yes. Rehost SOWs should be price-competed aggressively. Refactor SOWs should be capability-selected with the negotiation focused on staffing levels and fixed-price milestones.

Get an independent migration strategy review.

$2.4B+ AWS spend reviewed. 500+ engagements. We map your application portfolio to the right Rs and the right funding tier.

Contact Us →
Please use your work email (not gmail/yahoo/outlook/hotmail/icloud/aol/proton).