Sergio Gutierrez | CEO, Nubius Solutions.
Moving a virtual machine from VMware to another platform can look straightforward.
Power it down. Convert the disks. Start it on the new platform.
For critical production workloads, that is only a small part of the job.
This is a practitioner’s guide based on recent VMware to OpenNebula migrations of critical production workloads being performed by Nubius Solutions. The work is led by experienced engineers with direct involvement from senior technical leadership.
Across these migrations, the issues that matter most are consistent: preparing the destination correctly, understanding dependencies, maintaining network continuity, controlling downtime, validating storage and application performance, preserving rollback options, and making sure the new environment is ready for production operations.
The Destination Has to Be Ready Before the First Production VM Moves
In a VMware migration, a short maintenance window depends on work that happens well before the maintenance window begins.
Before migrating production workloads, the destination environment has to be ready to operate as a production platform. That means validating compute capacity, networking, storage, backups, monitoring, and the operational processes around the new environment.
Workload requirements and dependencies also need to be understood before cutover. The target architecture should reflect availability requirements, expected growth, storage needs, and how the environment will be operated after migration.
The engineering team also needs a rollback plan before the first production workload moves. We do not want to discover during a production cutover that storage behaves differently under load, a network dependency was missed, or an operational process does not work as expected.
By the time a production VM is powered down, most of those questions should already have answers.
Run the Source and Destination Platforms in Parallel
For a VMware to OpenNebula migration, the existing VMware environment and the new OpenNebula environment can operate simultaneously during the transition.
This allows the destination to be built, tested, and stabilized without requiring the source environment to disappear first. Workloads can then move in controlled groups rather than through one large cutover.
Prepare the destination. Move a group. Validate it. Stabilize it. Then move the next group.
That gives engineers and application owners time to confirm that migrated systems are behaving correctly before additional workloads are moved. It also preserves a practical path back to the source environment if something does not validate correctly.
For critical infrastructure, this gives us a way to reduce risk as the migration progresses rather than concentrating it into a single event.
Change as Little as Possible During Cutover
A hypervisor migration already introduces significant change.
Unless there is a clear technical reason, the maintenance window should not also become the time to change IP addresses, redesign network paths, modify applications, and rework dependencies.
In the migrations we are performing, existing network connectivity and server IP addresses are preserved where practical. During the agreed maintenance window, the workload is powered down in VMware, its disks are converted for KVM, and the server is started on the new platform without unnecessary application or network reconfiguration. This reduces the number of variables introduced during the move.
If an application does not behave correctly after cutover, the engineering team should not also have to determine whether the issue came from the hypervisor conversion, an addressing change, a network redesign, or several changes introduced at once.
There may be good reasons to modernize those components. They do not all need to be changed during the same maintenance window.
Downtime Is Only the Visible Part of the Migration
Downtime gets attention because that is what users and the business experience.
For workloads we are moving today, including systems with large disks, we are achieving approximately 20–30 minutes of downtime during the actual cutover. In practice, the disruption can feel much more like a planned server restart than a traditional infrastructure migration.
The important part is what makes that possible.
The destination has already been built and tested. Network requirements have been addressed. The workload has been prepared. The migration process and rollback path are understood before the maintenance window begins.
A fast conversion does not compensate for incomplete preparation.
Storage Has to Be Treated as Part of the Platform
Virtualization migrations naturally draw attention to the hypervisor. In production environments, storage can be just as important.
A workload can convert successfully and still perform poorly if the new environment cannot provide the latency, throughput, availability, or data protection the application requires.
For the OpenNebula environments discussed here, StorPool provides the distributed storage layer. The broader engineering point is not that every migration requires the same storage product. Storage architecture has to be selected, designed, and validated as part of the target platform.
Before production workloads depend on it, we need to understand how storage behaves under actual workload conditions, not simply whether enough capacity is available.
Performance, resilience, replication, backup, and recovery are all part of migration readiness.
Automation Makes the Conversion Repeatable
We automate much of the VM conversion process.
This reduces repetitive manual work, makes migration steps more consistent, and limits opportunities for human error. Our engineers use Nubius-built automation adapted to the source and target environments rather than assuming every migration is identical.
During the migration window, workloads are powered down on the source VMware environment, converted for KVM, and started on the new platform.
Automation, however, does not remove the engineering work around the conversion. The destination still has to be sized correctly. Application dependencies still have to be understood. Storage performance has to be validated. Application behavior has to be tested. And the team has to know when to proceed and when to roll back.
Automation makes a well-engineered process faster and more repeatable. The engineering work is what makes that process reliable.
Application Owners Need to Be Part of Validation
We can use automation to verify that the VM is running, network connectivity exists, storage is responding, monitoring is active, and the operating system appears healthy.
As part of that process, a script captures pre- and post-migration snapshots of the OS state, including services, packages, disk configuration, CPU, and RAM. An AI tool can quickly compare the snapshots and flag differences for review.
That does not necessarily mean the workload is behaving correctly. Infrastructure engineers still need to perform validation after migration, working with the people who know the applications and services best.
That involvement begins before cutover, when dependencies and expected behavior are established, and continues when the migrated workload is tested on the new platform. A server starting successfully is one checkpoint. The real test is whether the workload and the services that depend on it behave as expected under normal operating conditions.
For the migrations we are performing, application validation typically involves both developers and QA. Developers log in to the application services and verify that each application responds and behaves as expected. QA then runs smoke tests focused on API and application response rather than deep functional testing.
There is also a practical balance to strike. Validation has to be thorough enough to give the team confidence without consuming the entire maintenance window. A two-hour maintenance window can easily become eight hours if validation is taken too far.
We have found that the appropriate validation depth becomes easier to establish after the first few workloads are migrated. As the internal team sees the process work and gains confidence in the new environment, validation becomes more efficient without sacrificing the checks that matter.
The Migration Continues After the VM Starts
After a workload is converted, it must be monitored before the next group moves.
Monitoring, backup and recovery, operational ownership, escalation procedures, and ongoing support all need to work on the new platform.
This becomes especially important when an organization is introducing another virtualization environment. A technically successful migration should not create an operational problem for the people responsible for running the infrastructure.
The new platform has to be supportable as part of normal operations after the migration is complete. That is why migration work has to cover the full path from architecture and capacity planning through migration, validation, rollback preparation, and ongoing operations.
What Production Migrations Reinforce
Moving a production workload from VMware to OpenNebula is not primarily a disk-conversion exercise.
The conversion itself can be automated. The harder engineering work is everything around it: building the destination correctly, understanding dependencies, maintaining continuity during the transition, minimizing unnecessary changes, validating storage and application behavior, and knowing how to respond if something does not perform as expected.
When that work is done before and around the cutover, moving the workload becomes a controlled infrastructure change rather than a prolonged migration event.
For critical production systems, that is the objective.
Establish the Economics Before You Decide
A VMware renewal is one reason to evaluate platform economics. A new workload, infrastructure expansion, or a broader platform decision can raise the same question.
Before deciding where a workload should run, it helps to establish a cost baseline and compare the economics over time.
For a broader look at how to evaluate workloads, platform options, economics, and migration readiness, see our VMware Migration: A Practical Decision Framework.
Compare 3-year platform costs with the Nubius VMware Cost Calculator.
Validate Before You Commit
Every migration has edge cases — dependencies, storage behavior, network constraints — that don’t surface until you look at the actual environment. For qualified organizations, Nubius offers a complimentary engineer-led Migration Assessment: a focused review of one representative workload and its storage, run before you lock in a cutover plan. It surfaces the technical parameters, effort, and risk specific to your environment, so the plan is built on what’s actually there, not assumptions.
Request a Complimentary Migration Assessment
On that page, click Let’s Talk About Your Project and enter Complimentary Migration Assessment in the Subject field.