Designing a UI for an operation that had never had one.

How we got from one to the other

Research and discovery

The audience here is platform engineers and virtualization admins managing fleets of VMs across OpenShift clusters. Many of them are coming from vSphere, so they arrive with strong expectations — hierarchical resource views, readiness checks they can actually read, and a clear gate before anything irreversible happens.

Between mid-May and mid-July 2025, the design went through seven full review rounds with the cross-team group. The information architecture shifted twice along the way. The Migration readiness step started life as a post-submit error surface, but became a pre-flight gate after the second round, once it was clear users wouldn't trust the result unless they saw the checks pass beforehand.

Key UX moves

A four-step wizard with explicit migration-readiness gating

The flow runs General information → Target placement → Migration readiness → Review. The readiness step kicks off five checks in parallel — network, storage, compute, version and capacity — and users can't move forward until they all pass. The friction is deliberate. Once the migration is in flight there's no real way back, so a hard gate before commit is worth the extra step.

Source and destination as paired panes

Two clusters means two trust boundaries. The Target placement step shows source and destination side by side, with cluster and project paired on each. The symmetry is intentional — the worst version of this UI would have made one of the two sides feel like an afterthought.

What we cut from the MVP

The original scope included bulk actions, a TreeView for browsing cluster hierarchies and multi-VM migration with grouping. Tech Preview shipped with none of that — single VM, simple table. Pushing a larger surface into Tech Preview with no UI precedent anywhere in the ecosystem felt like a bigger risk than starting smaller and earning the next round of scope.

Challenges

The Ansible question

A debate ran for several weeks on whether Ansible was the right execution layer for cross-cluster migration. One side felt it was a natural fit. The other felt it added complexity without enough payoff. The design had to stay neutral throughout — the playbook export option needed to feel like a first-class fork in the road, not a quiet hedge.

High fidelity walkthrough

The interactive prototype that drove the design is also public:

• ACM user interface prototype →
• OKD docs: Enabling CCLM for VMs →

Final takeaways

1. When there's no UI precedent in an ecosystem, shipping smaller is usually the more senior call. Tech Preview went out single-VM, with bulk actions, TreeView and multi-VM grouping deferred — and that turned out to be the right shape.
2. For operations that can't really be undone, a bit of deliberate friction earns its keep. The pre-flight gate added a step, but it's the step users told us they needed in order to trust the result.
3. Two clusters means two trust boundaries. Treating source and destination as paired panes wasn't a layout decision — it was a model decision dressed as a layout one.
4. What I'd push harder for next time: joint design across all three migration paths (in-cluster, cross-cluster and Migration Toolkit) earlier in the GA cycle. Seams between products are far easier to design at the start than to retrofit later.

Public proof and customer evidence

The work shipped as Tech Preview in ACM 2.15, with GA targeted for 2.16. The wider OpenShift Virtualization story — which cross-cluster live migration is a foundational part of — already has a fair amount of public customer evidence behind it:

• Cleveland Clinic (10,000+ VMs) — migrating all VMs to OpenShift at 50% lower TCO. (Source)
• Emirates NBD — moved 9,000+ VMs from VMware, up to 200 per night. (Source)
• Telenet Business — 50 GB VM transitions in minutes with near-zero downtime. (Source)
• NASA JPL selected OpenShift Virtualization for mission-critical infrastructure. (Source)

Further reading