I replaced a broker's proprietary hypervisors with open-source. Without ever stopping trading. - Farid Saïd

In my first two articles, I wrote about an AI that audits my infrastructure, then an AI I build applications with. This time the topic is more down to earth, but it is one of the projects I am proudest of: migrating an entire financial infrastructure's virtualization, from a proprietary hypervisor to Proxmox , in production, without ever stopping the trading floor.

Here is why, how, and above all the traps, because that is where the real work hides.

Why touch a hypervisor that works?

That was the first question I got. Virtualization was running, it was stable. Why take the risk? Three reasons.

First, cost. The proprietary licenses cost me tens of thousands of francs every year. A Proxmox subscription is a few hundred euros. Over time, that stops being a budget line and becomes an argument.

Second, independence. When your virtualization layer belongs to a single vendor, the vendor decides the prices, the pace, the features, and when your version reaches end of support. In a small team, that dependency is a silent risk.

The third is the most important, and it is the thread of this blog: open source is text. A Proxmox config is files. So it is versionable in Git, readable by an AI, auditable, reproducible. A proprietary hypervisor is a black box that neither Git nor my AI agent can really work with. Moving to Proxmox was not just a change of software: it made my infrastructure legible to my tools.

The setup: two sites, a handful of servers, about twenty machines

To follow the rest, you need the setting.

On one side, the main data center: three recent servers (dual socket, plenty of RAM each) running a proprietary hypervisor, carrying most of the critical machines, including the domain controllers, the virtualized firewalls, and the market-data servers.

On the other side, a second site, with an aging Proxmox cluster on end-of-life hardware, hosting a dozen internal services: monitoring, Git repositories, portals, application building blocks. So the goal was not only to leave the proprietary vendor. It was also to consolidate both worlds onto one fresh Proxmox cluster, and keep only a minimal node on the second site as a recovery site. Two projects in one, and always the same rule: nothing stops.

First step: clean house

The best migration is the one you do not have to do.

Before touching anything, I went through the inventory carefully. Out of the twenty-odd machines, several had been powered off for months, obsolete, or replaced by something else: an old management server, templates, a directory connector migrated elsewhere, decommissioned application servers. Every machine removed before the migration is one less to migrate, test, and document. The scope shrank before the first switchover. It is the least technical step and the most profitable.

The constraint: the trading floor never stops

No question of shutting everything down over a weekend and praying. On a trading infrastructure, the big bang is forbidden.

So the method was a rolling migration . I consolidate the machines onto fewer hosts to free one completely. I reinstall that host as Proxmox. I create the cluster. I migrate the machines one by one into the new world, then free the next host, and start again.

The scary question is capacity: can a single host carry the others while you drain them? I did the math before, not during. Eight active machines consolidated came to about 80 GB of RAM out of 128 available, with headroom on the cores. It fit. You do not consolidate blind: you consolidate when the numbers say it holds. At every moment, the service ran in parallel on the old or the new platform. The desk saw nothing.

Hyper-V

LIVE<br>Proxmox

Rolling migration: free a host, reinstall it as Proxmox, move the machines over, then start again. The service runs in parallel, without interruption.

Three ways to move a machine

Moving a VM from one hypervisor to another is not a single operation. Depending on the machine, I used three approaches.

Conversion. For classic Windows servers, I shut the machine down, convert its virtual disk to Proxmox's format (qemu-img convert), recreate a KVM VM with a VirtIO controller and network card, then install the VirtIO drivers at boot so Windows sees its disk and network. Without those drivers, the installer sees neither disk nor card: that is the classic trap. For a critical trading server, the operation happens outside market hours, and only if its high-availability peer is healthy.

Container rebuild. For Linux services, I did not convert: I rebuilt. A lightweight LXC container, the application reinstalled cleanly, the data reimported. It is more work than copying a disk, but you gain density, you leave behind years of accumulated cruft, and you end up with a clean, documented, reproducible machine.

The domain controller case. That one, you never convert. Cloning Active Directory by...