# Moving from on-site VMware to AWS in stages

*Cloud & Edge · 7 min read · Updated 2026-10-07 · https://www.jbrichardson.com/resources/move-vmware-to-aws*

**Short answer:** Move from on-site VMware to AWS in waves, not all at once. Inventory every server and dependency, build a landing zone with separate accounts and non-overlapping networks, connect with a VPN, pilot a low-risk system, then migrate in waves using replication with a tested rollback. Right-size and decommission only after a restore test passes.

Most businesses do not need to move everything to the cloud at once, and the ones that try usually pay for it in downtime and surprise bills. A staged migration lets you prove each step, keep a rollback path and learn what your workloads really need.

## Start with an inventory, not a destination

List every virtual machine with its owner, operating system, CPU and memory use over a few weeks, storage, licences and what it talks to. Dependencies decide the order you can move things in, so map them before you pick a date.

Then decide a strategy for each workload. The usual choices are rehost (move as is), replatform (small changes such as a managed database), refactor (rebuild for the cloud), repurchase (replace with SaaS), retire and retain. Most estates are a mix, and a good share of servers turn out to be candidates for retire.

## Build the landing zone first

- Separate AWS accounts for production, non-production and shared services, managed with AWS Organizations.
- Single sign-on with MFA through IAM Identity Center. No long-lived access keys for people.
- VPC address ranges that do not overlap your on-site networks. This is painful to fix later.
- Logging on from day one: CloudTrail, AWS Config and flow logs to a locked-down log account.
- Budgets and cost alerts before the first workload lands.

## Connect the networks

Start with a Site-to-Site VPN. It is quick to set up and good enough for a pilot. If you end up with steady, high-volume traffic or strict latency needs, add AWS Direct Connect. Use a Transit Gateway once you have more than a couple of VPCs, and make sure DNS resolves in both directions (Route 53 Resolver endpoints handle this).

## Move in waves

1. Wave 0: a low-risk pilot, such as a test system, to prove the network, access and monitoring.
2. Replicate servers continuously with AWS Application Migration Service, then run a test launch before the real cutover.
3. Move databases with AWS Database Migration Service or native replication, and keep the source read-only until you are sure.
4. Cut over in a planned window with a written rollback plan and an owner for each step.
5. Repeat in waves, moving independent systems first and tightly coupled groups together.

## After the move

Right-size instances once you have a month or two of real usage, then buy Savings Plans for the steady part of the load. Turn on AWS Backup, tag everything with an owner and cost centre, and only then decommission the old hosts. Keep the old environment until a full backup-and-restore test has passed in AWS.

> **Keep your exit path open** Define the landing zone and each workload in Terraform from the start. It makes environments repeatable, reviewable and portable, and it is the best defence against being locked into decisions made in a console.

---
Published by JBRichardson LLC, 1603 North Olden Ave, Ewing, NJ 08638. Phone (609)-564-3016. https://www.jbrichardson.com/contact