No software license fee
The full product will be free of charge under a proprietary end-user license, with no per-VM or feature-tier fee. It will run self-hosted in infrastructure you control. Final license terms will be published before release.
Coming soon Enterprise-grade migration platform
VMware migration, engineered end to end.
Inspect the real guest. Plan the move. Read through VDDK HotAdd. Convert, validate, cut over, and hand off to open KVM infrastructure from one operator-controlled platform.
100% FREE Full product. Self-hosted. No software license fee.
- Self-hosted
- CloudStack · initial release
- Storage-only handoff
- Proxmox · integration in progress
Enterprise migration software Free means the product. Not a limited edition.
- 100% free
- No software license fee
- HotAdd first
- No silent NBD fallback
- Cold + warm
- Repeated CBT delta passes
- 50,000 VMs
- Synthetic inventory exercised
Why it is free
Free of charge, self-hosted, and clear about the terms.
Organizations leaving VMware need a migration platform that is complete, inspectable, and not tied to a license negotiation. The model below is straightforward. There is no premium tier behind it.
Closed source while the first release line stabilizes
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.
Independently funded, no paid tier today
Development is independently funded. Commercial support, training, architecture work, and migration services are planned for after the initial release. The business model is services, not software license fees.
Maintained by
Andrija Panić, PMC member of the Apache CloudStack project, with years of VMware-to-CloudStack and KVM migration work at ShapeBlue before this product. V2K Migrate is built from how hypervisors behave in production, not from a generic disk converter.
The actual product
Built to be inspected before it is trusted.
Every view below comes from the current V2K Migrate interface. The infrastructure and workload data are synthetic; the product surface is real.
Browse the read-only live demoWarm / CBT execution
See the entire migration, not a progress spinner.
Lifecycle state, topology, per-VM and per-disk progress, throughput, destination adoption, and operator controls stay visible in one operational surface.
Estate-scale discovery
Search the estate before you schedule the move.
Filter VMware inventory by vCenter, cluster, datastore, guest OS, power state, CPU, memory, disk footprint, inspection state, and migration status before building a plan.
Disk-derived evidence
Know what is inside the guest, not only what vCenter reports.
Read-only inspection derives operating system, firmware, disk, NIC, and network evidence from the guest disk so migration decisions are based on the machine that will actually boot.
Why VDDK HotAdd
Datastore-attached reads.
No NBD data stream.
Snapshot-backed VMDKs are HotAdded to Linux workers inside vSphere and opened as locally accessible whole disks. The migration engine reads from that attached block device; the control plane schedules and observes.
Control plane Inventory · Placement · Scheduling · Telemetry No disk payload relay
01 · Source Snapshot-backed VMDK VMware datastore
VDDK SCSI HotAdd 02 · Worker Locally accessible whole disk Read · sparse detection · CBT deltas
Controlled disk stream 03 · Destination Bootable KVM disk NFS/QCOW2 · Ceph RBD · LINSTOR/DRBD
The transport decision
HotAdd is the architecture, not an opportunistic optimization.
V2K Migrate validates datastore-aware worker placement before a plan starts. It does not hide a failed HotAdd path by silently moving bulk reads onto NBD.
Data-path property VDDK HotAdd NBD / NBDSSL
Disk access VMDK attached to worker VM Blocks served by ESXi over the network
Bulk read path Datastore and ESXi I/O path LAN / NFC path, port 902 by default
Read model Whole-disk block access on the worker Synchronous VDDK block requests
Operational constraint Worker must access the source datastore NFC host and vCenter session limits apply
One controlled workflow
More than a disk copy.
Coordinate discovery, evidence, preflight, transfer, guest conversion, validation, cutover, and destination adoption as one migration plan.
- Plan Operator decisions
- Move Worker data path
- Cut over Explicit gates
- 01
Discover and inspect
Synchronize vCenter inventory, filter the estate, and read OS, firmware, disk, and network evidence from guest disks.
- 02
Build the migration plan
Group selected workloads and map storage, destination, network, and per-VM settings before data movement begins.
- 03
Prove the path
Run preflight checks across workload eligibility, workers, storage, capacity, networking, and destination configuration.
- 04
Move cold or warm
Run full cold copies or scheduled warm CBT delta passes through bounded worker and disk concurrency.
- 05
Convert and validate
Apply KVM guest changes, verify transferred data, validate QCOW2 structure, and retain the conversion evidence.
- 06
Cut over and hand off
Gate the final delta and source shutdown, then complete destination adoption or a storage-only handoff.
Storage and destinations
One migration engine. Multiple target paths.
Write directly to the storage you operate, then hand the result to a destination integration or a platform-neutral storage workflow.
Source VMware / vSphere VDDK HotAdd + CBT
Migration engine Inspect + copy + prepare Worker data path
FileNFS / QCOW2
BlockCeph RBD
GatewayLINSTOR / DRBD
Initial release 01
CloudStack
The first deeply developed destination integration, with preflight, import, and operator-controlled adoption.
Integration in progress 02
Proxmox
A core destination platform for the product, with integration work underway for the initial release.
Initial release 03
Storage-only handoff
Migrated disks and machine descriptors ready for separate platform adoption or custom automation.
Under the hood
Move less data. Keep more control.
The engine is designed around the source read path, storage write path, and the operator decisions that make a migration safe to execute.
01
Inventory with evidence
Search large VMware estates and inspect real guest OS, firmware, disk, and network state before planning.
02
Cold and warm execution
Run cold copies or repeated CBT passes scheduled ahead of a controlled final cutover.
03
Purpose-built data path
Use VDDK HotAdd, allocated-block-aware reads, bounded disk streams, and direct target writes.
04
Preflight and hard gates
Block unsafe starts and imports when workload, worker, storage, network, or destination checks are stale or incomplete.
05
Telemetry at every level
Track plan, VM, and disk progress with throughput, ETA, pass history, and separate migration and import failures.
06
Evidence and accountability
Retain conversion artifacts and reports, with role-based access, audit records, explicit gates, and controlled cleanup.
Data-path focus
Purpose-built for migration throughput.
Source transport Strict VDDK HotAdd Read-only source path
Integrity checks BLAKE3 sampling + qemu-img Data regions + QCOW2 structure
Warm migration CBT delta passes Controlled final cutover
Disk concurrency Bounded parallel streams Per-workload control
Destination writes Zero-aware data path NFS / Ceph / LINSTOR
Large inventory 50,000-VM synthetic test Repeatable offline benchmark
Architecture
Control in one place. Disk movement on the data path.
Linux worker appliances operate inside the vSphere environment and write directly to the selected storage path. Destination adoption stays separate from the migration and storage layers.
Control plane · Go + PostgreSQL
Operator Web UI
Automation REST API
Control plane Plans · state · scheduler · telemetry Decides, gates, and observes. Never relays disk payloads.
Data path · inside vSphere
Bulk disk data stays on this row. HotAdd read → worker → direct storage write. The control plane sees progress, throughput, and gates — never the payload.
Source VMware / vSphere VMDK snapshot · read-only VDDK HotAdd + CBT
HotAdd read vSphere workers HotAdd reads · CBT · conversion Linux appliances. Bounded disk streams.
Direct write · zero-aware Storage NFS / QCOW2 · Ceph RBD · LINSTOR / DRBD
Adoption · separate stage Adoption CloudStack · Proxmox* · Storage-only * Integration in progress
- Bulk disk data
- Control requests and telemetry
- Adoption, after migration completes
Technical FAQ
Built for operators who will inspect the details.
The product is designed as an operational migration platform, not a single conversion command wrapped in a dashboard.
Inspect the live interfaceNearly 70kTracked Go code
50,000 VMsSynthetic inventory benchmark
Cold + warmCBT migration modes
HotAdd firstRead-only VDDK source path
What sits behind the interface?
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.
Is V2K Migrate really free to use?
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.
Is the source code available?
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.
Who is behind V2K Migrate, and how is it funded?
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. There is no paid tier today; commercial support, training, architecture work, and migration services are planned for after the initial release. The business model is services, not software license fees.
Is this only a VMDK-to-QCOW2 conversion wrapper?
No. V2K Migrate coordinates inventory, guest inspection, planning, preflight, cold or warm transfer, guest preparation, validation, cutover, reporting, and destination adoption. Conversion is one controlled stage inside the migration lifecycle.
Why is VDDK HotAdd the primary source transport?
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. 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.
Broadcom VDDK transport methodsHow are transferred disks checked?
The validation path combines BLAKE3 region sampling with QCOW2 structural checks through qemu-img. Migration failures and destination import failures remain separate operational states.
Which target paths are planned for the initial release?
CloudStack and storage-only handoff are initial target paths. Proxmox is a core target with integration work in progress. NFS/QCOW2, Ceph RBD, and LINSTOR/DRBD are represented in the storage architecture.
Has the interface been exercised with a large inventory?
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.
Coming soon
Get V2K Migrate launch updates.
V2K Migrate will be free to use and self-hosted. Leave your email for release news. Tell us which targets matter to you only if you want to.