Leaving Azure VMware Solution and VMware Cloud on AWS: Where Your Storage Lands

Most VMware® exit writing assumes a rack the reader controls. That assumption is wrong for a large and growing group of buyers: the ones who already migrated once, into Azure VMware Solution, VMware Cloud on AWS, or Google Cloud VMware Engine, and who gave up the hardware decision as part of that move. For them the estate is a managed vSphere cluster inside a hyperscaler region, billed by the host, and the storage layer is not something they ever picked.

That group is now being told to move again. Microsoft has announced the retirement of the legacy Azure VMware Solution reserved-instance SKUs that bundled VMware licensing, with an off-ramp period running into 2027; the exact terms and dates are worth reading in Microsoft’s own announcement rather than in any vendor’s summary of it. Whatever the specifics, the effect is the same as the on-premises licensing squeeze: the commercial arrangement that justified the original decision is ending, and inaction is not one of the available options.

The off-ramp guides now appearing in this space are all licensing and control-plane documents. They compare landing platforms on management experience, on how the hosts are billed, on how the VMs are moved. Almost none of them mention what happens to the datastore, which is odd, because in hosted VMware the datastore is the part of the stack with the least flexibility and the most cost leverage. This post is about that part.

What Hosted VMware Actually Changed About Your Storage

On-premises, vSAN is a choice. You bought servers, you populated them with drives you selected, and you enabled vSAN across them. If the storage layer disappointed you, swapping it meant a project, but the project was possible.

In Azure VMware Solution, VMware Cloud on AWS, and Google Cloud VMware Engine, vSAN is not a choice. It is the datastore the service provides, running on the local NVMe drives of the managed hosts you rent. You cannot substitute it, you cannot tune the drive selection behind it, and in most cases you cannot inspect the failure domain in the way you could on your own hardware. The service abstracts the hardware and hands you vCenter.

Two consequences follow, and both of them are financial rather than technical.

Capacity is bought in host units. When the cluster runs low on usable space, the remedy is to add a host. That host arrives with its CPU sockets, its memory, and its VMware licensing entitlement, all of which you pay for in order to reach its drives. Storage-heavy, compute-light workloads therefore pay a compute tax that has nothing to do with their actual demand. This is the exact coupling that made hosted VMware expensive for many estates in the first place, and it is structurally identical to the per-core problem on-premises, just with the invoice coming from a hyperscaler.

Cost-reduction levers are indirect. External storage attachments and cloud-native file or object services can move some data off the vSAN datastore, and both hyperscalers document that pattern, but they add a second storage system to operate and they do not change how the primary datastore scales. Deduplication and compression settings help at the margin. None of it changes the unit of purchase.

Table 1: What changes about the storage layer when a vSphere estate moves into a hyperscaler-managed service.

Why the Off-Ramp Is the Only Moment the Storage Decision Is Open

Storage decisions are sticky because moving data is expensive and risky. A running estate has volumes attached to VMs that people depend on, and nobody schedules a storage migration for its own sake. This is why so many organizations run the same storage architecture for a decade after the reasoning behind it stopped applying.

An off-ramp with a deadline breaks that inertia, exactly once. The VMs are moving anyway. The data has to be copied anyway. The cutover window has to be negotiated with application owners anyway. Every cost that normally makes a storage change unjustifiable is already being paid for a different reason. If the storage architecture is going to change at all, this is the cheapest moment in the next ten years to change it.

Which makes the default option worth naming precisely. The default is to land on another platform where storage is again bundled with the hypervisor and again purchased in node units: a different vendor’s hyperconverged stack, in the same cloud region, with a different licence attached. That move satisfies the deadline. It also re-creates the coupling that produced the deadline, one platform generation later, and it spends the one cheap storage-migration window you had in order to do so.

Planning a hosted VMware off-ramp and unsure what to do with the datastore? Talk to us before you pick the landing platform, because the storage decision constrains the platform choice far more than the reverse. Talk to a storage architect

Four Landing Options, Scored on What Actually Costs You

There are four honest destinations for a hosted VMware estate. They differ less in migration effort than in what they commit you to afterwards.

Stay on hosted VMware under new commercial terms. Bring your own VMware licences, or accept whatever replaces the retired SKUs. Lowest migration effort, no storage change, and no change to the host-unit purchasing model. Reasonable if the estate is small, stable, and the new pricing is tolerable.

Move to a different hosted VMware service. VMware Cloud on AWS or Google Cloud VMware Engine instead of Azure VMware Solution, or the reverse. This is a procurement move dressed as a migration. vSAN remains the datastore, host units remain the purchase unit, and you have acquired exposure to a second provider’s future licensing decisions rather than removing exposure to the first one’s.

Move to a hypervisor-bundled hyperconverged stack in the same cloud. Keep the region, replace the stack underneath. Management is familiar, the VMs move with tooling the vendor supplies, and the deadline is met. Storage is again bundled with the platform, capacity is again added in node units, and the next licensing change lands on you the same way this one did.

Land the VMs on KubeVirt or Red Hat® OpenShift® Virtualization with the storage layer decoupled. Highest migration effort of the four, because the VMs become Kubernetes objects and the operational model genuinely changes. In exchange, storage stops being a property of the platform. Capacity is provisioned against a pool, not a node count, and the same storage layer can sit on-premises, in a sovereign European cloud, or in the hyperscaler region the estate already occupies.

Table 2: The four landing options, scored on purchasing unit, scaling independence, and what the move costs you the next time terms change.

Note the pattern in the last column. Three of the four options leave you in the same structural position: a platform vendor sets the terms, the storage is welded to the platform, and a future commercial change forces another full migration. Only the fourth turns the next move into a re-attach, because the volumes are addressed over a network fabric rather than owned by a specific cluster.

Making the Storage Layer Survive the Landing

The practical work is less exotic than it sounds, and it is the same work already documented for on-premises estates in our KubeVirt migration guide. Hosted VMware adds one wrinkle: the source disks live on a datastore you reach through vCenter inside a provider-managed cluster, so the export path matters more and egress may be billable.

The mechanics, in order:

1. Inventory by storage profile, not by VM. Group the estate by IOPS demand, latency sensitivity, capacity, and snapshot policy. The output you want is a small set of storage classes, not a per-VM spreadsheet.
2. Import the disks as DataVolumes. The Containerized Data Importer path takes VMDK or converted images and produces PVCs that a VirtualMachine object can boot. This is the same path used for on-premises vSphere sources.
3. Provision RWX block for anything that must live-migrate. VM live migration on KubeVirt requires the volume to be attachable from two nodes at once, which means ReadWriteMany block access mode, not filesystem. This is the single most common blocker discovered late.
4. Re-establish snapshot and backup policy before cutover. A CSI snapshot is not a VM backup: it captures the disk, not the VM definition. Both need to be in the backup scope from day one, not after the first restore test fails.
5. Validate the failure behaviour you are actually buying. Kill a node in the target environment and time the volume re-attach. That number, not a synthetic benchmark, is what determines whether the platform is production-viable for your estate.

Where simplyblock fits is step 3 onward. The storage layer runs as software on NVMe drives, serving volumes to compute over NVMe/TCP or NVMe/RoCE, with a CSI driver that provisions them like any other Kubernetes volume. Concretely, for a hosted VMware estate leaving its provider:

• Capacity is decoupled from host count. You add usable terabytes to the pool, not hosts. A storage-heavy, compute-light estate stops paying for cores it does not use in order to reach drives it does.
• **Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. It is not free; the difference is that the meter is one you already plan around, and data volume does not move it.
• RWX block comes from the same storage class as RWO, so live migration is a configuration property rather than a second storage system.
• Deployment model is yours. Hyperconverged on the same nodes as the VMs, or separated across a storage fabric, from one control plane. Estates that landed hyperconverged out of habit can separate the tiers later without a data migration.
• The same layer runs in more than one place. On-premises NVMe, a sovereign European cloud, or the hyperscaler region the estate already sits in, with the same storage classes, snapshot semantics, and re-attach behaviour. That is what makes the next move a re-attach.
• Hypervisor-independent. vSphere, Hyper-V, bare-metal Kubernetes, KubeVirt, and OpenShift Virtualization all consume the same storage layer, so a phased migration does not require running two storage systems in parallel.

None of that removes the migration work. It removes the part where you do the migration work again in three years because a platform vendor changed the terms of a licence you do not control.

Questions and Answers

Is the datastore in Azure VMware Solution or VMware Cloud on AWS replaceable?

No. In both services, and in Google Cloud VMware Engine, vSAN is the datastore the managed service provides, running on the local NVMe drives of the hosts you rent. You can attach supplementary external storage or move data to cloud file and object services, but the primary datastore is not swappable and its capacity is expanded by adding hosts. That constraint is the main reason the off-ramp is worth treating as a storage decision rather than a licensing one.

Why does moving to another hyperconverged platform not solve the problem?

Because it preserves the coupling that caused it. If storage is bundled with the platform, capacity still arrives in node units, the storage layer is still versioned with the hypervisor, and the platform vendor still sets the commercial terms. The migration satisfies the deadline and re-creates the exposure. Simplyblock’s position is that the storage layer should be a separate purchasing and scaling decision from the compute platform, which is what makes the following move cheap.

What should we do first if the off-ramp deadline is close?

Inventory the estate by storage profile before evaluating any landing platform. Group VMs by IOPS demand, latency sensitivity, capacity, and snapshot policy, and note which ones must support live migration. That inventory tells you what storage characteristics the target platform has to provide, and it is the input every subsequent decision needs. Picking the platform first and discovering the storage requirements afterwards is the sequence that produces late-stage surprises, usually around ReadWriteMany block.

Does leaving hosted VMware mean repatriating to our own hardware?

Not necessarily, and the two decisions are separate. You can land on KubeVirt or OpenShift Virtualization inside the same hyperscaler region the estate already occupies, on standard instances with local NVMe, and keep the geography unchanged. Whether to also move the data out of the hyperscaler is a data-gravity and cost question that deserves its own analysis. The point of decoupling storage from the platform is that you get to answer the two questions independently, and on your own schedule.

How does simplyblock’s pricing compare to per-host capacity purchasing?

Simplyblock is priced like the platform it runs on: by the CPU capacity of your worker nodes, counted the same way your OpenShift or Kubernetes subscription counts them, and data volume does not change the price. In a hosted VMware service, reaching more usable capacity means renting another whole host, including its cores and its platform licensing. The comparison that matters for your estate is the raw-to-usable ratio and the compute you are currently paying for solely to reach drives. Estates with high capacity and modest compute demand see the largest difference; compute-heavy estates see less.