VMware migration, engineered end to end.

Nearly 70,000 lines of tracked Go code sit behind the product: approximately 45,000 lines of application code and 25,000 lines of tests. That figure does not include the React interface, SQL, scripts, documentation, generated output, or dependencies.

Yes. The full product will be free of charge under a proprietary end-user license, with no per-VM fee, restricted feature tier, or premium edition. It will run self-hosted in infrastructure you control. Final license terms will be published before release.

The initial release will be closed source. Our long-term direction is to explore an open-source release after the product and its support model mature; the timing and licensing model are not yet determined. Bug reports and release notes will be public from the first release.

V2K Migrate is developed and maintained by Andrija Panić, a PMC member of the Apache CloudStack project, with years of VMware-to-CloudStack and KVM migration work at ShapeBlue before this product. Development is independently funded. The full product remains free of charge. Any future paid services will be optional and separate from the software.

No. V2K Migrate coordinates inventory, planning, preflight, cold or warm transfer including warm cutover, optional data validation and read-only guest inspection, optional conversion, reporting, and destination import or storage-only handoff. Conversion is one controlled stage inside the migration lifecycle, after all source data has been copied.

A plan groups VMs into a migration batch. Its shared options apply by default, with per-VM overrides. Choosing CloudStack or Proxmox offers storage pools compatible with that platform; storage-only handoff uses manually defined pools without a destination platform. Choose network mappings, cold or warm migration, and, for warm migration, CBT delta sync and cutover settings. Both modes offer optional sampled data checks, read-only guest inspection, virt-v2v conversion, and Windows static IP preservation. Selecting Windows static IP preservation enables guest-disk inspection with libguestfs tools to read the registry and identify actual IP parameters and static versus DHCP addressing before conversion.

After creating a plan, run preflight checks for all its VMs. Green means OK. Orange warnings identify limitations or settings that cannot be honored as requested, but do not prevent starting the plan. A red blocker on a VM prevents the whole plan from starting until resolved. Starting the plan begins the selected cold or warm migration through VDDK or OpenVDDK HotAdd.

For CloudStack and Proxmox, Import is an operator action after a VM successfully completes its transfer and selected validation, inspection, and conversion stages. Optional automatic import and optional automatic power-on after import are planned for both platforms. These are separate choices: automate import, power-on, both, or neither. Automatic import will require all preceding stages for that VM to succeed. These automation options are not yet available in the current build. Storage-only handoff has no platform Import step: the migrated disks and machine descriptors are the result.

VDDK HotAdd attaches a snapshot-backed VMDK to a Linux worker VM and opens it through the ESXi storage stack as a locally accessible whole disk. Bulk reads therefore stay on the datastore and host I/O path instead of streaming every block through the NBD or NBDSSL LAN/NFC path, which uses port 902 by default. Direct datastore reads through HotAdd can be an order of magnitude faster than transferring disk data over NBD or NBDSSL; actual throughput depends on the environment. Broadcom documents NBD reads as synchronous and NFC as subject to host and vCenter session limits; those limits do not apply to HotAdd. The trade-off is explicit placement: the worker must be able to access the source datastore, so V2K Migrate validates datastore-aware worker eligibility instead of silently falling back to NBD.

When the operator enables sampled data checks, V2K Migrate compares 66 regions of 4 MiB per disk between the source and destination using BLAKE3, after the final copy and before guest conversion. Read-only guest inspection and Windows IP settings collection, when selected, also happen before virt-v2v modifies the destination image. No further source copy or CBT delta is applied after conversion begins. QCOW2 structural checks use qemu-img. Migration failures and destination import failures remain separate operational states.

Preflight detects the source vTPM and raises a VM-level warning before migration. V2K Migrate does not copy TPM state, certificates, sealed objects, or key material. Any destination vTPM is new and empty, so operators must confirm the BitLocker recovery and attestation plan before cutover.

Yes. The inventory path has been exercised against a repeatable offline dataset of 50,000 synthetic virtual machines. The public screenshots and interactive demo use synthetic data only.

CloudStack and storage-only handoff support NFS/QCOW2, Ceph RBD, and LINSTOR/DRBD. Proxmox supports NFS/QCOW2 and Ceph RBD. LINSTOR is not supported for Proxmox. Storage support is specific to each destination integration.

Yes and no. If you already have VMware VDDK libraries, good for you. It works with VMware VDDK 8.0.3 if you already have it, and with OpenVDDK, an independent drop-in library written from scratch, now in its final HotAdd testing phase. See openvddk.com.