Migrating a handful of servers to AWS is easy. Migrating an enterprise portfolio of hundreds of applications — with dependencies, compliance constraints, and zero downtime tolerance — is a program, not a project. The difference between success and a stalled migration is a clear strategy per application and the right tools for each phase.
This guide covers the 7 Rs migration framework, the migration lifecycle, and the AWS tools that turn "we should move to cloud" into a tracked, executable plan.
The Migration Lifecycle
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ ASSESS │──→│ MOBILIZE │──→│ MIGRATE │──→│MODERNIZE │
│ │ │ │ │ │ │ │
│ Discover │ │ Landing │ │ Move │ │ Optimize │
│ portfolio │ │ zone, │ │ workloads│ │ refactor │
│ + business│ │ pilot, │ │ in waves │ │ to cloud │
│ case │ │ skills │ │ │ │ native │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
Most failed migrations skip Assess (no dependency mapping) or Mobilize (no landing zone) and jump straight to moving servers. Don't.
The 7 Rs: Strategy Per Application
Every application gets one of seven dispositions. This is the core decision.
┌────────────────────────────────────────────────────────────────┐
│ 7 Rs MIGRATION STRATEGIES │
├────────────┬─────────────────────────────────────────────────────┤
│ Retire │ Decommission — no longer needed │
│ Retain │ Keep on-premises (for now) — not ready/not worth it │
│ Relocate │ Move VMware as-is (VMware Cloud on AWS / EVS) │
│ Rehost │ Lift-and-shift (MGN) — move, then optimize │
│ Replatform │ Lift-tinker-shift (e.g., DB → RDS, self-mgd → managed)│
│ Repurchase │ Drop and shop (move to SaaS) │
│ Refactor │ Re-architect for cloud-native (microservices, serverless)│
└────────────┴─────────────────────────────────────────────────────┘
Choosing the Right R
| Strategy | Effort | When to Use | Example |
|---|---|---|---|
| Retire | None | App is unused or redundant | Legacy reporting tool nobody opens |
| Retain | None | Compliance/latency keeps it on-prem, or mainframe not ready | Regulated system pending modernization |
| Relocate | Low | VMware estate, want fast exit from data center | vSphere workloads → EVS / VMware Cloud |
| Rehost | Low | Speed matters, optimize later | App server → EC2 via MGN |
| Replatform | Medium | Small changes yield big managed-service wins | Self-managed MySQL → RDS/Aurora |
| Repurchase | Medium | Commercial SaaS exists | On-prem CRM → Salesforce |
| Refactor | High | Strategic app needing scale/agility | Monolith → microservices on ECS/Lambda |
The Pragmatic Reality
Most large migrations are 70% Rehost/Relocate, 20% Replatform, 10% Refactor. You cannot refactor everything — it's too slow and expensive. Rehost first to exit the data center (hit the deadline), then modernize the applications that justify the investment. This is the "move then improve" pattern.
Phase 1: Assess
Discovery — You Can't Migrate What You Can't See
AWS Application Discovery Service collects server configs, performance metrics, and — critically — network dependencies from your on-premises environment.
Two collection methods:
| Method | How | Best For |
|---|---|---|
| Agentless (OVA appliance) | VM in vCenter, collects VM inventory | VMware environments |
| Agent-based | Install agent on each server | Detailed process + dependency data |
Discovery answers: What do we have? How is it used? What talks to what? (Dependency mapping prevents the classic "we migrated the app but forgot it calls a database still on-prem" disaster.)
Migration Evaluator / Business Case
Before moving anything, build the business case:
- Current TCO (hardware, licensing, data center, staff)
- Projected AWS cost (right-sized, with Savings Plans)
- Migration cost + timeline
- Risk assessment per application
Phase 2: Mobilize
Build the Foundation
Before migrating workloads, establish:
- Landing Zone — multi-account structure, guardrails, networking (Control Tower / Landing Zone Accelerator)
- Network connectivity — Direct Connect or Site-to-Site VPN to on-premises
- Security baseline — GuardDuty, Security Hub, IAM Identity Center
- Migration pilot — migrate 1-3 low-risk applications to validate the process and build team skills
Migration Waves
Group applications into waves based on:
- Dependencies — migrate tightly-coupled apps together
- Complexity — start simple, build confidence
- Business criticality — non-critical first, crown jewels later
- Team capacity — realistic parallel workload
Phase 3: Migrate — The Tools
AWS Migration Hub: Single Pane of Glass
Migration Hub is the command center — it tracks migration status across all tools and applications in one dashboard.
┌─────────────────────┐
│ Migration Hub │
│ (tracks everything) │
└──────────┬──────────┘
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ App Discovery│ │ MGN │ │ DMS │
│ (assess) │ │ (rehost) │ │ (databases) │
└──────────────┘ └──────────────┘ └──────────────┘
AWS Application Migration Service (MGN) — for Rehost
The primary lift-and-shift tool. Continuous block-level replication from source servers to AWS:
- Install MGN agent on source servers (or agentless for vCenter)
- Continuous replication to a staging area in AWS (low-cost)
- Launch test instances — validate without affecting source
- Cutover — final sync, launch production instances, redirect traffic
Key benefit: Minimal downtime (minutes at cutover), continuous sync means you can test repeatedly before committing.
AWS Database Migration Service (DMS) — for Databases
Migrates databases with minimal downtime, including heterogeneous migrations (Oracle → PostgreSQL, SQL Server → Aurora):
- Homogeneous (same engine): direct migration
- Heterogeneous (different engine): use Schema Conversion Tool (SCT) first to convert schema/code, then DMS for data
- CDC (Change Data Capture): keeps source and target in sync during migration for near-zero downtime
Tool Selection by Strategy
| Strategy | Primary Tool |
|---|---|
| Rehost | Application Migration Service (MGN) |
| Relocate (VMware) | VMware Cloud on AWS / Amazon EVS |
| Replatform (database) | DMS + Schema Conversion Tool |
| Refactor | Manual re-architecture + CI/CD |
| Mainframe | AWS Mainframe Modernization service |
Phase 4: Modernize
Once workloads are on AWS, modernize the ones that justify it:
| From | To | Benefit |
|---|---|---|
| EC2 app servers | Containers (ECS/EKS) or Lambda | Scaling, cost, agility |
| Self-managed databases | RDS/Aurora/DynamoDB | Managed ops, auto-scaling |
| Monolith | Microservices | Independent deployment, scaling |
| Batch on EC2 | Step Functions + Lambda | Serverless, pay-per-use |
| File shares | S3 + EFS/FSx | Durability, cost tiers |
| Data warehouse | Redshift / Lakehouse (Iceberg) | Modern analytics |
AI-Assisted Modernization (2026)
AWS now offers AI-agent-driven modernization — particularly for mainframes. Specification-driven approaches use AI agents to analyze legacy code (COBOL), extract business logic, and generate modern microservices. This dramatically reduces the cost of the hardest migrations.
Migration Patterns
Pattern 1: The Strangler Fig (Gradual Refactor)
Instead of a big-bang rewrite, incrementally replace pieces of a monolith:
Legacy Monolith
│
├── Route new feature → New microservice (AWS)
├── Route feature B → New microservice (AWS)
└── (monolith shrinks over time until retired)
New functionality goes to cloud-native services; the monolith gradually "strangled" until it's gone. Lower risk than big-bang.
Pattern 2: Rehost Then Replatform
On-prem → MGN rehost to EC2 (hit the data center exit deadline)
→ then: migrate DB to RDS (replatform)
→ then: containerize app (modernize)
Get out of the data center fast, improve incrementally. Avoids the trap of trying to perfect everything before moving.
Pattern 3: Database-First (for data-gravity apps)
1. DMS replicate database to AWS (CDC keeps in sync)
2. Migrate application servers (MGN)
3. Cutover: point apps to AWS database, stop CDC
Common Migration Mistakes
| Mistake | Impact | Fix |
|---|---|---|
| No dependency mapping | Break apps that call un-migrated services | Application Discovery Service first |
| Refactor everything | Migration never finishes, budget blown | Rehost 70%, refactor selectively |
| No landing zone first | Ungoverned sprawl, security gaps | Build landing zone in Mobilize phase |
| Lift-and-shift then stop | Pay for un-optimized EC2 forever | Plan modernization backlog post-migration |
| Big-bang cutover | High-risk, hard to roll back | Wave-based migration with pilots |
| Ignoring licensing | Bring problematic licenses to cloud | Assess BYOL vs license-included |
| No rollback plan | Stuck if cutover fails | MGN test instances + documented rollback |
The Migration Readiness Checklist
ASSESS
☐ Application Discovery Service deployed
☐ Dependency mapping complete
☐ 7 Rs disposition assigned per app
☐ Business case / TCO analysis done
MOBILIZE
☐ Landing zone deployed (Control Tower / LZA)
☐ Direct Connect / VPN to on-premises
☐ Security baseline (GuardDuty, Security Hub)
☐ Pilot migration completed + lessons captured
☐ Migration waves planned
MIGRATE
☐ Migration Hub tracking configured
☐ MGN for rehost workloads
☐ DMS + SCT for database migrations
☐ Test instances validated before cutover
☐ Rollback procedure documented per wave
MODERNIZE
☐ Post-migration optimization backlog
☐ Right-sizing (Compute Optimizer)
☐ Savings Plans purchased
☐ Modernization candidates prioritized
Summary
Migrating an enterprise to AWS is a disciplined program:
- Assess — Discover the portfolio, map dependencies, assign a strategy (one of the 7 Rs) per app, build the business case.
- Mobilize — Landing zone, connectivity, security baseline, pilot migration, wave planning.
- Migrate — Migration Hub as command center; MGN for rehost, DMS+SCT for databases, EVS for VMware.
- Modernize — Optimize and refactor the applications that justify the investment.
The strategic truth: You can't refactor everything, and you shouldn't try. Rehost the bulk to exit the data center on time, then modernize selectively where it delivers business value. "Move then improve" beats "perfect then move" every time.
Alpesh Kumbhare is an AWS Architect at Atos, specializing in cloud migration and AWS infrastructure automation. Connect on LinkedIn.
Top comments (0)