An interface for an operation with no undo

How it happened

Who this is for

The people who run private clouds for a living: think air-traffic controllers, but for thousands of virtual machines. Most of them spent years in the industry-standard tool before ours, so they arrived knowing exactly what a migration should feel like: a clear map of what's where, safety checks they can actually read, and a hard stop before anything irreversible.

Between May and July 2025 the design went through seven review rounds. The biggest shift came in round two. The safety checks started life as an error message you saw after submitting, and it became obvious nobody would trust that. These users wanted to watch the checks pass before committing. So the error message became a pre-flight gate, and that one move reshaped the whole flow.

The three calls that mattered

A hard gate before the point of no return

The flow is four steps: what you're moving → where it's going → is it safe → confirm. The third step runs five checks at once, network, storage, computing power, version, capacity, and you cannot continue until all five pass. That friction is deliberate. Once the machine is mid-flight between data centres there is no undo, so one forced pause before commit is cheap insurance.

Source and destination as equals

Moving between two data centres means trusting two different systems at once. So the "where it's going" step shows origin and destination side by side, the same details paired on each. The worst version of this screen would have made one side feel like an afterthought, the symmetry isn't a layout choice, it's the mental model.

Shipping small on purpose

The original scope had bulk moves, a browsable map of everything you own, and moving whole groups of machines at once. The first release shipped with none of it, one machine at a time, a simple table. When nothing like your product exists yet, shipping small and earning the next round of scope beats shipping big and hoping.

The hard part

The argument I had to design around

One debate ran for weeks between the engineering teams: should the migration run through the company's automation tool, or stand on its own? One side said natural fit; the other said complexity without payoff. My job was to keep the design neutral while the argument played out, the "run it as a script instead" option had to feel like a real fork in the road, not a quiet hedge for a decision nobody had made yet.

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 nothing like your product exists yet, shipping smaller is usually the more senior call. The first release went out deliberately narrow, one machine at a time, and that turned out to be the right shape.
2. For operations that can't be undone, a bit of deliberate friction earns its keep. The safety gate added a step, but it's the step users told us they needed in order to trust the result.
3. Moving between two systems means trusting both. Treating origin and destination as equals on screen wasn't a layout decision, it was a model decision dressed as a layout one.
4. What I'd push harder for next time: three separate teams each owned a different flavour of "moving machines," and we designed ours alone. 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. Cross-cluster live migration is part of the wider OpenShift Virtualization move, which already has 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