Lesson 280 · AWS Learning Path

AWS 280: The seven migration strategies

Anil Jalela · Published Apr 1, 2026 · 10 min read

Why this lesson matters

“Move it to AWS” is not one strategy. A low-value application may be retired, a regulated mainframe retained temporarily, packaged software replaced with SaaS, VMware workloads relocated, servers rehosted, databases replatformed, and a differentiating product refactored. Choosing one label for an entire portfolio wastes money and hides dependencies.

The seven Rs are retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. A strategy records the intended disposition, not an executable plan. Every decision still needs evidence, target state, dependencies, owner, economics, validation, cutover, rollback or exit, and review date.

Outcomes

By the end, you can:

• define all seven strategies and distinguish commonly confused pairs;
• choose at application or component level from business and technical evidence;
• separate migration strategy, migration pattern, tooling, and wave;
• calculate confidence and record missing evidence instead of guessing;
• include data, dependencies, licensing, security, compliance, operations, skills, and cost;
• recognize mixed strategies and temporary retain/rehost decisions;
• turn decisions into dependency groups, waves, cutover gates, rollback, and decommissioning;
• review automated recommendations without delegating accountability to a tool; and
• classify a 20-application portfolio with testable rationale.

Four different decisions

Do not write “DMS” as a strategy or “rehost” as a runbook. The same strategy can use several patterns/tools, and one application can use different strategies for web, database, file, identity, and reporting components.

Evidence required before selecting an R

Build a current-state record:

• business capability, owner, users, revenue/risk, criticality, lifecycle and roadmap;
• servers, operating systems, middleware, databases, storage, network and environments;
• inbound/outbound dependencies with protocol, frequency, volume, latency and data meaning;
• utilization and seasonal peaks over a representative period;
• RTO, RPO, availability, performance and maintenance windows;
• data classification, residency, retention, encryption and audit obligations;
• licenses, contracts, vendor support, hardware ties and renewal/end-of-support dates;
• deployment source, test automation, configuration, observability, backup and DR;
• operational team, skill/readiness, incidents, toil and technical debt; and
• current cost plus target one-time and recurring assumptions.

Discovery traffic does not explain business semantics. A rarely observed quarterly batch can be critical; a busy monitoring connection may not require co-migration. Interview owners and operators, validate CMDB data, and assign confidence to each field.

Retire

Retire decommissions or archives an application that no longer provides sufficient business value.

Good evidence includes confirmed replacement, no valid users/traffic over an appropriate business cycle, duplicate capability, unsupported/security risk, and owner/legal approval. Low CPU alone is not proof: schedulers, annual jobs, license servers, DNS, integrations, or disaster-only systems may be quiet.

Retirement plan:

1. identify data retention, legal hold, audit and retrieval requirements;
2. map inbound/outbound callers, jobs, DNS, certificates, identities and licenses;
3. notify owners/users and define a reversible disable period;
4. archive data/configuration/source/runbooks with tested retrieval;
5. block or stop service and monitor unexpected demand;
6. remove routes, DNS, secrets, agents, backups and licenses in order;
7. terminate infrastructure only after acceptance; and
8. verify billing, security inventory and CMDB closure.

Rollback during the observation window restores service from the preserved state. After destruction, recovery may be a separate archive-restore process with a longer RTO.

Retain

Retain keeps the workload in its current environment for now. Valid reasons include regulatory restrictions, hardware/latency dependency, vendor constraints, imminent retirement/replacement, insufficient evidence, frozen business period, or economics that do not justify migration.

Retain must have an owner, security/support plan, cost, risk acceptance, dependency contract, trigger, and review date. “Too hard” without a reassessment plan is backlog avoidance. Retained dependencies can force migrated applications into hybrid latency, DNS, identity, monitoring, and failure exposure.

Examples of triggers: contract renewal, hardware end-of-life, data-center exit, supported managed-service release, dependency migration, or six-month architecture review.

Rehost

Rehost moves servers/VMs largely as-is to EC2, often called lift and shift. It can accelerate data-center exit and reduce application change. It does not automatically deliver cloud-native availability, cost efficiency, patching, observability, backups, or scalability.

Evaluate architecture/instance compatibility, drivers/kernel, boot mode, disk and filesystem, IP/DNS change, identity, licenses, latency, replication bandwidth, cutover outage, agent conflicts, target subnet/security, backup, monitoring and rollback. Right-size from measured demand, not source nameplate capacity.

Typical pattern: replicate disks continuously, launch test instances in an isolated subnet, remediate boot/network issues, run functional/performance/security tests, freeze or final-sync, switch traffic, validate, retain rollback state for a defined window, then decommission source.

Rehost can be a deliberate two-step strategy: move by deadline, stabilize, then replatform/refactor. Record the modernization owner/date or the temporary state often becomes permanent.

Relocate

Relocate transfers compatible virtualized/cloud resources to another environment with minimal application change, such as moving a VMware estate into a compatible AWS-hosted VMware environment or moving supported AWS resources between accounts/VPCs.

It differs from rehost because the surrounding platform/resource is moved without converting each workload to a new compute architecture. Validate product support, network extension, IP/DNS, cluster capacity, storage/datastore, identity, licenses, backups, operational ownership, failure domains, data transfer, and eventual exit.

Relocation can meet a rapid facility deadline but preserve existing platform costs and technical debt. It is not “no change”: connectivity, control plane, support model, monitoring and disaster recovery change.

Repurchase

Repurchase replaces the current application with a commercial SaaS or different licensed product, sometimes called drop and shop.

The difficult work is business/process and data migration, not server copying:

• fit-gap requirements and customizations;
• vendor security, residency, encryption, audit, availability and exit rights;
• identity/SSO, roles, integrations, APIs, rate limits and egress;
• data mapping, cleansing, history, attachments and reconciliation;
• contract, subscription, implementation, support and price escalation;
• user training, process change and dual-running period; and
• export format, deletion proof and vendor-exit plan.

Rollback may require keeping the legacy system read-only or dual-running while reconciling writes. Do not permit uncontrolled writes in both systems.

Replatform

Replatform makes targeted optimizations without redesigning the application's core architecture. Examples include self-managed database to RDS, server-hosted application to containers, or file/object workflows to managed storage where code changes are limited.

It reduces operational work but introduces service behavior and constraints. Validate engine/version/extension compatibility, parameter/feature differences, connection endpoints, maintenance, backup/restore, HA/failover, quotas, monitoring, IAM/encryption, performance, licensing and cost.

A database replatform needs schema/object assessment, full load plus change replication, data validation, performance tests, cutover lag gate, endpoint change, rollback/forward-recovery and source retention. “Managed” does not eliminate application testing or shared-responsibility duties.

Refactor or re-architect

Refactor materially changes architecture/code to obtain agility, scale, resilience, managed/serverless operation, or new business capability. It may split a monolith, redesign state, adopt event-driven flows, change data stores, or automate delivery.

This is usually the highest-complexity strategy. Large migrations often move first with rehost/replatform/relocate and modernize later, unless refactoring is required for the business outcome or source cannot run on target.

Define domain boundaries, data ownership/consistency, API/event contracts, idempotency, deployment, observability, security, performance, resilience and incremental transition. Use patterns such as strangler only with routing, data synchronization, rollback and coexistence evidence. Avoid a “big bang rewrite” with no incremental value or parity test.

Compare the seven

Speed depends on evidence and dependency complexity; the table is a tendency, not a promise.

Mixed strategy example

For an order platform:

• retire an unused reporting server;
• retain a mainframe fulfillment dependency for 12 months;
• rehost a vendor-locked batch worker;
• repurchase CRM capability as SaaS;
• replatform PostgreSQL to RDS;
• refactor order events into managed messaging; and
• relocate a supporting VMware appliance.

The portfolio record can name the application-level strategy as “replatform-led,” but component decisions and dependencies remain explicit. Coexistence needs hybrid DNS, routes, identity, data synchronization, latency, monitoring and incident ownership.

Decision method and confidence

Score options only after mandatory gates:

1. Is retirement safe and approved?
2. Is a replacement/SaaS aligned to business capability?
3. Must it remain due to an explicit constraint?
4. Can the platform relocate compatibly?
5. Can it rehost within deadlines/support?
6. Which limited managed-service changes improve outcome?
7. Is refactoring justified and deliverable?

For each decision record:

Low confidence does not mean choose rehost automatically. It means perform detailed assessment before commitment.

From strategy to wave

Dependency groups contain applications/components that must move together. Waves contain manageable dependency groups selected by complexity, business priority, environment, team capacity, bandwidth, platform readiness and change windows.

Early waves should be small, lower risk and useful for learning. Avoid placing every simple app first if a hidden shared database then blocks later work. Remove shared-service “noise” from communication maps but document real identity, DNS, backup and monitoring dependencies.

Each wave includes design, target/landing-zone readiness, tooling and replication, cutover/rollback runbook, functional/data/performance/security/operations tests, business acceptance, hypercare, source decommission and lessons fed into later waves.

Twenty-application exercise

Classify:

1. unused intranet with legal records;
2. stable Linux web app under data-center exit deadline;
3. Oracle app needing unsupported extensions;
4. VMware estate with short facility lease;
5. custom CRM with available SaaS replacement;
6. differentiating monolith needing weekly releases;
7. batch app with mainframe dependency;
8. unsupported Windows application with no owner;
9. PostgreSQL app suitable for managed database;
10. file-transfer server with partner IP allowlists;
11. low-latency factory control tied to hardware;
12. seasonal public API;
13. duplicate reporting platform;
14. licensed appliance available from Marketplace;
15. analytics warehouse with residency limits;
16. container-ready stateless service;
17. application scheduled for merger replacement;
18. identity directory shared by 80 applications;
19. archive search used twice yearly; and
20. order system with seven mixed components.

There is no score for choosing seven different labels. There is a score for evidence. For each application submit all decision-record fields, at least two rejected alternatives, confidence gaps, dependency group, wave readiness, cutover/rollback or retire/retain exit, and review trigger.

Tool recommendations are evidence, not authority

Discovery, Migration Evaluator, Migration Hub, database/schema tools, and AWS Transform reports can accelerate inventory or recommendations. Their output reflects collected data, supported rules, scan period and assumptions. Validate ownership, hidden dependencies, licensing, compatibility, business process, security and data duties with humans.

AWS Transform can produce R-strategy evidence for supported VMware assessment scenarios. Do not enable a service, upload estate data, create artifact storage, or install tooling merely to complete this no-create lesson. Review current identity, Region, permissions, encryption, data handling and pricing before any separately approved live assessment.

Cost, risk, and acceptance

Compare total cost over a stated period:

• source run/contract/facility and avoided costs;
• assessment, tool, transfer, dual-run and project labor;
• target compute/storage/database/network/security/log/support;
• licenses, SaaS subscription and escalation;
• modernization development and operational training;
• outage, rollback, delayed decommission and compliance risk; and
• exit/portability/data retrieval.

Acceptance must include business transaction, data count/reconciliation, performance under representative load, security/compliance, backup/restore/DR, monitoring/alerts, operations/runbook/on-call, billing/tags, and source decommission criteria.

Diagnose poor strategy decisions

Lesson acceptance

The lesson is complete only when the learner can:

• define and contrast all seven strategies accurately;
• separate strategy, pattern, tool and wave;
• collect business, infrastructure, dependency, security, operational and economic evidence;
• classify all 20 applications and mixed components with confidence;
• reject at least two alternatives per application using evidence;
• identify temporary decisions and enforce review/exit triggers;
• group dependencies into executable waves with readiness gates;
• define cutover, rollback, acceptance, hypercare and source decommission;
• model full lifecycle cost, risk, licensing and compliance; and
• attest that no AWS or production resource changed.

Official sources

• About the seven migration strategies
• Application prioritization and migration strategy
• Detailed portfolio discovery
• Portfolio analysis and migration planning
• Wave planning
• AWS Transform R-strategy report