For companies operating in Russia, moving away from VMware in 2026 is no longer simply a question of choosing another hypervisor. The practical challenge is migrating virtual machines so that they start correctly on the new platform while keeping business downtime within an acceptable window.
This guide covers the main Russian virtualization platforms, how to choose between them, migration approaches, workload preparation, downtime reduction, acceptance testing, and the economics of running the new environment.
Why Delaying the VMware Exit Can Cost More Than Migrating
The licensing and regulatory environment has made continued reliance on VMware increasingly difficult for organizations operating in Russia.
Broadcom's VMware Cloud Foundation 9 introduced License Portability and BYOL options, but Russian providers fall outside the permitted scope of these licensing models. For organizations subject to Russian procurement requirements, inclusion in the Russian software registry can also affect platform selection under 44-FZ and, in some cases, 223-FZ.
Critical information infrastructure operators face an additional transition toward trusted software and hardware. The target date of January 1, 2030, is established by Government Resolution No. 1912. At the same time, FSTEC Order No. 117, which came into force on March 1, 2026, replaced Order No. 17 and changed requirements for information protection in relevant systems.
Organizations processing personal data must also consider the requirements of Federal Law No. 152-FZ. In regulated environments, this can affect not only the virtualization platform itself but also the security tools and infrastructure used around it.
What Happens If You Keep Perpetual VMware Licenses?
A perpetual VMware license does not automatically provide access to future software updates. Continuing to run an unsupported environment therefore creates several technical and operational risks.
- Security vulnerabilities: several vulnerabilities affecting vCenter and ESXi have received CVSS scores above 9 in recent years, including vulnerabilities that can enable code execution.
- Ransomware exposure: ESXi environments remain a target for ransomware campaigns.
- Hardware compatibility: new server hardware may become increasingly difficult to use with older VMware releases.
- Audit and compliance risks: unsupported software can become a problem during security and compliance assessments.
How to Reduce the Risk While Preparing the Migration
If an immediate migration is not possible, several measures can reduce exposure while the new environment is being prepared.
- Isolate the management plane. vCenter, ESXi management interfaces, iLO and iDRAC should not be directly accessible from the Internet. Protect administrative access with network segmentation and MFA.
- Reduce unnecessary hypervisor access. Disable SSH where it is not required, enable lockdown mechanisms where appropriate, and restrict firewall access to management and backup systems.
- Keep backups outside the virtualization environment. Where possible, use isolated or immutable backup copies so that an incident affecting the virtualization layer does not also compromise the backups.
These measures can provide additional time to prepare a controlled migration, but they should be treated as interim risk reduction rather than a replacement for moving to a supported platform.
Where to Move: Russian Virtualization Platforms and Selection Criteria
Most Russian virtualization platforms are built around KVM, QEMU, or libvirt. They differ primarily in the management layer, cluster capabilities, storage architecture, automation, and certification status.
| Platform | Architecture and capabilities | Typical use case |
|---|---|---|
| zVirt | oVirt-based architecture, clusters, live migration, HA, templates and distributed storage | General vSphere replacement, medium and large clusters |
| RED Virtualization | oVirt lineage, integration with RED OS, native ESXi VM import | Government organizations and domestic technology stacks |
| Basis Dynamix | Private cloud, VDI, containers and orchestration | Large enterprises and internal cloud environments |
| SpaceVM | Own management layer, advanced SDN capabilities and support for protected environments | CII and certified environments |
| vStack HCP | Hyperconverged architecture, vStack HV based on bhyve, high VM density | Service providers and compact HA clusters |
| VMmanager | Lightweight management and rapid deployment | Hosting and small-to-medium environments |
| Cyber Infrastructure | Virtualization, SDS and backup capabilities from one vendor | Integrated virtualization and storage environments |
| ALT Virtualization | ALT-based distribution with several editions, including a PVE-based edition using Proxmox VE 9.1 with SDN | Organizations using the ALT Linux ecosystem |
| Proxmox VE / KVM + libvirt / OpenStack | Open-source virtualization and cloud stack without proprietary licensing | Development, non-critical workloads and environments where vendor responsibility is not required |
The selection process should start with the workloads rather than with the hypervisor. Classify environments by requirements such as critical information infrastructure, government information systems, personal data, production, development and VDI. Then define mandatory requirements, including registry status, FSTEC certification and protection class, before comparing functional capabilities.
Certified and Commercial Editions Are Not the Same Thing
For some platforms, a FSTEC-certified build is a separate product branch rather than simply a certificate attached to the commercial edition. Certified versions can lag behind commercial releases by a year or more because software updates have to go through additional verification.
This can affect both the upgrade cycle and the cost of ownership. Licenses for certified and commercial editions may not be interchangeable, and a package update can require a new compliance assessment.
If only part of the infrastructure requires certification, it may therefore make sense to maintain separate regulated and non-regulated environments instead of putting the entire infrastructure on the certified edition.
Where Russian Platforms Differ from vSphere
A replacement platform can cover the core virtualization requirements without reproducing every vSphere feature. Several differences should be tested before migration.
- Automated balancing: DRS-level workload balancing is generally less mature.
- Fault Tolerance: high availability normally means restarting a VM on another node rather than maintaining continuous dual-node execution. This introduces downtime.
- Software-defined storage: newer SDS implementations can have different performance and operational requirements from vSAN.
- Automation: PowerCLI-based scripts usually need to be replaced with REST API calls, Ansible, Terraform or platform-specific automation.
These differences should be measured in the target environment rather than evaluated only from feature lists. A practical test plan can include:
- live migration of a 256 GB VM under sustained write load;
- failure of a node running 30 VMs and measurement of recovery time;
- platform updates under load;
- workloads using disks larger than 4 TB and long snapshot chains;
- GPU passthrough for VDI or other GPU-dependent workloads.
Replacing the hypervisor also affects the surrounding ecosystem. Backup, monitoring, Active Directory or LDAP integration, certified security tools, multipath configuration and disaster recovery procedures all need to be reviewed.
Own Hardware, a Provider's Private Cloud, or a Hybrid Model?
The target infrastructure does not necessarily have to be deployed on new hardware owned by the company. Three models are common.
Dedicated Hardware
Own infrastructure provides maximum control and predictable resource availability, but it requires capital expenditure, procurement and deployment time. Hardware delivery and preparation can take 8–16 weeks.
This also creates a migration paradox: the new environment is needed before the old VMware environment can be decommissioned, but the new infrastructure may not yet be available when the migration project begins.
Private Cloud from a Provider
A provider's private cloud removes the need for an initial hardware investment and can often be provisioned within days. The provider is responsible for the data center, physical servers, virtualization layer and network infrastructure up to the agreed service boundary.
The customer remains responsible for guest operating systems, applications, access management, data and backups unless the contract states otherwise. These responsibilities should be documented explicitly before migration.
Hybrid Infrastructure
A hybrid model can place regulated workloads on dedicated infrastructure while running less restricted workloads in a provider cloud. This approach is common when only part of the environment has strict certification or data-location requirements.
Cloud infrastructure can also be used as a temporary migration platform. Workloads can be moved out of the existing environment, freeing the company's own servers while the new virtualization platform is built and tested without repeated overnight migration windows.
Afterward, workloads can either be moved back to the new platform or remain in the cloud.
For temporary migration environments, a cloud server can provide configurable CPU, RAM and storage resources that can be scaled as needed. Hourly billing can also make temporary infrastructure easier to budget during a migration project.
When evaluating a provider, the contract should clearly define:
- SLA metrics and compensation mechanisms;
- the format in which workloads can be exported, such as disk images, OVA/OVF or qcow2;
- any data export or egress charges;
- the scope of applicable certifications.
What If Existing Hardware Is Not on the Compatibility List?
Older hardware does not necessarily have to be discarded immediately. A practical approach is to test one representative server, run a workload test and confirm the configuration with the platform vendor.
Hardware outside the official compatibility list may be suitable for non-critical workloads, but controllers and network adapters are common sources of problems. Specialized industrial or medical applications can also have dependencies on VMware that make immediate migration impractical. In such cases, isolation may be preferable to an unsupported conversion.
How to Size the New Environment
Do not reproduce the existing VMware allocation one-to-one. The target platform may use resources differently.
- VMware memory overcommit ratios of around 1.2–1.5:1 are common in some environments, while KVM-based platforms may require a much more conservative ratio of up to approximately 1.1:1. Databases and 1C workloads should generally not rely on memory overcommit.
- CPU scheduling characteristics differ between hypervisors. A fleet containing many 8-vCPU VMs running at 5% utilization may have significant opportunities for right-sizing.
- NUMA topology can become more important when workloads are resized or moved to different hardware.
- For SDS, usable capacity must account for replication, such as a 2x or 3x replication factor, as well as capacity reserved for rebuilding data after a node failure.
Migration Mechanics: From Inventory to Cutover
Step 1: Inventory the Existing Environment
Start with a complete inventory using tools such as RVTools or the vCenter API. Record at least:
- vCPU and RAM allocation;
- virtual disks and their sizes;
- guest OS versions and architecture;
- BIOS or UEFI configuration and Secure Boot;
- virtual disk controllers;
- RDM and shared disks;
- snapshot chains;
- PCI passthrough devices;
- MAC addresses;
- VLAN assignments.
Step 2: Map Dependencies
A VM inventory alone is not enough. Map application servers, databases, directory services, license servers, integration buses, network flows, firewall rules, load balancers and application owners.
The goal is to understand which systems must move together and which can be migrated independently.
Step 3: Classify Workloads
- Non-critical: suitable for early migration and testing.
- Medium criticality: acceptable downtime measured in hours.
- Critical: target downtime of approximately 15–60 minutes.
- Special workloads: database clusters, 1C, passthrough devices and VMs larger than 2 TB require separate migration procedures.
Step 4: Run a Pilot
Select 10–15 VMs representing different operating systems and workload types. Measure conversion time for a typical 200 GB VM, identify conversion failures and record the time required for post-migration validation.
Step 5: Migrate in Waves
Move workloads in groups of approximately 20–50 VMs, starting with low-criticality systems and progressing toward production workloads. Related systems should be migrated together where possible.
Keep the old environment operational in parallel until the new platform has passed acceptance testing.
V2V Conversion
In a typical conversion, a VMware VMDK disk is converted into qcow2 or raw format, while the virtual hardware definition is rewritten for the target hypervisor.
Several tools can be used depending on the platform:
- virt-v2v: can retrieve VMs from vCenter or ESXi, convert the virtual disks, install VirtIO drivers, correct boot configuration and remove VMware-specific components.
- qemu-img: provides lower-level disk conversion but does not perform the full guest OS adaptation.
- Hystax Acura and similar tools: can replicate workloads to reduce the final cutover window.
- Native import: can be used when the target platform supports the required VMware version and VM configuration.
Networking During Migration
Test converted VMs first without connecting them to the production network. This prevents duplicate IP addresses and allows the guest OS configuration to be checked safely.
Differences in MTU can cause inconsistent network performance, while trunk configurations must preserve the required VLANs. Changes to IP addresses or subnets can also break firewall rules, database connections and application integrations.
Preparing the Guest Operating System
Windows: install VirtIO drivers before shutting down the source VM. Check UEFI and Secure Boot settings, record the existing IP configuration because a changed MAC address can cause Windows to create a new network profile, and verify whether hardware changes could trigger activation.
Remove VMware Tools before the final shutdown where appropriate and install qemu-guest-agent on the target platform.
Linux: verify that the initramfs contains the required VirtIO modules. Check /etc/fstab and make sure filesystems are referenced by UUID rather than device names that may change after conversion.
Common migration problems include active snapshots that have not been consolidated, RDM or shared cluster disks that require conversion or redesign, and very large VMs that take too long to copy.
For example, copying a 4 TB VM over a 10 Gbps network at 400–500 MB/s can take approximately 2.5–3 hours before conversion and validation are even complete. Replication is preferable when such a window is unacceptable.
Special Considerations for 1C
1C environments require attention to licensing and hardware parameters. Obtain the required PINs in advance or prepare a separate license server. HASP USB keys require a network license manager; direct USB passthrough to a cloud environment may not be available.
For 1C and database workloads, write latency is often more important than peak throughput. An average latency of up to 1 ms is a useful target, while sustained latency above 5 ms can become visible to users. Establish a baseline before migration and compare the target environment against it.
During the cutover, stop client sessions and web publications first, then the application server and database. Start the components in reverse order after migration. Scheduled jobs should remain disabled until the environment has passed acceptance testing.
How Long Does the Downtime Really Take, and How Can It Be Reduced?
| Migration method | Typical downtime | Requirements | Suitable workloads |
|---|---|---|---|
| Cold conversion with virt-v2v or qemu-img | 1.5–6 hours per 500 GB–1 TB | Storage and migration channel capacity | Non-critical and development workloads |
| Replication with final synchronization | Minutes | Replication software, licenses, agents and controller | Critical production and large VMs |
| Storage replication | 10–30 minutes | Compatible storage infrastructure | Large installations using compatible storage |
| Application-level migration | 1–5 minutes | Application replication or duplicate resources | Databases and critical applications |
| Load balancer migration | No service interruption | Stateless applications or shared session/database infrastructure | Web and terminal server clusters |
For a typical fleet, around 80% of VMs can often be handled with conventional cold conversion. Critical workloads require a different approach.
A typical replication-based cutover may consist of:
- final synchronization: 3–10 minutes;
- clean shutdown: 2–5 minutes;
- boot: 2–4 minutes;
- IP or DNS switch: dependent on TTL;
- ARP convergence: 1–2 minutes;
- integration testing: 15–40 minutes.
The most important migration milestone is the point of no return. Once the new environment contains data that does not exist on the old environment, a rollback can result in data loss or require manual reconciliation.
Define rollback criteria before the cutover. Examples include:
- the service does not become operational within 45 minutes;
- a critical integration fails;
- disk latency exceeds twice the agreed threshold;
- data discrepancies are detected.
Acceptance Testing
| Metric | Test | Target |
|---|---|---|
| Write latency | fio, random 8 KB, queue depth 32 | No more than 15% worse than VMware; DB/1C target ≤1 ms |
| IOPS | fio, 70/30 workload | No more than 10% deviation |
| CPU | Guest synthetic benchmark | No more than 5% degradation |
| Live migration | 64 GB RAM VM under write load | ≤5 minutes without session interruption |
| HA | Shut down a node running 20 VMs | All VMs recovered on other nodes within 10 minutes |
| Actual RTO | Restore a 500 GB VM from backup | Measure against the established baseline |
| Platform update | Update the cluster under load | No service interruption; rollback tested |
Baseline measurements are essential. Without them, it is difficult to determine whether a performance change after migration is caused by the virtualization platform, storage, network or workload configuration.
Example: 8 Nodes, 220 VMs and 60 TB of Storage
Consider a corporate production environment with eight nodes, 220 VMs and 60 TB of storage. The environment processes personal data but is not classified as critical information infrastructure.
| Project stage | Typical duration |
|---|---|
| Inventory and dependency mapping | 3–4 weeks |
| Platform selection and testing | 6–8 weeks |
| Licensing and hardware | 2 weeks in cloud / 12–16 weeks for hardware |
| Platform deployment | 4–6 weeks |
| Pilot migration | 2–3 weeks |
| Migration waves | 20–40 VMs per week, 6–10 weeks |
| Acceptance and decommissioning | 4 weeks |
| Total | 5–7 months with provider cloud / 7–11 months with own hardware |
Three-Year TCO Example
| Cost item | Own infrastructure | Provider cloud |
|---|---|---|
| Servers: 8 nodes, 2 × 32 cores, 1 TB RAM | ₽28.8 million | Included |
| 100 TB usable storage | ₽12 million | Included |
| Virtualization licenses, 3 years | ₽5.8 million | Included |
| Cloud resources: ₽1.75 million/month × 36 | — | ₽63 million |
| Backup | ₽4.2 million | ₽3.6 million |
| Design and implementation | ₽3.5 million | ₽1.2 million |
| External migration team | ₽5.5 million | ₽5.5 million |
| Dual licenses/resources for 4 months | ₽1.9 million | ₽2.3 million |
| Training and certification for 4 administrators | ₽0.9 million | ₽0.45 million |
| Data center hosting: 3 racks × ₽65,000 × 36 | ₽7.02 million | — |
| Operations: 2 engineers for 3 years | ₽14.4 million | ₽7.2 million |
| Hardware support, years 2–3 | ₽6.1 million | — |
| Downtime: 26 hours × ₽180,000 | ₽4.68 million | ₽4.68 million |
| Total | ₽94.8 million | ₽87.93 million |
The downtime figure in this example is illustrative and should be replaced with the company's actual cost of downtime. The 26 hours represent the cumulative downtime across migration waves, not a single outage.
In this example, the three-year difference is approximately 7%. Over a five-year period, owned infrastructure can become more economical when workloads remain stable. Actual results can vary significantly depending on hardware prices, utilization, staffing, cloud rates and migration requirements.
Key Takeaways
A VMware migration in 2026 is not primarily a VM conversion project. Converting the virtual disks is only one part of the work; inventory, dependency mapping, platform selection, ecosystem changes, testing and acceptance usually consume much more time.
Russian virtualization platforms can provide practical alternatives to vSphere for many workloads, but the migration should account for differences in automated balancing, fault tolerance, memory overcommit, storage and automation.
Budgeting should therefore be based on three-year TCO rather than the virtualization license price alone. Hardware, storage, operations, migration, dual-running costs and downtime all contribute to the final figure.
Downtime cannot always be eliminated, but its duration can be controlled. VirtIO preparation, snapshot consolidation, appropriate replication, DNS and TTL planning, baseline measurements and clearly defined rollback criteria can make the final cutover significantly more predictable.
For organizations that need temporary infrastructure during the transition, a cloud server can be used to move workloads out of the existing VMware environment while the target platform is prepared and tested.
Companies considering a broader cloud migration can also evaluate Cloud4U cloud infrastructure services as part of the target or temporary architecture.
