VMware to OpenShift migration with Cisco Isovalent, in waves, keeping your IP addresses.
Red Hat OpenShift Virtualization runs your existing virtual machines on Kubernetes, alongside containers. Cisco Isovalent connects the vSphere and OpenShift networks so applications can move in waves without renumbering. Ngenium’s senior engineers assess your estate, design the target on Cisco UCS, migrate with Red Hat’s Migration Toolkit for Virtualization and secure the result. Services-only: you procure the platform through your partner or distributor; we engineer the move.
Everything between a vSphere estate and a running OpenShift platform.
Moving virtual machines is the easy part. What decides whether a migration succeeds is knowing what moves easily and what does not, keeping network identity intact, and re-implementing security intent on the new platform.
Know what moves easily, and what does not.
Inventory from RVTools and Red Hat’s free OpenShift migration advisor, application dependencies, and a traffic-light scorecard: green for standard Windows and Linux VMs, amber for large disks, shared-disk clusters and GPU pass-through, rethink for features with no direct equivalent.
A platform you can size and procure.
OpenShift Virtualization on Cisco UCS with Intersight lifecycle management, storage from FlexPod with NetApp, FlashStack with Pure Storage or OpenShift Data Foundation, and Cisco Unified Edge for branch and plant sites.
Move VM 12 of 40 today, keep its IP address.
Cilium as the cluster network with Cisco Isovalent. Private Networks give VMs isolated, VLAN-style networks; the Network Bridge connects vSphere and OpenShift at layer 3, with no stretched layer-2 domain, so a VM keeps its address while the rest of its group waits.
NSX intent, re-implemented, not copied.
The existing rule base sorted into required, duplicate, overly broad and obsolete rules, then re-implemented as Cilium network policy with reusable application templates, with Hubble flow evidence before and after each cutover.
Controlled waves with Red Hat MTV.
Network and storage mappings, warm or cold migration chosen per workload, sequencing by dependency group, cutover runbooks and rollback criteria. Warm migration shortens the outage but does not remove it, and we say so on day one.
Finish the move, then retire VMware.
Post-cutover validation against the flow baseline, policy templates and flow monitoring exported to Splunk, backup and disaster recovery patterns on OpenShift, and a plan to remove bridge dependencies and decommission hosts once each wave is stable.
Running AI workloads next to your VMs? See how we deliver the Cisco Secure AI Factory on OpenShift →
Not sure OpenShift is the right destination? See how we compare platforms with no product to push →
Before, during, after: one accountable team.
The same senior engineers carry the work from the first inventory to the last decommissioned host. After go-live, the platform can move into managed security operations through our strategic partnership with Port53.
What your VMware team already knows, on OpenShift.
- vCenter → the OpenShift web console, with Advanced Cluster Management for fleets
- ESXi host → a bare-metal worker node running KVM, provisioned from Intersight
- DRS and HA → the scheduler, node health and eviction policies, configured per VM
- vMotion → live migration, on shared read-write-many storage
- Port group and distributed switch → a network attachment definition with Cilium and Isovalent Private Networks
- Datastore → a storage class and persistent volume claim, mapped one-to-one by MTV
- NSX distributed firewall → Cilium network policy: the intent is re-implemented, not converted rule by rule
- VMware Tools → the QEMU guest agent, installed during or after conversion
Why teams bring in Ngenium.
- Senior engineers only — the engineer who assesses your estate is the one who runs the cutover.
- Services-only — we never resell hardware or software and carry no product margin, so our advice on whether and what to migrate follows your estate, not a quota.
- Network and security depth — Cisco networking and Isovalent alongside Red Hat OpenShift, NetApp, Pure Storage and Splunk; the network is where VMware migrations usually go wrong.
- Honest about the trade-offs — warm migration still needs a cutover window, some workloads should stay or be redesigned, and running two platforms costs money until the last wave.
About VMware to OpenShift migration.
Can our virtual machines run on OpenShift without becoming containers?
Yes. Red Hat OpenShift Virtualization runs virtual machines on KVM, managed through OpenShift, next to containers. Guest operating systems and applications stay as they are. Red Hat also offers the OpenShift Virtualization Engine edition as a VM-only entry point that can move to the full platform later.
Will applications keep their IP addresses?
They can. Cisco Isovalent’s Network Bridge connects the vSphere and OpenShift networks at layer 3, without a stretched layer-2 domain, so a VM keeps its address when it moves and its dependencies keep working while the rest of its group waits. We validate the bridge design against the current support matrix during the assessment.
How much downtime should we expect?
Some, for each VM. Warm migration copies disks while the VM keeps running, then shuts the source down for a final synchronization at cutover, which shortens the outage but does not remove it. We record each application’s downtime tolerance in the assessment, choose warm or cold migration per workload and schedule cutovers inside your change windows.
Does Ngenium sell OpenShift, Isovalent or the hardware?
No. Ngenium is services-only. You procure Red Hat OpenShift, Cisco Isovalent and Cisco UCS through your partner or distributor; Ngenium assesses, designs, migrates and secures. Cisco channel partners also bring us in to deliver migrations for their customers, including white-label engagements under NDA.
What should not move, or should move last?
Standard Windows and Linux VMs on shared storage usually move easily. Large disks, shared-disk clusters, GPU and PCI pass-through, long snapshot chains and guests with special software terms need more planning, and features with no direct equivalent are redesigned rather than copied. The readiness scorecard sorts every workload group into green, amber or rethink before a plan is made.
Planning a move off VMware?
Talk to the senior engineers who would assess and migrate it — not a salesperson.