Peerobyte / Community / Blog / The VMware Exodus: How to Migrate to OpenStack/KVM/Proxmox or Cloud Without Downtime

The VMware Exodus: How to Migrate to OpenStack/KVM/Proxmox or Cloud Without Downtime

Last updated: Jan 29, 2026 18 minutes reading time

Why the VMware Exodus Has Become a Reality

Until recently, it seemed that VMware was forever. For decades, the company was synonymous with virtualization, setting standards for data centers worldwide. Then 2024 began, followed by 2025, and everything changed. Hundreds of clients started leaving, proving that nothing lasts forever in business. And for businesses today, the question is no longer "do we need to migrate?" but rather "how exactly and where to?"

Broadcom + VMware: The Merger Effect

After Broadcom acquired VMware, it became clear: the old business model is dying. The biggest blow to customers was the abandonment of perpetual licenses that could be purchased once and used for years. Now it has turned into an endless subscription with annually increasing bills.

Broadcom also drastically reduced the number of partners. This deprived many local integrators and resellers of access to favorable terms. As a result, companies—especially small and medium-sized ones—had to face an unpleasant truth: maintaining infrastructure on VMware became noticeably more expensive and complex.

The European Market Under Pressure

In Europe, the situation escalated to the limit. The cancellation of vSphere Essentials, a product that was incredibly popular with small and medium-sized businesses, effectively left thousands of companies without access to the familiar VMware ecosystem. It was replaced by much more expensive plans oriented toward large clients.

Broadcom doesn't even hide that they now only work with large clients. This puts small businesses in a hopeless situation: either pay "like big" corporations or urgently look for a replacement. It's no surprise that after this turn of events, interest in OpenStack, KVM, Proxmox, and, of course, cloud providers has sharply increased.

Regulators Are Also Involved

Such an aggressive approach by Broadcom has not gone unnoticed. Antitrust investigations are already underway in the EU to determine whether the company is violating competition rules. But there's no point in businesses waiting for bureaucrats to sort things out. Infrastructure is needed here and now, not in a year or two when a decision will be made.

European Context: What to Look at First

When European companies start thinking about moving from VMware, it's not just about technology. When it comes to migration, you need to think not only about where to move but also about laws and people. These two factors directly affect how quickly and successfully the transition will proceed.

Laws and Regulations: How Can We Do Without Them?

European business cannot simply ignore legislation. There's already GDPR, which strictly regulates data handling. These new rules, like NIS2, Data Act, and DORA, add more headaches for businesses.

The Data Act dictates how compatibility and data exchange between different platforms should work. And DORA is focused on the financial sector, where migration from VMware is not just an upgrade but a condition for legal compliance.

VMware Engineer Shortage and Open-Source Growth

Additionally, there's the staffing problem. Additionally, there's the staffing problem. In Europe, there's already an acute shortage of certified VMware engineers. Some of them went into consulting, while others decided to master Kubernetes and other cloud technologies.

Because of this, the labor market is changing, and now specialists in open-source solutions like OpenStack, KVM, and Proxmox are needed. And although the market is not yet saturated with such personnel, there's a clear advantage here: young specialists are more willing to study them, as these skills will be useful not only in data centers but also in large cloud services.

Service and Certification Availability

And don't forget that compliance with standards is another key criterion. European providers on OpenStack actively offer their services to clients with ISO 27001 (information security) and ISO 27701 (privacy management) certificates.

Additionally, EUCS (European Cybersecurity Certification Scheme) will soon appear, which will become a unified standard for all cloud services in the EU. This means that when choosing a platform, it's worth looking not only at "hardware" and hypervisor but also at the provider's possession of these certificates. In essence, they are becoming a pass to the market for companies from the financial, medical, and government sectors.

Data Sovereignty: A Hidden Driver

A less obvious but critically important aspect is data sovereignty. European laws like Gaia-X or French SecNumCloud requirements strictly regulate where data should be located.

Because of this, many companies can no longer work with giants like AWS or Azure if they don't provide the required level of localization and transparency. In essence, businesses have to look for new ways. This pushes them toward local cloud providers on OpenStack or to use hybrid models where part of the data remains in their own data center, and part—with a trusted partner in the EU.

Migration Preparation: What's Often Forgotten

When the conversation turns to migrating from VMware, many companies mentally imagine the process as "moving virtual machines" from one basket to another. But reality is much more complex: infrastructure always has hidden dependencies, licensed products, and historical "artifacts" that can turn migration into an endless project. To avoid this, preparation should be as systematic as the migration itself.

Inventory: See More Than "Virtual Machines"

The first mistake is limiting yourself to a list of virtual machines. Yes, a list of VMs with CPU, RAM, and disks is needed. But the VMware stack usually runs many more "invisible" services:

network policies (vDS, NSX), without which migrated VMs suddenly find themselves isolated;
vSAN or other SDS solutions, where data is not tied to a specific disk but distributed across clusters;
vRealize automations and orchestrators that manage VM creation and deletion;
custom templates, snapshots, and scripts that have lived "under the hood" for years.

Inventory should cover all levels: compute, storage, network, automation. Otherwise, on the new stack, the business risks losing part of the automations or, worse, disrupting critical processes.

Licensed Applications and Compliance

The second risk zone is commercial applications, such as Oracle Database or SAP. Their licenses are often tied to a specific hypervisor, CPU cores, or even specific server models.

For example, migrating Oracle from VMware to KVM may require license revision and recalculation of "per core" metrics. And in the case of SAP, platform support will need to be agreed upon with the vendor. Plus there are compliance questions: in financial and pharmaceutical companies, migration without official vendor confirmation can lead to fines and audit problems.

Therefore, at the preparation stage, lawyers and licensing specialists need to be included in the project. Their task is to calculate in advance how the cost of application ownership will change after migration.

Hidden Dependency: What's Always Forgotten

Another trap is "invisible" agents and integrations. Classic examples:

backup agents (Veeam, Commvault) tied to VMware API;
monitoring systems collecting metrics through vCenter;
CI/CD pipelines where "production" deployment is automated specifically for VMware.

All these integrations need to be identified and checked in advance: whether new platforms have similar APIs and SDKs, how to reconfigure pipelines, which agents to update. Otherwise, after migration, the infrastructure may be "bare"—without monitoring and backups.

Pre-Migration Optimization

Migration is a great opportunity to clean things up. On average, in corporate environments, 20-30% of VMs turn out to be "zombies": no one uses them, but they're still running and consuming resources.

Before migration, it's worth conducting rightsizing: recalculate the actual needs of applications and reduce "fat" VMs that have historically bloated. This will reduce the load on the new platform and speed up the migration process itself. "As-is" migration is almost always more expensive and longer.

Practical Tool: CMDB and IaC

Finally, the main question is how to reduce the number of "manual" operations. Two approaches help here:

CMDB (Configuration Management Database): an up-to-date configuration database allows you to understand which services depend on what and not forget any critical component.
Infrastructure as Code (IaC): storing infrastructure descriptions as code (Terraform, Ansible, Helm charts) turns migration from "VM copy-paste" into a reproducible process. If IaC already exists—great, if not—migration is a great occasion to start.

Migration Scenarios: From Lift-and-Shift to Complete Rebuild

When a company decides to leave VMware, the main question arises: how exactly to migrate? In practice, there's no "universal recipe"—everything depends on scale, applications, and budget. Below we'll examine the main scenarios used in Europe today.

Lift-and-Shift: Quick but Not Always Smart

The classic scenario is lift-and-shift. The essence is simple: virtual machines "as is" are transferred to OpenStack or KVM, only the hypervisor changes.

Pros:

quick migration time,
minimal changes in architecture,
users often don't even notice the "move."

Cons:

all "old sins" are preserved: excess resources, outdated images, non-obvious dependencies;
licensed applications may not work correctly without certified support;
network and storage policies essentially need to be built from scratch.

In short, "lift-and-shift" is a way to quickly escape from VMware, but not the best solution for the long term.

But for small and medium-sized businesses and branches, Proxmox has changed everything. This is a relatively easy-to-manage hypervisor that works without problems on regular "hardware" and provides good functionality.

But it's important to understand the limitations:

Proxmox is weaker in scalability compared to OpenStack,
limited integration capabilities with enterprise tools,
fewer available certifications and vendor support.

Therefore, Proxmox is an excellent solution for local sites, pilots, or edge nodes, but for enterprise level and especially in highly regulated industries, it's often used as a "stepping stone" rather than a final destination.

On-the-Fly Containerization: KubeVirt and Harvester

For those who have already switched to containers, there's a very smart way to work with VMs. Technologies like KubeVirt or Harvester allow running virtual machines right inside a Kubernetes cluster, which makes it possible to "pack" VMs into containers.

What this gives:

unified platform for VMs and containers,
ability to gradually "unpack" monoliths into microservices,
flexible automation through Kubernetes API.

There are also cons:

high configuration complexity,
increased team qualification requirements,
not all applications behave well in such an environment.

This scenario is more often chosen by companies that have already deployed Kubernetes in production and want to minimize the number of "zoos" in their infrastructure.

Expert Moment: Unification Through Cloud-Init and Ansible

Regardless of the chosen scenario, migration is almost always a chance to clean up configurations. Tools like cloud-init and Ansible come to the rescue here.

For example, after transferring VMs, you can automatically:

configure network settings,
add users and keys,
set up monitoring and backup agents.

A unified Ansible role or playbook ensures that infrastructure after migration looks the same, rather than being a collection of "surprises" from each administrator.

Dual-Cloud Period: Temporary but Costly

Practically every migration project has a "dual-cloud" period when part of the workloads remains on VMware, and part already works on OpenStack or in another cloud.

This is the riskiest stage because:

you have to pay for support and licenses simultaneously in two worlds,
backup, monitoring, and security processes are duplicated,
the risk of configuration inconsistency increases.

Migration Tools: What Really Works in Europe

When the conversation turns to migrating from VMware, most companies first think: "Well, it's just copying virtual machines." But anyone who has participated in such a project at least once knows—it's a complex technological and organizational process. And the main question here is: what can we really ride on?

Open-Source Tools: Cheap, Flexible, but with Caveats

For companies wanting to minimize migration costs, there's a set of proven open-source solutions:

Virt-v2v—a classic tool for converting virtual machines from VMware to KVM/OpenStack. In addition to working with disks, it can transfer virtual machine parameters and adjust configuration. Limitation: not all drivers and agents "survive" the process without manual refinement.
Qemu-img—a true classic—a utility that allows converting disks from one format to another (for example, from VMDK → RAW or qcow2). In essence, the main thing in a virtual machine is its disk, which means it's enough to convert it to the required format and create a new VM with this image. The method is simple but requires manual environment settings.
Cloudbase-qemu-tools—useful when migrating Windows guest systems, as it automatically installs VirtIO drivers and optimizes network/disk operation.
Velero (formerly Heptio Ark)—a tool for backing up and restoring Kubernetes clusters, but it can be used in conjunction if part of the applications is already containerized.
Heptio (now part of VMware Tanzu) is still used for individual scenarios, but more often—in projects where Kubernetes + VM hybrid exists.
StarWind V2V Converter—although this is not pure open-source but a free proprietary tool, it's often put on par with OSS solutions due to its simplicity and convenience. Allows converting images between formats (VMDK, VHDX, QCOW2, etc.) in a couple of clicks, and is especially popular for "quick" migrations.

The main advantage of open-source solutions is accessibility and transparency. But the minus is obvious: they require high team qualification and more manual work.

Commercial Solutions: A "Box" for Money

Commercial migration tools are also popular in the European market:

Zerto—one of the leaders in DR and migrations. Allows "almost seamless" VM transfer through hypervisor-level replication.
PlateSpin (Micro Focus)—an old but still used product for "mass" server migrations, including physical → virtual and back.
Carbonite Migrate—focused on minimizing downtime, works with different OSes and hypervisors.

All three solutions are actively used in projects with critical workloads where business cannot afford even hours of downtime. Their minus is licenses and vendor dependency, which for SMB can be expensive.

Hyperscaler Solutions: Good but Not Always Legal

Large clouds offer their migration services:

AWS Application Migration Service,
Azure Migrate,
Google Migrate for Compute Engine.

They work great if the goal is to move to a hyperscaler. But there's a nuance: in Europe, data sovereignty comes to the forefront. In the financial, government, and healthcare sectors, such tools are often impossible to use: data must remain within the EU and under European jurisdiction. Therefore, despite the maturity of hyperscaler tools, in projects with strict compliance, they are used less frequently.

Local Cloud Providers

Europe is actively developing its own clouds, and many of them already offer native migration scenarios from VMware:

OVHcloud (France)—one of the leaders among OpenStack providers, supports migration tools at the service level.
IONOS Cloud (Germany)—focuses on compliance and certifications, including ISO and BSI C5.
Scaleway (France)—popular with startups and SMB for simplicity and transparent pricing.
Deutsche Telekom Open Telekom Cloud—a major player, operates on Huawei OpenStack, certified under strict German standards.

For companies that need to remain in EU jurisdiction and comply with Gaia-X, SecNumCloud, or NIS2 requirements, these providers become the priority choice.

Non-Obvious: Network Migrations

Companies often think about VMs and applications but forget about the network. And it's precisely the network that most often breaks during migration.

The difference between overlay and underlay networks can lead to unpredictable delays.
MTU problems (especially if the new stack uses VXLAN/GENEVE) can cause "strange" application failures.
Multicast is not always supported by cloud providers or requires special settings.

To avoid surprises, it's important to test network segments in advance: run packets, check MTU, make sure multicast and broadcast traffic works the same as in the VMware environment.

Downtime Minimization: Approaches and Architectures

One of business's main concerns when migrating from VMware is service downtime. Even a couple of hours offline for critical systems can cost more than the VMware license itself. Therefore, the architect's key task is to structure the process so that migration is as "transparent" as possible for users.

Live Migration and Replication

The most obvious option is live migration. Here data is synchronized in real-time, and switching is performed with almost no downtime.

Zerto does this through bidirectional VM replication: while the service runs in VMware, its copy is already synchronized to OpenStack or another cloud.
In the open-source world, DRBD Proxy plays a similar role, replicating block devices between clusters.

The minus is cost (in Zerto's case) and configuration complexity. But for banking and e-commerce systems, this approach is practically indispensable.

Dual-Write and Temporary Gateways

For databases and streaming systems, dual-write or temporary synchronization gateways are often used.

PostgreSQL can work through logical replication, when data is written simultaneously to the old and new database.
Kafka can be "duplicated" using mirror mechanisms, synchronizing topics between clusters.

Yes, this complicates the architecture during migration, but it reduces the risk of data loss during switching.

Canary and Staged Cutover

Experience shows: transferring everything "overnight" is almost always a bad idea. An error on one service can paralyze the entire process.

It's much more reliable to work by business services rather than by clusters. This staged approach resembles canary deployments in DevOps: first, we move part of users or transactions to the new environment, check stability, then expand.

Infrastructure as Code—Accelerator

To speed up VM and service redeployment in the new environment, Infrastructure as Code helps. For example:

Terraform + OpenStack provider allow describing VM profiles, networks, and storage as code.
This turns creating new environments from "manual magic" into a fast and reproducible process.

Thanks to IaC, you can simultaneously conduct migration and test "clean" environments, reducing the risk of surprises.

Economics and TCO: What's Important to Consider in 2025-2026

When discussing migration from VMware, the argument "it will be cheaper" almost always comes up. But the numbers aren't always obvious. To understand the real economics, it's important to calculate TCO (total cost of ownership) over a 3-5 year horizon.

VMware vs. OpenStack/Proxmox

After Broadcom's changes, VMware subscriptions increased by tens of percent, especially for SMB and mid-market. Over three years, VMware licenses + support cost more than migration to OpenStack or Proxmox with local integrator support.

OpenStack offers better scaling prospects but requires a team. Proxmox is cheaper and simpler but is mainly suitable for branches and small businesses.

Hidden Costs

Open-source is not "free." Companies pay with time and salaries: staff training, engineer certification, community support, or enterprise distribution subscription (Red Hat OpenStack, Canonical). These expenses should be considered, otherwise TCO can unexpectedly increase.

Economy of Scale

Migration is a chance to update "hardware." New AMD EPYC processors and CXL (Compute Express Link) technologies emerging in 2025 allow consolidating workloads and more efficiently sharing memory/PCIe resources. This reduces CapEx and makes the open-source stack competitive even with hyperscaler clouds.

European Support Programs

In 2025-2026, the EU Innovation Fund, Horizon Europe, and local tax benefits for "green" data centers are operating in Europe. Companies that invest in energy efficiency and local clouds during migration can offset up to 20-30% of expenses through grants and loans.

Cases from Europe: Practical Examples

To not stay in theory, let's look at how European companies are really leaving VMware and what they're choosing instead.

German Bank: OpenStack for Compliance

One of the major banks in Germany in 2024-2025 began migration from VMware to OpenStack. The reason—new NIS2 and DORA requirements that tighten rules for financial organizations.

The bank chose an OpenStack distribution with commercial support to guarantee long-term stability and certification availability. Additionally, they implemented IaC (Terraform) and Ansible so that infrastructure passes audits faster. The result—not only reducing dependence on VMware but also improving process transparency for regulators.

France: Government Sector and SecNumCloud

In France, the government sector went even further: several agencies abandoned VMware in favor of a provider certified under SecNumCloud. Here the key driver was data sovereignty—it's critical that personal and government data be processed within France and under French jurisdiction.

As a result, part of the systems was transferred to a local OpenStack provider, part remained in private data centers. This hybrid allowed meeting all ANSSI (national security regulator) requirements while maintaining scaling flexibility.

SMB in Benelux: Proxmox + IONOS Cloud

Medium-sized businesses in Benelux often choose a lighter scenario. Example—a network of medical laboratories that transferred branch offices to Proxmox and used IONOS Cloud in Germany for disaster recovery.

This approach allowed saving on licenses while simultaneously complying with GDPR: data remains in the EU, DR scenarios are ISO 27001 certified. For SMB, this proved to be the golden mean—without vendor lock-in and without overpaying for hyperscaler.

Conclusion: Strategy for "Life After VMware"

VMware won't disappear tomorrow—products will remain, large clients will use them for years to come. But trust is undermined: Broadcom's changes in licensing and support showed how risky it is to rely on just one vendor.

The European market is already responding to this challenge. More and more companies are switching to open-source stack—OpenStack, KVM, Proxmox—and choosing local cloud providers that comply with GDPR, NIS2, DORA, or SecNumCloud requirements. This is not just "savings" but a strategic move toward sovereignty and flexibility.

What to do today? Prepare a migration roadmap for a 12-24 month horizon. Even if you're not planning an immediate move, you need to understand: which services are tied to VMware, which alternatives are realistic, where the risks are, and how much it will cost.

The best first step is test sandboxes. Deploy OpenStack or Proxmox, try migrating a couple of services, compare TCO and SLA of different providers. In parallel, build a multi-cloud architecture where the key is not "sitting on one vendor" but having freedom of choice.

Life after VMware exists. And the sooner you start planning it, the less you'll depend on others' decisions tomorrow.

Comment

Similar texts

See more posts

21 Jun 2026