The following recommendations are derived from field observations, lab validation data, and enterprise migration engagements. They are intended to guide practitioners toward reliable, predictable, and low-risk migration outcomes at scale.
Migration Planning and Workload Segmentation
Effective migration planning begins with a structured inventory analysis that classifies workloads by their technical characteristics and operational risk profile. Rather than migrating all VMs in a uniform wave, workloads should be segmented into tiers that inform sequencing, tooling selection, and batch composition.
Recommended Segmentation Tiers
| Tier | Profile | Characteristics | Migration Approach |
|---|---|---|---|
| Tier 0 | Mission-Critical | Oracle RAC, WSFC, stateful HA clusters | Manual / Application-aware, out-of-band |
| Tier 1 | Business-Critical | Databases, ERP, messaging brokers | Cold migration, small batches, post-migration UAT |
| Tier 2 | Business Applications | Web servers, app servers, batch workers | Warm or cold, medium batches, automated validation |
| Tier 3 | Infrastructure Services | DNS, NTP, monitoring agents, jump hosts | Cold, large batches, minimal validation |
| Tier 4 | Dev/Test/ Non-Prod | Developer sandboxes, CI runners, test VMs | Aggressive batches, best-effort validation |
Tier 0 workloads should be migrated last, using application-specific migration procedures rather than Forklift. Starting migrations with Tier 4 and Tier 3 workloads provides operational experience with the toolchain before it is applied to higher-risk environments.
Dependency Mapping
Before sequencing, produce an application dependency map that identifies which VMs communicate with each other at the network level. Co-dependent VMs should be migrated within the same migration wave to avoid split-brain network scenarios where some components reside in OpenShift and others remain in VMware. Tools such as VMware network flow analysis from the NSX or Aria Suite can accelerate this process.
Batch Sizing and Concurrency Tuning
Batch sizing has a disproportionate impact on migration throughput, storage utilisation, and operational control. The following guidelines are derived from lab data across multiple FlashArray configurations.
| VM Profile | Disk Size Range | Recommended Batch | Max Concurrency | Migration Path |
|---|---|---|---|---|
| Small / Stateless | < 50 GB | 20–30 VMs | 8–12 | XCopy preferred |
| Medium / App Server | 50–200 GB | 10–15 VMs | 4–8 | XCopy preferred |
| Large / Database | 200–500 GB | 5–8 VMs | 2–4 | Cold + XCopy |
| XL / Data Warehouse | > 500 GB | 2–4 VMs | 1–2 | Cold + XCopy or manual |
Concurrency Scaling Rules
- Do not exceed 12 concurrent migrations on a single FlashArray without establishing baseline latency metrics.Monitor array write latency and pause if sustained latency exceeds 1 ms.
- The Forklift maxInFlight parameter in the MTV custom resource controls plan-level VM concurrency. Set this conservatively (4–6) for initial waves and increase after validating storage and network stability.
- Each concurrent migration requiring VDDK creates a persistent NBD session to the ESXi host.
- VMware ESXi hosts have a default limit of 27 concurrent NBD connections; beyond this, connections are queued.Distribute large migration batches across multiple ESXi hosts to avoid NBD saturation on a single host.
Network and Storage Design Guidelines
Dedicated Migration Network
VDDK-based migrations consume significant network bandwidth — typically 1–10 Gbps per concurrent migration depending on VM disk I/O patterns. It is strongly recommended to configure a dedicated VLAN or network segment for migration traffic that is isolated from production application traffic. This prevents migration activity from impacting production workload performance and enables QoS policies to be applied specifically to migration flows.
OpenShift StorageClass Selection
Ensure that the StorageClass used for migration target PVCs has volumeBindingMode: WaitForFirstConsumer set. This ensures PVCs are provisioned in the same topology zone as the pod that will consume them. Using Immediate binding mode can result in PVCs provisioned in zones that are unreachable by the migration conversion pods, causing pod scheduling failures.
Migration Sequencing Strategy
A phased migration sequencing strategy provides operational checkpoints that reduce risk and allow teams to build confidence progressively
Wave 1 — Validation (Tier 4): Migrate 10–20 dev/test VMs. Validate full toolchain, timing data, and post-migration runbook. Duration: 1–2 days.
Wave 2 — Infrastructure (Tier 3): Migrate supporting services — DNS, NTP, monitoring. Establish baseline OpenShift observability. Duration: 2–3 days.
Wave 3 — Applications (Tiers 2 & 1): Migrate application and business-critical workloads in dependency-ordered batches. Run UAT for each batch before proceeding. Duration: varies — typically 1–4 weeks.
Wave 4 — Core Services (Tier 0): Migrate mission-critical, clustered, or application-aware workloads using custom procedures. Duration: planned maintenance windows, varies.
Risk Mitigation and Rollback Planning
Pre-Migration
Before initiating any migration, create a FlashArray crash-consistent snapshot of the source volume using the Everpure purity CLI or REST API. This snapshot serves as the rollback point if the migration fails or the migrated VM does not pass post-migration validation. Snapshots should be retained for a minimum of 72 hours post-migration completion.
Rollback Procedure
If post-migration validation fails and rollback is required:
- Power off the migrated VM in OpenShift Virtualization
- Detach the PVC from the VM and restore the source FlashArray snapshot to the original volume
- Power on the original VMware VM and validate network connectivity and application functionality
- Capture the failure details and amend the migration plan before re-attempting