Part one of this series listed the five places a VMware estate can go. Part two answered what actually replaces a vSphere cluster. Neither said how the virtual machines get there, which is the question both posts walk up to and stop short of.
What Does the Tooling Actually Do?
The migration service is built into the platform we run, and it works in four steps: you add the source environment, define a migration, let the disks replicate, then deploy. Replication uses Changed Block Tracking — the first pass copies everything, and each pass after it copies only the blocks that changed since the last one.
Crucially, that happens while the source virtual machines keep running. You are not scheduling an outage to copy a terabyte. You are scheduling an outage to copy whatever changed since the last sync, which is a much smaller number and, more importantly, a predictable one.
It is agentless in the sense that matters to most people: nothing is installed inside the guest. The service does stand up temporary worker machines of its own to do the work, which is worth knowing when you are reasoning about where the traffic comes from, but your VMs are not modified to participate.
Is It a Live Migration? No.
This is the part worth being blunt about, because the industry is not. Only the disks replicate. Memory and runtime state are not transferred. When you cut over, the virtual machine starts fresh on the target — it does not resume mid-flight the way vMotion moves a VM between hosts in a cluster.
So the guest reboots. Once, at a moment you choose.
Anyone telling you a cross-platform migration happens with no downtime at all is selling you something, and part one of this series was largely about learning to hear that. The accurate claim is better than it sounds: because the incremental syncs run ahead of time, the cutover window is short and roughly the same whether you are moving ten VMs or two hundred. It scales with your change rate, not with your estate. That is the property you actually want when you are planning a maintenance window with a business attached to it.
Plan a reboot per VM. Plan the order. Do not plan zero.
What Does It Cost?
The migration tooling is free. Not discounted, not bundled into a twelve-month commitment — there is no separate migration product to buy, because the tool only pays for itself if the workload ends up running with us. Our platform vendor gives it away for the same reason, and we have not invented a markup on top of it.
What is not free is people. If you want our engineers scoping the estate, mapping networks, sequencing the cutover and sitting on the bridge at 2am, that is Cloud Migration as a Service and it is a service with a price. Migrations that are not onto our platform are the same answer.
So: the tooling is free, the hands are not. We would rather write that sentence than have you discover it on the first call.
What Has to Be True Before You Start?
This is the genuinely useful part, and it is the part no provider publishes, because it is a list of reasons your migration might not work. Most stalled migrations stall here rather than in the copying.
- VMware Tools installed and current on every VM you intend to move. The service uses it to read guest network configuration and to take quiesced snapshots of running machines. An estate with years of un-updated Tools is a migration project with a prerequisite project in front of it.
- Storage that supports Changed Block Tracking — VMFS or NFS, in practice. Without CBT there is no incremental sync, and without incremental sync there is no short cutover.
- No disks in Independent mode. They are excluded from snapshots by design, which is exactly what breaks this.
- No software RAID inside the guest.
- No software-encrypted disks — BitLocker, LUKS or equivalent. The tooling has to read the block device and rewrite the boot path; an encrypted volume defeats both.
- Security agents must not block access to the bootloader or disks. This catches people out constantly. Endpoint protection and guest-integrity products are built to prevent precisely the operations a migration performs.
- On Linux: a working package manager, static addresses held in Netplan or NetworkManager profiles rather than hand-edited scripts, and at least 500 MB free on
/booton the RHEL family. LVM spanning several physical volumes needs a target sized to boot that layout. - CentOS 6 is not supported. If you are still running it, moving platforms is not your most urgent problem.
Run that list against your estate before you talk to anyone about timelines. It will tell you more about how long your migration takes than any provider’s brochure.
Does It Need vCenter?
No, and this surprises people. vCenter is optional as a source, but connectivity to vCenter alone is not sufficient — the migration service connects directly to the individual ESXi hosts to read the disks. It needs TCP 443 and 902 to each of them.
That is a firewall conversation, and it is usually the one that delays the start date. Estates where ESXi management lives on a tightly held network and only vCenter is reachable will need rules opened before anything replicates. Find this out in week one, not on the morning of the first sync.
Who Actually Runs It?
Either of us. The service is available to administrators and to self-service users, with project-level access control, so a customer with the appetite can run their own migration from the console and never open a ticket. It also handles the dull-but-essential parts: driver injection and removing source-specific components so the guest boots on new virtual hardware, network mapping, and preserving IP and MAC addresses where you want the machine to come up believing nothing happened.
Most people want help with the first few and then do the rest themselves. That is the right shape, and it is why the tool being free matters — you are not paying per VM for the ones you could have moved yourself.
When Is This the Wrong Tool?
When the source is not VMware. The built-in service is for vSphere estates coming to us. If you are moving from Hyper-V, AWS, Azure, oVirt or bare metal, the path is CMaaS, which runs on Coriolis — built by Cloudbase Solutions, who are a partner of ours. Coriolis covers far more source platforms and handles one-step and two-step migrations, and it is what sits behind the managed service.
Two tools, then, and they are not competing: the built-in one for VMware-to-us, self-service, free; Coriolis for everything else and for anything you want run for you.
What We Don’t Do
We do not migrate you and then leave you on a platform that is wrong for you — part two was explicit that an estate living inside VMware’s operations and analytics tooling should stay where it is, and a free migration tool does not change that answer. We do not promise zero downtime. We do not quote a migration timeline before someone has run the prerequisite list against the actual estate, because the honest answer to “how long” is “that depends what your VMware Tools situation looks like”.
And we do not charge for the tool. If a provider is quoting you a line item for migration software on a VMware move, that is worth a question.
Next in the series: Proxmox — where it fits, and where it does not. We sell it, so that second list is the one to read.
If you want to know whether your estate passes the list above, send us what you are running and we will go through it with you — including the cases where the answer is to stay put.
