Zero-Downtime Migration of Dual Data Centres to AWS

At a Glance

Detail	Value
Industry	Enterprise
Environment	2 colocation data centres, 400+ workloads, VMware, OpenShift
Timeline	3 months lift-and-shift, 6 months progressive conversion
Key Results	Zero downtime, 35% cost reduction after conversion, 100% VMware exit

The Challenge

A digital marketplace for wholesale automotive auctions, connecting thousands of dealers across North America and Europe, had outgrown its two colocation data centres. Hardware refresh cycles were becoming prohibitively expensive. OpenShift clusters running on VMware were hitting capacity limits. And both colocation leases were expiring within six months.

The mandate was clear: migrate every workload to AWS without a single second of customer-facing downtime. But the portfolio was complex. 400+ workloads spanning traditional VMs and containerised applications running on OpenShift, all deeply interdependent.

The tight deadline ruled out a traditional re-architecture-first approach. The team needed to get out of the data centres fast, then modernise in place.

The Approach

We structured the migration in two distinct phases.

Phase 1: Lift-and-Shift via VMware Cloud on AWS

Rather than refactor 400+ workloads under time pressure, we used VMware Cloud on AWS as an intermediate landing zone. This allowed us to migrate entire vSphere environments (VMs, networks, and policies) as-is, with zero application changes.

Direct Connect Extension. We extended the existing Direct Connect circuits from the colocations to the VMware Cloud SDDC in the same AWS region. This preserved IP addressing, VLAN configurations, and firewall rules. The workloads didn’t know they had moved.

Bulk vMotion. Using VMware HCX, we migrated 400+ VMs over a 10-week window. Each wave of VMs was vMotioned live during business hours with no downtime. The HCX network extension kept MAC and IP addresses intact, so application dependencies required zero reconfiguration.

OpenShift on VMware. The OpenShift clusters running on VMware were migrated as VMs within the VMware Cloud SDDC, preserving the container orchestration layer exactly as it was. OpenShift continued managing its containers. It was simply running on AWS infrastructure now.

Phase 2: Progressive Conversion to Native AWS

With the immediate deadline met, the team systematically converted the VMware footprint to native AWS services:

VMs to EC2. Workloads that couldn’t be containerised or weren’t suited for serverless were converted to EC2 using AWS Application Migration Service. vSphere VMs were replicated to EC2 instances with modern AMIs, preserving the OS and application configuration. These were primarily legacy or third-party applications with tight OS dependencies.

Applications to EKS. Applications already running in OpenShift were migrated to Amazon EKS. We provisioned EKS clusters with matching node profiles, ported application manifests with minimal changes, and shifted traffic namespace by namespace behind a shared ingress with canary validation. Containerised applications were natural fits for EKS with no re-architecture needed.

Applications to Lambda. Stateless, event-driven services and API backends were refactored as Lambda functions during the conversion phase. These were low-complexity workloads with clear request-response patterns. Internal APIs, data processing pipelines, and webhook handlers that benefited from serverless scaling without ongoing instance management.

The Results

• Zero customer-facing downtime events across both phases.
• 12-week lift-and-shift completion. Both colocations decommissioned on time.
• 35% reduction in infrastructure operational costs after full conversion.
• 100% VMware exit. No ongoing VMware licensing or operational overhead.
• 400+ VMs assessed and converted to EC2, EKS, or Lambda per workload suitability.
• No application rewrites during the initial migration. Business risk minimised.

Key Takeaways

1. Lift-and-shift is not failure. When the clock is ticking on a data centre lease, getting out is the priority. VMware Cloud on AWS let us migrate at vMotion speed with zero downtime and zero application changes, and modernise later without a gun to our heads.
2. One size does not fit all for conversion. We used EC2 for workloads that needed OS-level control, EKS for containerised services, and Lambda for stateless event-driven functions. The right conversion target depended on the application, not the migration timeline.
3. Plan the exit from day one. VMware Cloud on AWS was always intended as a bridge, not a destination. We started planning the conversion architecture (assessing each workload for EC2, EKS, or Lambda suitability) during the lift-and-shift, so Phase 2 began the day Phase 1 completed.
4. Test conversion, not migration. We didn’t test the vMotion. We tested the conversion. Our pre-production environment ran identical workloads on EC2, EKS, and Lambda to validate behaviour before committing production traffic.