More than 600 virtual machines. An estimated seven-day migration under stable conditions. Approximately four weeks in reality, after recurring storage failures forced the team to migrate some systems more than once.

This is the story of how a shared migration workflow helped an operations team retain control when the infrastructure did not behave as planned.

The challenge: migrating at scale without depending on a few specialists

A large organization was moving more than 600 virtual machines from VMware to OpenShift Virtualization. The operations team included roughly ten people with different levels of experience in Kubernetes, OpenShift and the underlying infrastructure.

Red Hat Migration Toolkit for Virtualization (MTV/Forklift) provided the technical migration engine. But moving a VM is only one part of a much larger job: deciding what is ready, mapping networks and storage, assigning responsibility, scheduling work, tracking execution, verifying services and handling exceptions.

The goal was to make that work repeatable and visible to the whole team—not to require an OpenShift specialist to coordinate every individual migration.

Building the workflow while using it

MTV Manager began as a practical way to move beyond spreadsheets and scripts. A stable foundation was used early in the migration project, then expanded as operators encountered real requirements.

Inventory, ownership, readiness assessment, migration batches, live status, verification and project progress became parts of one operational workflow. Instead of asking everyone to piece together information from separate tools, the team could work from a shared picture of each VM and the wider project.

When storage failures changed the plan

Once the team had collected each VM’s migration window, responsible owner, verification contact and completion criteria, the workflow was ready to support a much higher pace. The entire development and test environment was migrated in four days, without any special effort to maximize throughput. Many of those VMs could be moved during daytime, with fewer constraints around downtime than production workloads.

Based on the available bandwidth and observed pace, the team estimated that hundreds of VMs per day—and completion of the full 600-plus VM scope in approximately seven days—would have been feasible if the underlying infrastructure had remained stable. This was an informed capacity estimate, not a demonstrated seven-day result.

Instead, recurring problems in the Ceph storage environment disrupted the work. Some virtual machines had to be migrated again, including systems whose migrations had previously completed. The overall effort took approximately four weeks.

At that point, the biggest risk was not only the technical failure. It was losing track of what had happened across hundreds of systems: which VMs had been migrated, which needed another attempt, what required recovery, and what still awaited verification.

MTV Manager helped keep that operational state visible and actionable. Recovery and repeat-migration requirements fed back into the product as the team worked through the problems.

Without that shared workflow, the team believes reconstructing migration history and coordinating repeated work would have consumed substantially more time. That avoided effort was not formally measured, so we do not present a numerical time-saving claim.

Making migration a team workflow

With common preparation and status information, migration work could be distributed across more operators rather than concentrated with a small number of specialists. The technical experts remained essential for complex problems, but routine coordination no longer needed to depend entirely on them.

Readiness checks helped distinguish systems prepared for migration from those with outstanding blockers. Batches gave operators manageable groups of VMs. Verification kept technically completed migrations visible until the surrounding operational work was finished.

What the project demonstrated

• Scale: more than 600 virtual machines in the migration scope.
• Observed pace: the development and test environment migrated in four days without a special acceleration effort.
• Estimated capacity: hundreds of VMs per day and the full scope in approximately seven days, subject to stable infrastructure and completed preparation.
• Actual duration: approximately four weeks, including disruption and repeated migrations caused by storage problems.
• Coordination: a common workflow across operators with different levels of OpenShift experience.
• Resilience: migration state, recovery work and verification remained visible when the original plan had to change.

The four-day development/test migration and approximately four-week overall duration are observed outcomes. The seven-day full-project scenario is the team’s estimate under stable infrastructure conditions, not a guarantee for another environment.

The lesson: the migration engine is only part of the solution

MTV and OpenShift were responsible for performing the technical migrations. MTV Manager provided the operational structure around them.

The most important result was not simply moving hundreds of virtual machines. It was being able to keep a complex project organized when the same work had to be revisited, sometimes repeatedly.

The infrastructure problems delayed the project. A shared workflow helped prevent those problems from becoming a much larger coordination problem.

MTV Manager itself was developed iteratively with AI-assisted engineering support, including design discussions, implementation and testing. That development story is separate from the customer outcome: the value demonstrated here is the workflow the team could use in practice.

MTV performs the migration. MTV Manager manages the journey.

Explore MTV Manager and its capabilities →

Planning a VMware-to-OpenShift migration? Contact CNAME AB to discuss your migration project.