AWS 7R Migration Strategies: A Decision Framework for Engineering Teams

Most AWS migration projects don't fail because of technical complexity. They fail because teams treat migration as a single activity rather than a set of distinct strategies applied to different workloads.

AWS defines seven migration strategies — the 7Rs — that determine how each application moves to the cloud. The decision of which strategy applies to which workload has more impact on project cost, timeline, and outcome than any architectural choice you'll make after. Yet in practice, most teams default to "lift-and-shift everything" without evaluating whether that's appropriate.

This article presents a practitioner's framework for classifying workloads into the 7Rs, based on delivering 50+ AWS migrations across fintech, SaaS, healthcare, and e-commerce.

The 7R Strategies

Retire

Not every workload deserves migration. During discovery, you will invariably find applications that are redundant, unmaintained, or replaceable. In a typical enterprise portfolio of 20–40 applications, 10–20% qualify for retirement.

Decision criteria: No active users, duplicate functionality already covered by another system, or maintenance cost exceeds business value.

Common mistake: Teams skip this step because retiring applications requires stakeholder conversations. The result is migrating dead applications that consume compute budget indefinitely.

Retain

Some workloads shouldn't migrate in this wave. Applications with deep hardware dependencies, pending end-of-life within 12 months, or complex regulatory constraints that require legal review before cloud deployment are candidates for retention.

Decision criteria: High migration complexity combined with low business urgency, or external constraints that prevent cloud deployment within the project timeline.

Retain is not "never migrate." It's "not now." Document these workloads with a future migration path and trigger conditions.

Rehost (Lift-and-Shift)

Moving applications to EC2 or containers without code modifications. AWS Application Migration Service (MGN) automates this by continuously replicating servers and orchestrating cutover with minutes of downtime.

Decision criteria: Application has a short remaining lifespan (1-2 years), speed of migration matters more than optimization, or the application is a black box with no available source code.

Timeline: Days to weeks per workload.

Trade-off: You gain cloud elasticity and pay-as-you-go pricing immediately, but you inherit all existing architectural inefficiencies. A poorly designed monolith on-premises becomes a poorly designed monolith on EC2.

Relocate

Hypervisor-level migration, primarily for VMware workloads moving to VMware Cloud on AWS. The OS, application, and configuration remain untouched.

Decision criteria: Large VMware estate, tight data center exit deadline, and applications that cannot tolerate any configuration change.

Replatform

Migration with targeted adaptations to managed services. The application architecture stays intact, but you replace self-managed infrastructure components with AWS equivalents:

Decision criteria: Application is well-structured but operationally expensive. The team spends significant time on database maintenance, patching, backup verification, or scaling.

Timeline: 2-4 weeks additional per workload compared to rehost.

Trade-off: Moderate additional effort (schema compatibility testing, connection string changes) in exchange for a 40-60% reduction in ongoing operational cost. For most mid-complexity applications, replatforming represents the optimal balance between migration effort and long-term benefit.

Refactor (Re-Architect)

Rebuilding applications for cloud-native patterns: microservices decomposition, containerization (ECS/EKS), serverless (Lambda), event-driven architecture (EventBridge, SQS, SNS, Step Functions).

Decision criteria: The application is a core business asset that needs capabilities the current architecture cannot deliver — true horizontal scaling, independent service deployments, multi-region active-active, or zero-downtime deployments.

Timeline: Months. Budget accordingly.

Trade-off: Highest upfront investment, but delivers the best long-term results in terms of deployment velocity, fault isolation, and scaling capability. Reserve this for 2-3 applications maximum in a migration portfolio.

Repurchase

Replacing custom-built software with a commercial SaaS product. The application doesn't move to AWS; it moves to a vendor.

Decision criteria: The in-house application solves a problem that is not a core competency and commercially available alternatives have matured to cover your requirements. Common candidates: CRM, HR systems, monitoring, project management.

The Decision Framework

Classification should happen during the assessment phase, before any infrastructure work begins. For each workload, evaluate four dimensions:

1. Business Value

How critical is this application to revenue generation or core operations?

• High: Core product, customer-facing, revenue-generating
• Medium: Internal operations, supports core processes
• Low: Legacy, rarely used, or duplicate functionality

2. Technical Complexity

How difficult is it to migrate given current architecture, dependencies, and state management?

• High: Stateful, tightly coupled, hardware dependencies, proprietary protocols
• Medium: Standard web application with database, some external integrations
• Low: Stateless, containerizable, standard protocols

3. Team Capacity

Does your engineering team have the skills and bandwidth to support a complex migration approach?

• High capacity: Can support re-architecting alongside other work
• Limited capacity: Can handle replatforming with some external support
• Minimal capacity: Rehost or retain is the only realistic option

4. Time Constraint

How quickly must this workload be operational on AWS?

• Immediate (weeks): Data center exit, contract expiry
• Standard (1-3 months): Planned migration within a program
• Flexible (3-6 months): Can wait for deeper optimization

Mapping Dimensions to Strategy

A Practical Example

Consider a portfolio of 15 applications for a mid-size SaaS company:

┌─────────────────────────────────────────────────────┐
│ RETIRE (3)                                          │
│  - Legacy admin panel (replaced by new one 2024)    │
│  - Internal wiki (moved to Confluence)              │
│  - Prototype service (never went to production)     │
├─────────────────────────────────────────────────────┤
│ RETAIN (1)                                          │
│  - Hardware security module integration             │
│    (requires legal review for cloud deployment)     │
├─────────────────────────────────────────────────────┤
│ REHOST (4)                                          │
│  - Backoffice tools (low traffic, stable)           │
│  - Legacy reporting engine (EOL in 18 months)       │
│  - Monitoring collector agents                      │
│  - Staging environment clone                        │
├─────────────────────────────────────────────────────┤
│ REPLATFORM (5)                                      │
│  - Main API (PostgreSQL → RDS, cron → Lambda)       │
│  - Worker services (EC2 → ECS Fargate)              │
│  - File processing pipeline (S3 + Lambda)           │
│  - Authentication service (→ElastiCache for sessions│
│  - Notification service (→ SES + SQS)               │
├─────────────────────────────────────────────────────┤
│ REFACTOR (1)                                        │
│  - Core product platform (monolith → microservices) │
├─────────────────────────────────────────────────────┤
│ REPURCHASE (1)                                      │
│  - Custom CRM (→ HubSpot)                           │
└─────────────────────────────────────────────────────┘

This distribution — 20% retire, 7% retain, 27% rehost, 33% replatform, 7% refactor, 7% repurchase — is representative of what I see in practice. The replatform bucket is almost always the largest.

Migration Tooling Alignment

Each strategy maps to specific AWS tooling:

AWS Migration Hub provides a unified tracking dashboard across all strategies. For database migrations specifically, AWS Database Migration Service (DMS) handles both homogeneous and heterogeneous migrations with continuous replication (CDC), enabling near-zero-downtime cutovers.

Common Anti-Patterns

"Rehost everything, optimize later." Teams that plan to rehost first and replatform in a second phase rarely execute phase two. The urgency disappears once applications are running, and the team moves to other priorities. If replatforming is the right strategy, do it during migration.

"Refactor everything for cloud-native." The opposite extreme. Not every application needs microservices. A well-structured monolith running on ECS Fargate can serve thousands of requests per second with simpler operations than a distributed system.

"One strategy for all workloads." Every application in the portfolio has different characteristics. The decision framework exists because one size does not fit all.

Conclusion

The 7R classification exercise takes 3-5 days for a typical portfolio. It requires involvement from engineering leads, product owners, and sometimes finance (for retire/repurchase decisions). The output - a workload-by-workload strategy map - becomes the foundation for accurate timeline estimates, resource planning, and budget allocation.

Without it, you're building infrastructure for workloads that might not need to exist.

For a comprehensive breakdown of migration costs, the full 6-phase delivery process, and AWS tooling details, see my complete AWS cloud migration guide.