VMware-to-OpenShift migration is not only a control-plane decision. It is also a storage decision. If the storage plan is vague, the migration inherits risk from VM disks, backup workflows, performance assumptions, and recovery procedures.
Use this checklist before a VMware migration to OpenShift and Kubernetes, a vSAN replacement, or an OpenShift HCI architecture review.
The checklist is designed for platform, infrastructure, storage, and virtualization teams that need a shared planning artifact before the first production migration wave.
Phase 1: Inventory the Current VMware Storage Estate
Start with facts, not assumptions.
| Area | Questions to answer |
|---|---|
| vSAN or SAN usage | Which workloads depend on vSAN, SAN, NAS, or local datastore behavior? |
| VM disk classes | Which disks are latency-sensitive, capacity-heavy, or recovery-critical? |
| Snapshots and backups | Which workflows depend on array snapshots, VMware snapshots, or external backup tooling? |
| RPO/RTO | Which workloads have explicit recovery commitments? |
| Performance | Which workloads have known IOPS, throughput, or p99 latency requirements? |
| Maintenance | What happens during node, host, or storage maintenance today? |
| Ownership | Which team owns storage policy decisions and incident response today? |
Collect this information from the actual estate. Do not rely only on architectural diagrams. In many VMware environments, the storage design has changed through years of exceptions, one-off policies, and undocumented workload requirements.
Phase 2: Segment Workloads by Migration Risk
Do not move every workload in the first wave. Pick migration candidates based on storage complexity:
- Start with workloads that can tolerate clear maintenance windows.
- Keep high-risk databases and tightly coupled legacy VMs out of the first wave unless they are the target proof point.
- Identify VM workloads that can move to OpenShift Virtualization.
- Identify workloads that should be modernized into containers instead of moved as VMs.
- Define rollback expectations before moving production data.
- Identify workloads that need special backup, snapshot, or replication handling.
Use a simple migration risk map:
| Segment | Storage risk | Recommended first action |
|---|---|---|
| Low-risk VMs | Ordinary boot/data disks, clear rollback path | Use as early migration candidates. |
| Stateful application VMs | Application data, moderate recovery needs | Validate StorageClass and restore workflow first. |
| Database VMs | p99 latency, write consistency, backup coupling | Run performance and recovery proof before migration. |
| Legacy clustered apps | Shared-disk or topology assumptions | Review architecture before choosing a migration path. |
| Modernization candidates | Better fit as containers | Decide whether VM migration is still the right path. |
Phase 3: Map VMware Storage Behavior to OpenShift StorageClasses
The migration plan should translate storage behavior, not only disk size.
| VMware-era assumption | OpenShift storage design question |
|---|---|
| vSAN datastore | Which StorageClass provides the equivalent performance and protection outcome? |
| VM snapshot workflow | Which snapshot and clone workflow will platform teams use after migration? |
| HA and host maintenance | What happens during OpenShift node drain, workload rescheduling, and storage recovery? |
| Gold image or template clone | Can the new platform support fast clones without manual backend work? |
| Storage policy | Which OpenShift StorageClass, topology, and failure-domain policy replaces it? |
| Capacity reservations | Which PVC and thin-provisioning behavior replaces the old allocation model? |
| Datastore monitoring | Which Kubernetes and storage metrics replace datastore-level visibility? |
Do not make the new StorageClass model too granular. A common anti-pattern is to recreate every vSphere storage policy as a Kubernetes storage class. That creates configuration sprawl without improving operations. Start with a few classes that reflect real workload intents.
Phase 4: Validate OpenShift HCI vs Disaggregated Storage
For many teams, the first question is whether the target should be hyper-converged.
| Option | Use when | Watch for |
|---|---|---|
| OpenShift HCI | You want a familiar vSAN-like starting point and smaller operational footprint | Compute and storage may grow unevenly. |
| Disaggregated storage | You need independent scaling, larger capacity pools, or stronger separation | Network and failure-domain design matter more. |
| Hybrid model | You need different shapes for different workload classes | Requires clearer placement and policy rules. |
Simplyblock supports all three models, which helps teams avoid locking the migration into the first topology forever.
For VMware exit, the clean question is not “what looks most like vSAN?” It is “which model gives us the right operational starting point without creating another long-term lock-in problem?”
Phase 5: Define the Production Readiness Gate
Do not call the storage migration ready until these checks pass:
- p95 and p99 latency tested under representative load.
- Snapshot, clone, backup, and restore workflows tested.
- Node drain and failure-domain behavior validated.
- VM disk and database StorageClasses separated where needed.
- Monitoring and alerting connected to storage latency, saturation, and capacity.
- Rollback plan documented for each migration wave.
- Owner named for each production storage class.
- Cleanup policy defined for staging, clone, and validation volumes.
- Support path documented for platform, storage, and application teams.
Use a pass/fail gate, not a vague readiness statement:
| Gate | Pass condition | Owner |
|---|---|---|
| StorageClass mapping | Each workload segment maps to a documented class | Platform + storage |
| Restore test | Representative VM and data disk restore completes within target | Platform + backup |
| Latency test | p99 remains within target during expected load | Storage + application |
| Maintenance test | Node drain or maintenance does not create unacceptable outage | Platform |
| Rollback test | First-wave workload has a documented rollback path | Migration lead |
Phase 6: Build the Migration Wave Plan
Each wave should have its own storage checklist:
- Workloads included in the wave.
- Source datastore or storage policy.
- Target OpenShift StorageClass.
- Snapshot and backup procedure.
- Data copy or migration procedure.
- Validation owner.
- Rollback owner.
- Go/no-go criteria.
- Post-migration monitoring window.
The storage plan should be reviewed before the workload migration plan is approved. If the team cannot explain how a VM disk is protected, restored, observed, and deleted, it is too early to move that workload.
Phase 7: Watch for Red Flags
Stop and revisit the architecture if any of these appear:
- Every VM disk is mapped to one default OpenShift StorageClass.
- The migration plan says “storage TBD” after the platform design is approved.
- Live migration expectations are not tested with representative storage modes.
- Backup ownership changes during migration but is not documented.
- Databases are treated the same as ordinary boot disks.
- Node drain testing is skipped.
- The team cannot explain how p99 latency will be monitored after migration.
- The new HCI design cannot evolve if storage grows faster than compute.
These are not theoretical issues. They are the places where storage becomes the hidden blocker in platform migration programs.
Phase 8: Decide Where simplyblock Fits
Simplyblock is a fit when the migration needs OpenShift-native block storage for VMs and stateful workloads without carrying forward vSAN or SAN operating assumptions. It is especially relevant when teams want:
- Low-latency NVMe-oF storage for OpenShift.
- CSI-native provisioning, snapshots, and clones.
- HCI, hybrid, and disaggregated deployment options.
- A storage layer that supports VM and container workloads together.
- A cleaner path for OpenShift, private cloud, and VMware-exit programs.
Simplyblock should be evaluated as part of the target OpenShift storage architecture, not as a late-stage replacement for whatever storage assumptions made it through the migration plan.
Planning VMware-to-OpenShift storage migration?
Bring the checklist to a storage architecture review and pressure-test the migration plan before the first production wave.
Questions and Answers
When should storage planning start in a VMware-to-OpenShift migration?
Storage planning should start before the first workload wave. Waiting until VMs or databases are ready to move creates unnecessary risk around recovery, snapshots, and performance.
Should teams replace vSAN before or during the OpenShift migration?
It depends on the migration plan. Many teams evaluate the storage replacement as part of the OpenShift target architecture so they do not move control planes first and solve storage later under pressure.
Is OpenShift HCI the default replacement for vSAN?
It can be a strong starting point, but it should not be automatic. Some platforms need disaggregated or hybrid storage once compute and storage growth diverge.
What is the biggest storage risk during VMware exit?
The biggest risk is assuming disk capacity equals storage readiness. The real issues are latency, recovery, snapshots, failure domains, and operational ownership after the move.
How does simplyblock support this migration pattern?
Simplyblock provides Kubernetes-native block storage for OpenShift with NVMe/TCP and NVMe/RoCE support, CSI workflows, snapshots, clones, and deployment choices across HCI, hybrid, and disaggregated models.