Virtual machine migration to eEVOS

Choose a migration path matched to the source

Q: Does a completed import mean that the application is ready for production?

Not by itself. Boot, networking, drivers, application services, integrations and performance should be validated before production handover.

Move workloads from VMware vSphere, Microsoft Hyper-V, KVM and Xen-based environments into eEVOS. The workflow is planned around the source, the workload and the required cutover—not a one-size-fits-all conversion.

Compare migration paths Plan the migration

The eEVOS interface presents source-appropriate import options without requiring administrators to assemble a migration workflow on the command line.

One destination, several routes

Migration is more than copying a virtual disk

Understand the sourceInventory the VM, guest operating system, virtual hardware, dependencies and current storage.

Select the appropriate import routevSphere has a dedicated guided workflow; other hypervisors use the standard VM import process with source-specific preparation.

Automate guest preparationeEVOS detects the guest operating system and automatically installs the required paravirtualised drivers for supported guests.

Validate before cutoverCheck boot behaviour, drivers, network assignment, applications and performance before retiring the source VM.

Supported source environments

Different sources require different preparation

eEVOS provides several VM import routes. The level of automation and the preparation required depend on the source environment, guest operating system and virtual hardware.

Guided workflow

VMware vSphere

The dedicated vSphere Import connects to vCenter or ESXi, discovers virtual machines and guides storage, network and job configuration through the eEVOS interface.

Source discovery through vCenter or ESXi
Storage and network mapping
Import job overview and progress tracking

Explore the vSphere migration workflow →

Standard VM import

Microsoft Hyper-V

Workloads exported from Hyper-V can be prepared for the eEVOS VM import workflow. Guest drivers, boot mode and virtual network assignments should be reviewed before the first production start.

Plan the export and service interruption
Prepare the guest for the target virtual hardware
Validate boot, network and applications

Standard VM import

KVM environments

Compatible VM disk images from KVM-based environments can be brought into eEVOS. The source configuration is reviewed and the VM is assigned suitable virtual hardware, storage and networking.

Review source image and VM configuration
Define target resources in eEVOS
Test the imported workload before cutover

Standard VM import

Xen-based environments

Exported workloads from Xen-based environments can be migrated using source-appropriate preparation and the standard eEVOS import process. Validation remains a planned part of the migration.

Inventory virtual hardware and guest dependencies
Prepare the workload for import
Confirm drivers, networking and application services

A controlled migration sequence

Plan the cutover around the workload

The exact sequence and required interruption depend on the source, data volume, application consistency and chosen migration method.

Inventory

VMs, services, dependencies and owners.

Prepare

Guest, export route and maintenance window.

Target

Compute, storage, networks and protection.

Import

Transfer the VM and apply target mappings.

Validate

Boot, drivers, network and applications.

Cut over

Release production traffic and monitor.

Keep the source recoverable until validation is complete. A successful import job is not the same as a validated application. Rollback and acceptance criteria should be agreed before the production cutover.

Questions before migration

Review what the workload actually requires

The source hypervisor is only one part of the design. Availability, storage and recovery requirements determine the appropriate eEVOS architecture.

DowntimeHow long may the service be unavailable during the final cutover?

ConsistencyDoes the application require an application-consistent shutdown or coordination?

DependenciesWhich DNS, identity, licensing, database and network services must move together?

RecoveryWhich backup, instant recovery and disaster recovery methods are required after migration?

DriversDoes the guest need storage, network or boot preparation for the target environment?

AcceptanceWho confirms application function, performance and the production handover?

Storage after migration

Place the workload on the storage architecture it requires

A migrated VM is not tied to one storage model. eEVOS can use local storage, synchronously mirrored storage, external shared storage or distributed Ceph storage, depending on the selected architecture.

Local storage

Direct placement for a single system or workloads whose availability is handled elsewhere.

Mirrored storage

Synchronous two-node storage mirroring for compact high-availability designs.

Shared storage

External FC, iSCSI or NVMe-oF storage for established shared-storage architectures.

Ceph storage

Distributed storage for scale-out eEVOS clusters with native access by compute nodes.

VMware vSphere deep dive

A dedicated workflow where deeper automation is available

The vSphere migration page documents the connection, discovery, mapping and job workflow in detail. It is one migration route within the broader eEVOS import capability—not the only supported source.

Migration FAQ

Set expectations before the first import

Does eEVOS only support migration from VMware vSphere?

No. eEVOS also provides VM import routes for workloads from Microsoft Hyper-V, KVM and Xen-based environments. vSphere has a dedicated guided workflow, which is why it has an additional technical detail page.

Is the workflow identical for every source hypervisor?

No. Source discovery, export preparation, virtual disk handling and guest preparation differ. The migration plan should reflect the source and the workload rather than assume identical automation.

Does a completed import mean that the application is ready for production?

Not by itself. The guest must boot correctly and its networking, drivers, application services, integrations and performance should be validated before production handover.

Can the target use shared or distributed storage?

Yes. Depending on the selected eEVOS architecture, the target can use local, mirrored, external FC/iSCSI/NVMe-oF or distributed Ceph storage.

Discuss the migration before scheduling the cutover

Share the source environment, VM inventory, storage model, acceptable downtime and recovery requirements. euroNAS can help identify the appropriate migration and target architecture.

Discuss your migration Explore eEVOS

VMware and vSphere, Microsoft and Hyper-V, KVM, Xen and other product names are referenced solely to describe technical interoperability and remain the property of their respective owners. This page does not imply a partnership, endorsement or certification. Supported configurations depend on the current euroNAS version, the source environment, guest operating system and qualified target architecture.