Leaving VMware is not a matter of recreating virtual machines by hand. Migration Manager is the piece of the FuturFusion stack that plans and runs the transfer of virtual machines from VMware to Incus, in batches, without reinstalling the guest systems. This guide explains the role of the tool, its architecture (appliance, sources, targets, disk transfer), and documents how far a lab without ESXi lets you go: deployment and connection can be validated, but a complete import demands a real vCenter or ESXi 8.0. For people preparing an exit from the VMware ecosystem.
What you will learn
- What Migration Manager does and its place in FuturFusion.
- Its architecture: appliance, source, target, disk transfer.
- The migration workflow, step by step.
- What a test without ESXi validates, and where it stops.
Prerequisites
- A target Incus cluster or Incus server, ideally running Incus OS.
- A VMware source (vCenter or ESXi 8.0) for a real migration.
- Some background on the stack, through Operations Center.
What Migration Manager is
Migration Manager was announced on 21 December 2025, alongside Operations Center, under the Apache 2.0 licence. It is a planning and migration tool aimed at VMware to Incus. It embodies the central argument of the FuturFusion stack: offering a fully open source exit path from VMware, without rewriting each virtual machine by hand.
Like the other recent pieces of the project, it is young. Take it for what it is: a migration tool that is usable and promising, not a platform proven across thousands of virtual machines. The model it manipulates stays easy to grasp, which helps scope an exit project.
The architecture: appliance, source, target
Migration Manager deploys as a dedicated appliance, on the same principle as Operations Center: an immutable Incus OS image exposing an API and a CLI (migration-manager). The appliance is the conductor; it carries neither the source nor the target virtual machines, it drives the transfer between the two.
Around it, the model rests on a few key objects:
| Object | Role |
|---|---|
| Source | A vCenter or ESXi endpoint the appliance queries to list and read virtual machines. |
| Target | The Incus cluster that will receive the migrated machines. |
| Network | The mapping between VMware networks and Incus networks. |
| Batch | A group of machines migrated together, with its own cutover window. |
The disk transfer is the delicate technical point. Migration Manager reads the source VMDK disks through the VDDK (VMware Virtual Disk Development Kit) exposed by nbdkit, then rebuilds a usable disk on the Incus side. That mechanism is what recovers the real data of a virtual machine, not just its definition.
The migration workflow
The sequence follows a logical order, from wiring the source to the final cutover:
- Declare the VMware source to the appliance. The tool checks connectivity and authentication.
- Inventory: Migration Manager reads the source inventory and records the properties of each machine (hardware, disks, network).
- Declare the Incus target and the network mapping.
- Build a batch of machines to migrate together.
- Transfer the disks in the background, with the source still running.
- Cut over: stop the source machine, run a final incremental transfer, start it on Incus.
Declaring a source takes one command, with the certificate fingerprint to establish trust:
migration-manager source add vcenter-prod https://vcenter.example.lan \ --trusted-cert-fingerprint <sha256># vCenter credentials are prompted interactively| Name | Type | Connectivity Status | Username || vcenter-prod | vmware | OK | administrator |An OK status confirms the appliance talks to the source. The inventory is then listed with migration-manager instance list, and any read problems surface in migration-manager warning list.
Testing without ESXi: what it validates, what is missing
Standing up a test vCenter or ESXi 8.0 is not always possible. You can then simulate the source with vcsim, the vSphere simulator of the govmomi project. That detour has real merits, and a clear limit worth knowing before committing to it.
What a test with a simulator validates:
- The deployment of the Migration Manager appliance and access to its API.
- Declaring a source:
source adddoes return anOKconnectivity status. - Discovering the inventory: the appliance sees the machines the source announces.
- Version compatibility, provided the source announces itself as 8.0 (the simulator hardcodes an older version, so it has to be rebuilt).
What a simulator does not allow:
The practical lesson has two halves. On one side, a simulator is enough to validate installation, connection and the tool's model, which already removes a lot of uncertainty about setting it up. On the other, the real migration (importing the full hardware profile, transferring disk blocks) stays inseparable from a production source: that is where the genuine rehearsal before a VMware exit takes place.
Key points
- Migration Manager migrates virtual machines from VMware to Incus, in batches, without reinstalling the guests.
- Announced at the end of 2025, under Apache 2.0, as a piece of the FuturFusion stack.
- It deploys as an Incus OS appliance and drives the transfer between a source and a target.
- The disk transfer goes through VMware's VDDK and nbdkit.
- A simulator validates installation, connection and version, but not the complete import or the transfer.
- A real migration demands a vCenter or ESXi 8.0 source with real virtual machines.