Rob Pankow 
When enterprise teams plan a move from VMware to OpenShift or Kubernetes, the conversation usually starts with the compute layer: which virtualization technology replaces vSphere, how KubeVirt handles existing VM workloads, and how the orchestration model changes. Storage gets addressed later — and by the time teams reach the storage decision, they often discover that vSAN does not carry over.
This is not a gap in the migration plan. It is a structural reality. VMware vSAN is a hypervisor-integrated storage layer built specifically for vSphere VM workloads. It surfaces storage to virtual machines through the VMFS and virtual disk model. OpenShift and Kubernetes consume storage through an entirely different model: the Container Storage Interface (CSI), persistent volumes, and storage classes. These two models are not compatible, and vSAN was not designed to serve as a CSI backend.
The practical implication is that vSAN storage must be replaced — not migrated — as part of any serious OpenShift or Kubernetes transition. The question is what to replace it with, and how to approach the transition without introducing platform instability.
What vSAN Does That OpenShift Storage Must Also Do
Understanding the replacement decision starts with understanding what vSAN actually provides, beyond its tight VMware integration.
vSAN pools locally attached drives across ESXi hosts into a distributed storage cluster. It provides redundancy through object-based replication with configurable failure-tolerance policies, supports thin provisioning and deduplication, and delivers snapshots and clones as VM-level operations. In larger environments, stretched cluster configurations provide site-level resilience. The storage is policy-driven — storage policies attach to virtual machines and define performance and protection requirements — and management integrates directly into vCenter.
A replacement for vSAN in an OpenShift or Kubernetes context needs to deliver the same core capabilities through a fundamentally different interface. Instead of VMFS and virtual disk presentation to ESXi hosts, the replacement must provide CSI-compliant block volumes, dynamic provisioning through Kubernetes storage classes, snapshot and clone operations through the Kubernetes VolumeSnapshot API, and data protection with recovery capabilities appropriate for the new platform. Policy-based placement and quality-of-service controls replace vCenter storage policies.
The operational model also shifts. vSAN management lived inside vCenter. Storage management for Kubernetes-native storage lives inside Kubernetes or OpenShift tooling — or in the storage platform’s own management interface — and health monitoring integrates with Prometheus and the OpenShift monitoring stack rather than vCenter dashboards.
Why Broadcom Licensing Changes Accelerate This Decision
For many enterprises, the storage replacement decision has become more urgent since Broadcom’s acquisition of VMware. Licensing restructuring has made vSAN substantially more expensive in several scenarios: vSAN is no longer separately purchasable outside the vSphere+ and VMware Cloud Foundation bundles in the revised Broadcom commercial model, and per-core licensing for those bundles has pushed costs higher for organizations that previously licensed vSphere and vSAN individually.
The commercial pressure this creates has moved storage replacement from a future consideration to a current-cycle decision for many infrastructure programs. Teams that were planning a two- or three-year VMware exit are now evaluating accelerated timelines, and the storage layer is a required part of that exit — not an optional follow-on project.
This context matters for technology selection. Platform teams need a storage replacement that is ready for production use on OpenShift or Kubernetes now, not one that requires extensive tuning or a long integration project before it can carry critical workloads.
The Storage Replacement Decision: Key Criteria
Evaluating vSAN replacements for OpenShift or Kubernetes involves several criteria that are distinct from the vSAN-to-vSAN or storage-to-storage comparisons relevant in VMware environments.
CSI maturity and OpenShift certification matter more than raw feature lists. A storage platform that is not CSI-compliant or not validated for OpenShift will create integration friction that slows migration work. Red Hat OpenShift certified partners have validated their CSI drivers against the OpenShift platform, which reduces evaluation risk.
Data protection model needs to translate. vSAN’s policy-driven failure tolerance (using terms like FTT=1 or FTT=2 for the number of tolerable failures) maps to replication and erasure coding configurations in alternative storage platforms. Teams should verify that the replacement can meet their availability requirements with the hardware configuration they are deploying — particularly during the transition period when the storage cluster may be smaller than its steady-state size.
Snapshot and clone behavior affects how existing application workflows carry forward. vSAN supports VM-level snapshots that integration teams use for backup and rapid recovery. A Kubernetes-native replacement should support the VolumeSnapshot API and copy-on-write clone semantics so that equivalent workflows — backup integration, rapid database provisioning, CI/CD pipelines that clone storage for test environments — can be rebuilt without significant re-architecture.
Operational complexity during transition deserves explicit attention. Migration programs run the VMware and Kubernetes environments in parallel for months before cutover. The storage replacement needs to operate reliably during this period without requiring a fully staffed storage engineering team dedicated to it, particularly in organizations that are simultaneously building OpenShift platform expertise.
How simplyblock Addresses the vSAN Replacement Requirements
simplyblock is built for the vSAN replacement scenario specifically within OpenShift and Kubernetes migration programs. It is a software-defined block storage platform built on NVMe/TCP with a CSI driver for OpenShift and Kubernetes and Red Hat OpenShift certified-partner status.
Where vSAN pools locally attached drives across ESXi hosts, simplyblock pools NVMe drives across standard x86 servers and exposes them as block volumes via NVMe/TCP. The storage is software-defined and hardware-agnostic — it runs on commodity NVMe servers without proprietary controllers or specialized networking requirements beyond standard Ethernet.
Copy-on-write snapshots and clones replace vSAN’s VM snapshot model in a Kubernetes-native form. These operations are exposed through the standard Kubernetes VolumeSnapshot API and through simplyblock’s management interface. Backup integration, database cloning for test environments, and point-in-time recovery workflows can be rebuilt using the same CSI snapshot primitives that any Kubernetes-native application can consume.
Erasure coding and replication provide data protection with configurable failure tolerance. simplyblock’s erasure coding is designed to minimize storage overhead while maintaining protection — a key economics advantage over vSAN’s triple-replication default, which consumes three times the raw capacity to store each unit of data.
simplyblock supports both hyper-converged deployments — storage co-located on OpenShift worker nodes — and disaggregated deployments with dedicated storage servers. This flexibility allows teams to match the deployment model to their hardware constraints during migration, and to evolve the topology as the platform matures.
Planning the Transition
The practical migration from vSAN to a Kubernetes-native storage platform involves several stages that can be sequenced to minimize risk.
The first stage is establishing the new storage cluster in parallel with the existing vSAN environment. This does not require decommissioning vSAN first — the two storage environments operate independently during the transition period. Application workloads are migrated from the VMware environment to OpenShift incrementally, and each migration brings the storage for that workload to the new platform.
The second stage is validating storage behavior under production conditions for each workload type before treating the Kubernetes storage as the primary environment for that workload. This includes verifying snapshot and recovery workflows, confirming that performance SLAs are met under realistic I/O patterns, and testing failure scenarios — node loss, drive failure, network partition — against the new storage platform.
The final stage is decommissioning the vSAN environment after all workloads have migrated and sufficient operational confidence has been established. In most programs, this is the last step in a broader VMware exit, completed after compute, networking, and storage have all been validated on the new platform.
For teams working through this process, simplyblock’s implementation guides and the vSAN alternative overview provide architecture and deployment reference for common OpenShift migration scenarios.
Questions and Answers
Can vSAN be used as a storage backend for OpenShift or Kubernetes directly?
No. vSAN is a hypervisor-native storage layer designed for the vSphere VM model. It does not expose a CSI-compliant interface for Kubernetes or OpenShift. Teams moving workloads to OpenShift or Kubernetes need a storage platform built for that environment, not a bridge from vSAN.
How does vSAN’s failure tolerance policy translate to Kubernetes storage alternatives?
vSAN’s FTT (Failures To Tolerate) policy maps to replication factor or erasure coding configurations in Kubernetes-native storage platforms. An FTT=1 policy (tolerating one failure) roughly corresponds to two-way replication or erasure coding with one parity shard in NVMe-native alternatives. The exact mapping depends on the storage platform’s protection model and the hardware configuration.
Do workload data volumes need to be migrated when moving from vSAN to a Kubernetes storage platform?
Yes. Data does not move automatically. Application workloads are typically migrated by deploying new persistent volumes on the Kubernetes storage platform and moving application data through backup-and-restore, replication, or application-level export and import workflows. The approach depends on the application and its tolerance for downtime during the migration window.
What hardware is needed to replace vSAN on OpenShift?
A software-defined alternative like simplyblock runs on standard x86 servers with NVMe or SSD drives. The same servers can run OpenShift worker workloads in a hyper-converged configuration, or the storage cluster can be separated onto dedicated servers in a disaggregated model. No proprietary controllers or specialized networking hardware is required beyond standard Ethernet.
How long does a typical vSAN-to-Kubernetes storage migration take?
Timeline varies significantly with cluster size, workload complexity, and team bandwidth. Most enterprise programs run vSAN and the new storage platform in parallel for several months during the broader VMware exit, migrating workloads incrementally rather than in a single cutover. Storage migration planning should be included in the overall VMware exit timeline rather than treated as a sequential follow-on project.
