The Migration Tool Is the Product

I want to be precise about what kind of artifact the importer is, because it is easy to file it under features and it does not belong there. Nobody builds a tool to read a competitor's disk format because it is technically interesting. It gets built because somebody has concluded that the market is not made of people choosing between two products. It is made of people who have already chosen and cannot get out, and the binding constraint on the vendor's growth is not persuasion, it is exit cost.

So here is the claim, and the rest of this is mostly an attempt to complicate it. When the destination starts writing the migration tool, the competition has moved from which product is better to how cheaply you can leave the one you have. That is a much healthier market than the one it replaces, and it is also a market in which the migration tool is the most load-bearing thing the vendor ships, because it is the only component whose value is measured entirely in somebody else's product.

It is an argument, not a feature. A feature is aimed at somebody weighing your product against another. An importer is aimed at somebody who has already decided and is stuck, which is a much smaller and much more motivated audience. What it says, in the form of software rather than marketing, is that the switching cost you have priced is lower than you think. That is a claim other vendors have to answer, and it is answered in engineering rather than in a slide.

The incumbent will never build it. Every migration path out of a platform gets built by whoever benefits from you leaving, which is never the platform. That asymmetry is why exit tooling is underdeveloped in every category, and why it appears all at once when a challenger decides the moment has come. Nobody documents their own escape hatch.

The mechanism is elegant, and its shape explains its boundary. The importer is a storage plugin, so it appears in the interface as somewhere disks come from, exactly like an NFS share or a Ceph pool. You add the ESXi host as an import source with admin credentials, its guests appear in a list, you pick one, choose target storage and a network bridge, and Proxmox builds a native guest whose disks are copies and whose settings are a translation.

What travels well is everything with a defined format. A disk image is a disk image; the bytes have a specification and a converter can read them. CPU count, memory size, firmware mode, the number of network devices, the presence of a CD-ROM: all of that lives in a configuration file with a schema, and mapping one schema onto another is ordinary work that somebody has now done for you. That is a genuine and substantial gift, and it is the part that used to eat the first two weeks of any migration project.

What does not travel is everything that was a convention rather than a format. The general rule, and it holds well beyond hypervisors, is that a migration tool can move any part of the system somebody wrote a specification for, and hands back every part that was only ever agreement between people. The disks were specified. The way your estate is actually operated was not, and it is about to be handed back to you in pieces.

The source guest has to be powered off. That single line removes from the tool's reach every machine somebody has declared cannot be stopped, and those are exactly the machines the project exists to move. A migration plan built on the importer is really two plans: one for the guests you can schedule an outage for, which the tool handles, and one for the rest, which is the actual project and which the tool does not touch. Discovering that split late is how a six-week estimate becomes a six-month one.

The network adapter arrives as a new device. New device means new MAC address, which means Windows does not inherit the static address, gateway or DNS from an adapter it now regards as absent, and will warn about a duplicate address if you simply retype the old one. It means a Linux guest may find its interface renamed. It means every DHCP reservation keyed to the old MAC now points at nothing, unless you set the MAC by hand on the new device. Each of those is five minutes. Multiply by the fleet.

Some state does not come across at all. A virtual TPM's contents cannot be migrated in, which matters enormously if a guest uses full-disk encryption with keys sealed to that device, and the documentation says plainly to have the manual recovery keys in hand first. And the imports have to be serialized: the source API's session limit is low enough that running many at once causes it to start refusing everything, so the guidance is roughly four disks at a time. The tool is not a batch job. It is a queue with a person in it.

Clustering here runs on corosync, and corosync runs on majority, which makes two-node clusters a trap that looks like prudence. Two votes; lose one; the survivor has half, not a majority, and refuses to run. You have bought a second machine and made availability worse, and I would say plainly that a two-node cluster with no witness is less available than one well-backed-up single node. The supported fix is a QDevice: the corosync-qnetd daemon on a third Debian-based host that need not be a hypervisor at all, reachable over TCP and outside the latency requirements corosync itself has, contributing the vote that breaks the tie.

None of this is a criticism of the design; I think the design is right and I would rather have a platform that stops than one that guesses. The point is that the importer moved the disks in an afternoon and the operational model takes longer than that to learn, and the second cost does not appear in any migration plan I have ever been shown. What made the incumbent feel safe was rarely a feature. It was that somebody in the room had already been through its failure modes.

It is a separate product with a separate failure domain. Proxmox Backup Server 3.2 shipped on 25 April, the day after the hypervisor release, and it is a distinct piece of software you install on a distinct machine. That feels like extra work and it is the right shape. A backup system that shares a host, a storage pool or a credential with the thing it protects is one incident away from being deleted alongside it, and the separation being visible in the product is better than it being an architecture diagram nobody drew.

A snapshot is not a backup, and this is where people find that out. A snapshot is a reference to blocks that still live in the same storage, on the same hardware, reachable by the same credentials. It survives a bad upgrade and a fumbled configuration change, and it survives nothing else: not the array, not the ransomware that arrived with the administrator's password, not the deletion of the pool. It is a very good undo button and it is not a copy.

The honest test is a question about credentials. Can the account that runs the cluster reach and delete the backup destination? If yes, then whatever compromises or confuses the cluster reaches the backups too, and you have one failure domain wearing two names. That single question is worth more than any retention policy, and it is answerable in about a minute for any system you own, which is why I would ask it before asking anything else.

Proxmox VE is AGPLv3 and every feature is in the free version; there is no functionality behind the subscription, and there is no OEM licensing arrangement to negotiate. What the subscription buys is repository access, and specifically the enterprise repository, which is the slower, more heavily tested package stream. The free no-subscription repository gets the same packages earlier and with less testing behind them. So the paywall is not on the software. It is on release discipline.

I think that is the honest thing to sell, and it is the part most likely to be skipped by somebody evaluating on price, because a package stream is not a feature and does not appear in a comparison. Be clear what skipping it chooses: you have elected to be the testing tier for a platform that runs your estate, which is defensible for a lab and strange for anything else. Subscriptions are per node and every node in a cluster is expected to carry the same level, which makes covering only some of them a mistake with a specific failure mode.

The reason large organizations hesitate here is almost never technical, and treating it as technical is the standard mistake. It is the ecosystem. The backup product with a certified integration and a support statement that names the platform. The monitoring agent with a maintained collector. The compliance tooling that knows how to enumerate guests. The configuration management database connector somebody wrote in 2019 that nobody now understands. The capacity planning tool. The vulnerability scanner's authenticated host check.

Each is a small dependency and together they are the actual estate. The disks are a solved problem, as I have spent this piece saying; the twelve products that assumed the disks were somewhere else are not, and several will answer a support request about an unsupported platform by declining to open a case. That is not a technical limitation you can engineer around. It is a contract, enforced by the vendor's risk department rather than by anything you can demonstrate in a lab.

So I have to narrow the claim, and further than I would like. For a small estate, a lab, a service provider running its own stack, or an organization whose tooling is already open source and script-driven, I think the case is close to overwhelming and the importer makes it more so. For a regulated enterprise with a certified backup product, a compliance regime and an auditor with opinions, I cannot get there on the strength of a migration tool, and I would be suspicious of anyone who could. The importer changed the cost of moving the disks by an enormous factor and changed the cost of moving the organization by approximately nothing.

I should be careful about what the artifact actually proves. An importer is evidence that a vendor understands where the market is, not evidence that the destination is better, and it does nothing at all about the reasons a competent person would decline. It is one release from a small company, five months old as I write this, and the 8.2 line has done nothing but mature quietly over the summer, which is the most that can honestly be said about it yet.

What stays with me is the shape of what the tool could and could not carry. It read the disks, because somebody had written down what a disk is. It handed back the addresses, the driver order, the quorum behavior and the question of who gets the email when a backup fails, because none of those were ever specified anywhere, they were just what the people who ran the place had agreed to. Every migration is the same discovery, in a different vocabulary. The formats move. The agreements have to be made again.