VMware workload migration to public cloud with hybridity

Most organisations reach public cloud without abandoning their VMware estate. They retain data-centre infrastructure for capacity, latency or regulatory reasons while moving selected applications into AWS, Microsoft Azure or Google Cloud. Hybridity makes this practical, provided the operating model, security controls and network paths are designed together.

A workload migration to public cloud should begin with business intent rather than a list of virtual machines. Clear recovery objectives, application dependencies and success measures allow the team to choose the right migration pattern, validate it in stages and prevent the source environment from becoming an expensive source of orphaned resources.

Define the hybrid operating model

Decide which capabilities remain on premises and which move into the cloud. The source data centre may continue hosting VMware hosts, storage and backup infrastructure while the public cloud provides elastic compute, disaster recovery or specialist services. This creates a hybrid cloud architecture that can evolve without forcing a single cutover date.

Choose between a managed VMware service and a native cloud landing zone. VMware Cloud on AWS, Azure VMware Solution and Google Cloud VMware Engine reduce application conversion work, while EC2, Azure Virtual Machines and Compute Engine offer greater control when refactoring is practical. Validate licensing, hardware support and feature parity before committing.

Storage design shapes the source estate’s portability. A small stretched cluster such as a two-node vSAN deployment can be represented in a migration plan, but its replication links and unsupported configurations still need review. The two-node vSAN guide provides useful context for testing resilience assumptions before workloads are relocated.

Map dependencies and select a migration pattern

Inventory the entire application stack, including virtual machines, datastore files, licence servers, databases, DNS records, hard-coded IP addresses and external integrations. Use vCenter APIs and configuration-management records to identify relationships that application owners may overlook. Record recovery time and recovery point objectives alongside technical dependencies.

Match each workload to an appropriate pattern. A business-critical application with tightly coupled infrastructure may need rehosting through HCX or vMotion, while a supported web service could be replatformed using containers or managed databases. Retirement may be safer than migration when an application has become redundant, although its data and records still require a governed disposition process.

Define measurable acceptance criteria for testing. These should include application performance, security controls, backup restoration, DNS behaviour, licence compliance and recovery procedures. A workload is ready for production only when its operating team accepts the support model and the rollback procedure has been exercised.

Build an Australian landing zone

AWS provides Australian Regions in Sydney, Melbourne and Perth, while Azure and Google Cloud offer local deployment options in major capitals. Select a region based on customer proximity, service availability and recovery requirements rather than distance alone. Sydney–Melbourne latency can be modest on a well-engineered path, but internet routing and cross-region traffic can still create delay.

Map Australian regulatory obligations before moving data. The Privacy Act 1988 and Australian Privacy Principles may constrain personal information handling, while contracts should control offshore administrative access. Financial institutions may also need to align with APRA CPS 230, and government or critical-infrastructure organisations commonly use the ASD Essential Eight as a security baseline.

Use identity as a consistent control plane. Many Australian organisations already combine Microsoft 365 with Entra ID for hybrid workers, branch offices and cloud applications. Extending that identity model through conditional access, MFA and role-based administration reduces duplicated controls, but legacy VMware hosts still need a deliberate trust and authentication plan.

Connect networks without creating a bottleneck

Create dedicated paths using AWS Direct Connect, Azure ExpressRoute, Google Cloud Interconnect or encrypted site-to-site VPN, depending on scale and availability. Australian organisations commonly combine enterprise fibre from providers such as Telstra or Optus with SD-WAN for distributed sites. Test failover separately because a secondary VPN can fail to provide the expected bandwidth.

Match routing to the cloud platform’s architecture. Transit gateways, route tables, peering and on-premises prefixes must account for overlapping address ranges, asymmetric routing and maximum transmission unit differences. DNS and service discovery should migrate with the workload; otherwise, an otherwise successful virtual-machine move can leave users unable to reach the application.

Model the complete hybrid cost in Australian dollars. Include private connectivity, data transfer, licensed entitlements, managed security, logging and eventual exit costs. Provider discounts may appear attractive, but renewal assumptions and unused source capacity often become the largest ongoing expense.

Automate repeatable migration and validation

Automation should make each wave repeatable and auditable. The Ansible VMware automation guide demonstrates how inventories, workflows and idempotent playbooks can reduce manual intervention. Apply similar controls to cloud resources through Terraform or the platform’s native tooling.

Build validation into the deployment pipeline rather than treating it as a final manual check. Use PowerCLI and cloud APIs to confirm datastore attachment, guest customisation, firewall rules, identity access and monitoring coverage. Capture the source configuration, compare it with the target and store the evidence needed for change approval and audit.

Pattern	Suitable workload	Expected outcome	Main consideration
Relocate	VMware stack requiring minimal change	Existing platform enters a public cloud region	Validate licensing and regional feature support
Rehost	Individual virtual machines	Standardised compute replaces source hosts	Rewrite application dependencies where needed
Replatform	Applications suited to managed services	Lower operational overhead and easier scaling	Requires code or architecture changes
Refactor	Applications needing a cloud-native redesign	Improved portability and deployment flexibility	Highest delivery effort and testing demand

Run a reversible pilot and commit to the next step

Choose a representative but non-critical application for the first wave. Migrate it through a cloned network, verify business transactions and rehearse failover, rollback and backup restoration. Keep the source environment available until the new service has operated through normal business cycles and an agreed observation period.

Treat the pilot as the basis for a repeatable runbook. Assign platform, application, network and security ownership; track recovery metrics, cloud consumption and support incidents; and define what must happen when a workload changes ownership. Start the next migration wave this month with a named owner, a tested rollback point and a measurable cost baseline.