VMware migration — exit VCF without breaking the application

Post-Broadcom VMware migration is a planned project, not an emergency. Done well, it produces a platform you control and, on the engagements we have modelled, a 30-60% cost reduction on the workloads that move. Done badly, it produces operational debt and a stalled migration that becomes the next year’s emergency. The difference is structured assessment, honest TCO modelling, and engineers who have shipped this in production.

Ænix runs end-to-end VMware migrations for organizations exiting VCF. Same engineers who built and operate Cozystack — the destination platform we typically recommend — work alongside your team for assessment, sequencing, and implementation.

Pairs with: Ænix Public Cloud Platform for anyone selling cloud — hosters exiting VMware Cloud Director (the most common 2026 pattern), MSPs, telcos, national operators; Ænix Private Cloud Platform for regulated enterprises exiting VCF for their own consumption. Free VMware Migration Checklist →.

Who runs a VMware migration in 2026

Organizations triggered by:

• Broadcom subscription renewal — renewal quotes at 2-5× the prior deal in the engagements we run; ELA breakage; mandatory VCF bundling. VCF pricing is not published, so read that multiplier as our observation, not an industry figure
• Sovereignty pressure — DORA, NIS2, sectoral rules forcing critical workloads to customer-controlled infrastructure
• AI / GPU economics — sustained workloads where VMware GPU model adds licensing complexity
• Repatriation strategy — VMware-on-cloud workloads moving to private infrastructure
• Modernization — old VCF estate where the upgrade path is also the exit path

If two or more apply, structured migration compounds. If renewal is comfortable and no other trigger, “stay and tune” is honest.

What an Ænix VMware migration covers

Forklift: the VM transfer engine in the platform

Ænix ships Konveyor Forklift — the Kubernetes migration toolkit for virtualization — as part of the platform, so moving a cohort off vSphere does not need a separate tool, a separate licence or a separate project. Forklift is the same open-source engine that Red Hat distributes as the Migration Toolkit for Virtualization; it drives virt-v2v and KubeVirt CDI underneath and is configured through Kubernetes objects rather than a GUI-only workflow.

How it is configured. Four object types cover a migration:

• Provider — the connection to vCenter (or directly to ESXi) and to the destination cluster.
• NetworkMap — each source port group maps to a destination network: the pod network, a specific Multus attachment, or ignored. Per-network networkIPMode decides whether a static address is preserved, replaced by DHCP, or left alone.
• StorageMap — each source datastore maps to a destination StorageClass, with volume mode (Block or Filesystem) and access mode set per mapping.
• Plan and Migration — a Plan is a set of VMs sharing parameters and mappings; a Migration executes it. One Migration runs per Plan at a time, and the power state of each source VM is preserved through the move.

Cold and warm. Both are supported from vSphere, and the difference matters for planning:

• Cold — the source VM is powered off, converted, then transferred. Conversion happens before data movement, so a VM that cannot be converted fails immediately instead of after hours of copying. This is the default and the right choice for anything with a maintenance window.
• Warm — the VM keeps running while its disks are copied incrementally using VMware changed block tracking (CBT), by default snapshotting every hour. At cutover the VM is shut down and only the remaining delta moves. Warm migration is not live migration: RAM state is not carried across, so there is still a reboot. It shortens the outage from “length of a full disk copy” to “length of the last delta”, which is the whole point for a large database VM.
• Warm requires CBT enabled on each source VM and each of its disks before the migration starts, and a VM tops out at 28 CBT snapshots. Windows guests additionally need VMware Tools present with Volume Shadow Copy Service and the VMware Snapshot Provider set to Manual or Automatic, or the snapshot step fails.

What virt-v2v does to the guest. VirtIO drivers are injected, VMware Tools and VMware-specific NIC configuration are removed, boot configuration is rewritten, and the QEMU guest agent is installed. Static IP addresses from vSphere are preserved, and Windows drive letters are kept. This is the automated version of the manual cleanup that makes hand-rolled VMware migrations painful.

VDDK, and the licence problem you inherit. The VMware Virtual Disk Development Kit is the fast disk-read path, and it is not optional in practice:

• Without VDDK, transfer falls back to a materially slower path.
• With VMs backed by vSAN, VDDK is mandatory — those migrations do not work without it.
• The VDDK cannot be redistributed. Neither Ænix nor the Forklift project may ship it. You download it from Broadcom under your own entitlement, build a container image from it, and push that image to your own registry. Storing it in a public registry may breach the VMware licence terms. The platform takes the image reference as configuration; supplying the image is the customer’s step, and it is on the pre-flight checklist for exactly this reason.

Sources other than vSphere. The same engine covers oVirt/RHV, OpenStack, OVA files and remote KubeVirt clusters as cold migrations; warm migration is available from vSphere and RHV only. vSphere 6.5 and later is supported.

What Forklift will not do. These are real and should be found during assessment, not during cutover:

• Windows VMs with Measured Boot cannot be migrated — they are rebuilt on the destination. Secure Boot VMs may need Secure Boot disabled on the destination side.
• Windows Server 2012 and 2012 R2 do not boot after conversion; virtio-win has no drivers for them and there is currently no workaround. Plan those as rebuilds or leave them until the guest OS is upgraded.
• Hibernated VMs are not supported; hibernation is disabled on the source first.
• ISOs and CD-ROMs must be unmounted, every NIC needs an address, and VM names must be DNS-compliant and unique.
• Vendor appliances shipped as OVAs may fall outside the vendor’s support terms once converted. Check before you migrate one, not after.
• Guest OSes that virt-v2v does not support can be moved in raw copy mode, but they land on emulated devices rather than VirtIO and may boot or perform worse. Treat it as a fallback, not a plan.

Forklift covers the disk and guest layer. It does not decide your tenant model, your address plan or your cutover order — that is what the assessment and the cohort sequence are for.

Upstream status, stated plainly: Forklift ships in the Ænix platform today. The work to expose it as tenant self-service VM import in upstream open-source Cozystack is in review and is not yet in a released Cozystack version. If you are running Cozystack yourself rather than the Ænix platform, you deploy Forklift alongside it for now.

Estimate the cost difference

Before committing, model the delta. Enter your estate size and current VMware price; the calculator shows the annual saving, the three-year net after migration, and how fast the migration pays back. For the standalone tool and methodology, see the VMware cost calculator.

How Ænix engages on VMware migration

The engagement structure mirrors our Platform Readiness Assessment with VMware-migration emphasis:

• Assessment (14-28 days) — VMware estate inventory, destination architecture, workload classification, cutover sequencing, Phase 2 roadmap.
• Phase 2 implementation (6-18 months) — Ænix engineers integrated with your team for migration cohorts. Parallel-run validation. Knowledge transfer throughout.
• Phase 3 (optional) — managed Cozystack operations after migration completes.

For VMware-specific destination guidance, see VMware alternative (singular, vendor-focused) or VMware alternatives listicle (plural, market scan).

Why Ænix specifically for VMware migration

• Cozystack-native experience. We built the destination platform many migrations end up on. Implementation effort estimates calibrated against work we’ve shipped.
• No hyperscaler bias. Recommendations reflect technical fit, not partner economics. We say “stay in cloud” when right.
• EU + Central Asia teams. Time-zone friendly; aligned with DACH/EU regulatory frameworks.
• Open-source destination. Cozystack is Apache 2.0; the platform you migrate to is one you own.

Typical migration timeline

100-VM estate typically completes in 8-12 months. 1000-VM estate in 18-24 months.

VMware migrations we’ve supported

If Phase 2 follows assessment, assessment fee credited subject to scope.

• VMware migration tools & strategy
• VMware alternative — destination focus
• VMware alternatives listicle — market scan
• Platform Readiness Assessment
• Cozystack

Ænix is the team behind Cozystack (CNCF Project), and we offer Ænix Platform — our commercial productized offering based on Cozystack.