VMware Data Center to AWS: A Workload-by-Workload Migration Strategy

Customer Context

An industrial manufacturing organization approached an infrastructure renewal with 186 VMware virtual machines, 72 TB of data, and more than 40 applications. Order processing depended on warehouse interfaces, scheduled integrations, identity services, and plant connectivity. Moving every VM unchanged would preserve avoidable capacity; moving every application at once would concentrate production risk. The customer remains anonymous for confidentiality.

AAIC’s work connected a decision for each workload to an executable transition sequence and a cost comparison that included the systems remaining on premises.

Establish the Estate Before Choosing Destinations

Discovery reconciled virtualization inventory with utilization, storage growth, application ownership, licensing, backup coverage, and application dependencies. Maintenance windows, batch schedules, latency constraints, and unsupported software informed the decisions. Plant-facing dependencies remained explicit rather than disappearing from the cloud estimate.

The disposition register assigned each VM once:

Within the 82 rehost candidates, 23 VMs were rightsized after utilization and performance validation. Those 23 are a subset, not additional workloads. VM counts are not application counts; the 72 TB required separate replication, retention, and transfer planning.

Wave 0 and Six Controlled Workload Waves

Wave 0, Foundation, established inventory, dependency groups, ownership, and acceptance criteria alongside accounts, identity, network segmentation, connectivity, logging, budgets, backups, and infrastructure-as-code controls. Recovery and operational ownership were entry gates. This foundation phase preceded, and was outside, the six workload waves.

Six controlled workload waves follow that foundation:

1. Pilot: Rehearse a low-risk application group, validating replication, monitoring, restore, rollback, and business acceptance.
2. Low dependencies: Move independent internal services with known owners, checking latency and cost against assessment assumptions.
3. Shared services: Migrate eligible shared services and file workloads after testing dependent applications against the new endpoints.
4. Data services: Replatform compatible databases, reconcile data, verify recovery points, and test performance within an agreed rollback boundary.
5. Business apps: Cut over business-critical groups within plant-approved windows, with application owners and an escalation team present.
6. Acceptance: Complete remaining approved groups and service validation; decommission only after recovery, retention, and owner sign-off.

The six waves were sequencing groups, not equal VM batches. Dependencies determined membership; unresolved workloads stayed outside an approved wave. Retained systems remained managed dependencies. Retirement required evidence and approval, even when no AWS destination was needed.

Cutover, Rollback, and Recovery

Each wave has an owner-approved runbook, replication checks, a change freeze, acceptance tests, and a timed go/no-go decision. Tests cover orders, batch completion, identity, interfaces, and latency, not merely server availability.

Before writes move, rollback can return traffic to the source. After target-side writes begin, the runbook requires reconciliation or a tested reverse-data procedure before reopening the source. Independent writable copies are prohibited. The change lead triggers rollback when agreed error, reconciliation, or elapsed-time limits are exceeded.

Recovery objectives are agreed per business service. Backups, isolated restores, and a DR exercise must demonstrate recoverability across AWS and retained infrastructure. Replication alone is not proof of recovery.

Results: 30% Lower Three-Year Infrastructure TCO

The engagement achieved a 30% reduction in three-year infrastructure TCO. The workload decisions supported that result:

• 14 workloads retired: unnecessary systems were removed rather than migrated.
• 23 workloads rightsized: capacity was adjusted before cloud placement.
• 24 workloads selected for modernization: application change was targeted instead of applied to every VM.
• Six controlled workload waves: migration followed dependency groups and acceptance gates.

This is the result for this engagement, not a guaranteed saving for another estate. Customer-specific financial line items and commercial terms are not disclosed.

Day-2 Ownership and the Buyer Decision

AAIC’s operating model covers alerts, patching, recovery, capacity, and spending across cloud and retained infrastructure. OpsRabbit supports evidence correlation and investigation; engineers validate findings and approve changes.

The work brought inventory, workload decisions, migration runbooks, recovery planning, and Day-2 ownership into one delivery approach. The outcome was a smaller, more deliberately placed estate rather than an indiscriminate VM move.

Discuss your estate with AAIC’s VMware migration team.