# VMware to AWS migration path decision matrix

Pick **Relocate (EVS)**, **Rehost (MGN)**, or **Replatform (native EC2/containers)** by
VM count, VMware dependency, and how fast you must exit the data center.

> Reflects **July 2026**: Amazon EVS GA (Aug 2025) in 19 commercial Regions per AWS EVS
> FAQs; AWS Application Migration Service default **150** concurrent replicating servers
> (support increase available); VCF **5.2.1** on i4i.metal with BYOL license portability.

## 1. Primary decision

| Question | If YES → | If NO → |
|----------|----------|---------|
| Must preserve vSphere ops model this quarter? | **Amazon EVS** (Relocate) | Continue ↓ |
| Can change hypervisor with block-level replication? | **AWS MGN** (Rehost to EC2) | Continue ↓ |
| Application ready for containers / managed services? | **Replatform** (ECS/EKS/RDS) | Hybrid wave plan |

**Opinionated default:** **MGN for lift-and-shift majority**, **EVS for VMware-only estates**
that cannot retool hypervisor skills before DC exit deadline, **native replatform for net-new
or refactor-ready apps** — not all three at once in wave 1.

## 2. Path comparison

| Dimension | Amazon EVS | AWS MGN → EC2 | Native replatform |
|-----------|------------|---------------|-------------------|
| Hypervisor change | None (vSphere) | Yes (KVM/Xen on EC2) | Often none (PaaS) |
| App changes | None | Minimal (OS drivers) | Moderate–high |
| Cutover style | HCX vMotion / bulk | Test + cutover instance | Blue/green deploy |
| AWS service integration | VPC-level | Native EC2/RDS | Full managed stack |
| Best for | Broadcom renewal pressure, vSphere skills | General VM estate | SaaS, container-ready |
| Typical timeline | Weeks (same ops model) | 8–16 weeks per wave | Quarters per app |

## 3. When NOT to choose EVS

| Situation | Prefer instead |
|-----------|----------------|
| < 30 VMs, no vSphere-specific tooling | MGN → right-sized EC2 |
| GovCloud / air-gapped (verify EVS Region list) | MGN or Outposts until EVS available |
| Goal is container-first in 6 months | MGN short-term + replatform backlog |
| Stretched vSAN cross-AZ HA required day 1 | Separate EVS clusters + SRM (not stretched vSAN GA) |

## 4. MGN capacity planning

- Default **Max Active Source Servers**: **150** (request increase with migration plan via AWS Support)
- Max **200** source servers per replication job
- Migrate in **waves** to avoid EC2/EBS quota throttling during staging subnet replication
- Plan cutover windows: MGN **blocks writes** during cutover launch — coordinate with app owners

## 5. Wave planning

Use [wave-plan-worksheet.csv](./wave-plan-worksheet.csv) — score each VM:
dependency tier, RTO, VMware-only tooling, refactor readiness.

## Related posts

- [VMware migration path decision guide](/blog/aws-vmware-migration-evs-mgn-native-decision-guide-2026/)
- [Amazon EVS product deep-dive](/blog/amazon-elastic-vmware-service-evs/)
- [Migration readiness checklist](/blog/aws-cloud-migration-readiness-assessment-checklist/)
- [Data center exit program](/blog/data-center-exit-large-scale-aws-migration-program/)