How to migrate from VMware vSphere to Apache CloudStack without a big-bang cutover
If your vSphere renewal now means a per-core VVF or VCF subscription and you want to leave ESXi in stages rather than in one weekend, Apache CloudStack fits that plan. CloudStack can manage VMware vSphere and KVM side by side under one API and one management layer, so the move is a series of waves: each wave imports a group of VMs into a KVM zone, validates them, and retires the matching vSphere capacity. Nothing requires a single cutover date. The practical work is a per-wave import, and your existing vSphere clusters can keep running workloads that have not yet moved.
Platform and virtualization engineers with CloudStack operations skills usually own this work, with a network engineer and the application owners for each wave. The skills gap is real: CloudStack has its own zones, pods, clusters, primary storage, network offerings and accounts, so the team needs to be comfortable operating that model before the first import. Plan for the KVM import to need virt-v2v installed manually on every destination KVM host, because the CloudStack agent does not install it and the migration fails without it. Build that step into your host build process, and confirm the host distribution against the supported list in the CloudStack documentation before you start. For Linux VMs, cloning a running guest is the documented path; Windows VMs must be shut down gracefully first, so schedule those waves with outage windows. Confirm the exact import sequence and the storage behavior for your version in the CloudStack VMware to KVM import documentation and in a lab before committing to dates. Effort depends on the number of VMs, their operating systems, storage layout and how much network redesign each wave needs, so ask for a written scope that breaks down those factors per wave.
Which vSphere capabilities map to CloudStack and which need rework
This table maps common vSphere capabilities to their closest Apache CloudStack equivalents and marks each row as clean, needs rework or gap. Read the status column first, then the notes on how KVM cluster and storage design decide whether live migration and HA behave the way your vSphere estate does. Confirm HA and live-migration behavior for your chosen CloudStack release before you commit a cutover plan.
| Capability | CloudStack equivalent | Status and notes |
|---|---|---|
| vCenter inventory and hierarchy | Zones, pods, clusters, hosts and primary storage | Needs rework. Inventory is rebuilt as zones and clusters, so map vCenter folders and clusters to CloudStack objects before the first wave. |
| Compute orchestration | Instance deployment across KVM clusters through the management server | Clean for standard deployment. Placement depends on how you group hosts into clusters and tags, so plan cluster boundaries early. |
| Live migration (vMotion) | Live migration between hosts in a KVM cluster, dependent on shared storage | Needs rework. Confirm live-migration support and its storage prerequisites in your chosen release before relying on it for maintenance. |
| High availability (vSphere HA) | HA-enabled service offerings and host failure handling in the management layer | Gap to verify. Confirm HA behavior, failure detection and restart rules for your release, and test host failure in a lab first. |
| DRS-style placement | Deployment planners and host tags, without continuous automatic rebalancing | Gap. Expect manual or scripted rebalancing; confirm what the release offers before assuming automatic load balancing. |
| Multi-tenant accounts and projects | Domains, accounts, users and resource limits with resource accounting | Clean. Map vSphere roles and resource pools to CloudStack domains and accounts, and confirm quota and usage reporting for your needs. |
| Networking | Basic and advanced zones with isolated, shared and VPC networks | Needs rework. Rebuild port groups and distributed switch policies as CloudStack network offerings and zone networking, then test VLAN mappings. |
| Templates and images | Templates and ISOs registered to zones, converted on import | Needs rework. Import VMware images through the conversion path and retest guest tools, drivers and boot settings on KVM. |
| Storage (datastores, vSAN) | Primary storage pools on NFS, Ceph or local storage, with direct-to-storage-pool conversion in 4.22 | Needs rework. vSAN has no direct equivalent. Choose storage pools first, since live migration and HA depend on shared pools. |
| API automation | Native query-based API, CloudMonkey CLI and the Terraform provider | Clean for most scripts. Expect to rewrite vSphere API and PowerCLI automation, since CloudStack uses its own API model. |
What data and integrations move, and what you rebuild
A CloudStack move carries VM disks and their configuration across, but accounts, networks, offerings and templates must exist before the first import. Automation and backups do not follow the VMs, so each vCenter-driven process needs a named replacement and a test in your own environment.
VM disks through virt-v2v
Disks are converted to KVM format by virt-v2v on the destination host, not by CloudStack alone. For Linux VMs, the documented path clones a running guest first, which yields a crash-consistent copy, so application-level consistency still depends on the guest. Windows VMs must be shut down gracefully before import. Confirm that each guest OS you run appears in the supported list before scheduling a wave, and check direct-to-storage-pool conversion if your primary storage is shared.
VM metadata and configuration
CPU, memory, disk layout and NIC count are carried into the CloudStack instance, but VMware-specific settings such as tags, folder placement, custom attributes and guest-agent state are not automatically mapped to CloudStack constructs. List these per VM before the wave starts and decide which ones you recreate as tags or documentation. Confirm the exact fields your CloudStack version imports in a test VM.
Accounts, networks and offerings
CloudStack needs its own structure in place before any import: accounts or domains, zones, physical networks, guest networks, compute offerings matching your vSphere sizing, and disk offerings for each storage tier. Map each vSphere port group to a CloudStack network and confirm IP ranges and VLAN IDs with the network team. Without these objects, imported VMs have nowhere to land.
Templates and ISO library
Golden images and ISOs used in vSphere are not carried over as CloudStack templates. Decide which images you rebuild or register on KVM, which you keep as converted VM copies, and how Linux and Windows guest tools are handled after conversion. Record the owner and update cadence for each template so the library does not drift from what vCenter used to hold.
Backup jobs and monitoring
vSphere backup jobs and monitoring checks do not move with the VMs. Recreate each backup policy against the CloudStack instances and confirm that restores work on a KVM target before retiring the vSphere copy, since the backup product you choose may have its own VMware integration. Rebuild alerts for host, storage and VM health on the KVM hosts and remove vCenter-only alarms once their replacements are confirmed.
Terraform, Kubernetes and CloudMonkey automation
Scripts that called the vCenter API, PowerCLI or Terraform vSphere providers need new targets. CloudStack publishes CloudMonkey, a Terraform provider and a Kubernetes provider, so map each existing workflow to one of these. Review scripts for hard-coded vSphere object names, and test each replacement in a non-production zone, since the CloudStack API and provider versions must match your management server release.
The migration sequence from inventory to decommission
This sequence moves vSphere workloads into a CloudStack KVM zone in controlled waves, with each step closing on a written output so that ESXi hosts are retired only after the workloads on them have been verified on KVM. Every wave keeps a tested rollback path until the business owner signs off.
Classify the vSphere inventory
Your team lists every VM with its guest operating system, disk layout, network port groups, attached devices and dependencies on other systems. Each VM is tagged as a Linux candidate for cloning while running, or a Windows candidate that needs a graceful shutdown window, and anything with vSAN-backed disks, unusual firmware or licensing tied to hardware is flagged for separate handling. The output is a classified inventory with an owner, a wave assignment and a rollback contact for each VM, reviewed by the application owners. Confirm the current import rules for your guest types in the CloudStack documentation before you tag them.
Install virt-v2v on every destination host
The virt-v2v binary is not installed with the CloudStack agent, so your platform team installs it manually on each destination KVM host. Confirm that each host runs one of the supported distributions listed in the CloudStack VMware to KVM import documentation, such as AlmaLinux, Red Hat Enterprise Linux, Rocky Linux 8 or 9, or Ubuntu 22.04 or 24.04 LTS. Skipping a host causes the migration to fail on that host, so the check is run host by host. The output is a host register showing the installed virt-v2v version and distribution on every KVM host in the zone.
Build the KVM zone and storage pools
Your cloud team creates the CloudStack zone, pods, clusters and KVM hosts, then defines primary storage pools that the converted disks will land on. Networks are mapped to the zone's traffic labels so that VM NICs keep the VLAN and IP design they had under vSphere. Ask the vendor or community to confirm how direct-to-storage-pool conversion behaves with your chosen storage type before relying on it. The output is a validated zone where a test VM can be started, reached on its intended network and deleted cleanly.
Run a pilot wave
Your team selects a small set of low-risk VMs, ideally one Linux and one Windows machine, and imports them through CloudStack. Each pilot VM is checked for boot success, disk integrity, network reachability, service health and guest drivers, and the import task is recorded in the VM Import Tasks view. Application owners sign off on functional tests, and the rollback procedure is rehearsed by returning the VM to vSphere. The output is a validated pilot VM set and a signed-off rollback plan that every later wave must follow.
Operate both hypervisors under CloudStack
During the parallel run, the remaining vSphere hosts stay in production while new and migrated workloads run on KVM, both managed through the same CloudStack API and user accounts. Your operations team adjusts monitoring, backup jobs, change control and access roles so each VM has one authoritative record in CloudStack. Capacity is tracked on both sides so that a failed wave can be absorbed without overloading a host. The output is a single inventory view in which every VM is marked as on vSphere, on KVM or pending, and the team has reviewed it weekly.
Cut over remaining waves
Each wave is scheduled with its application owners, shut down or cloned according to its classification, converted into the KVM zone and checked against the same acceptance tests used in the pilot. Failed VMs are rolled back under the approved plan before the next wave begins, and each cutover record notes the import task, the test results and any configuration changes. Ask your partner or the vendor to confirm the handling of any VM type outside the Linux and Windows cases covered in the documentation. The output is a cutover log that shows every wave closed with acceptance evidence.
Decommission the ESXi hosts
Once no production VM remains on a host, your team removes it from vCenter, retains the final configuration and disk exports required by your records policy, and wipes or destroys the storage according to your data handling standard. Hardware is reclaimed or disposed of, and the CloudStack inventory and CMDB are updated to reflect the retirement. Review the Broadcom subscription and support status of any perpetual licenses you retire, and confirm the license terms with your account team. The output is a decommission record for each host, approved by the infrastructure owner and the security team.
What drives migration cost and duration, and how to control each driver
This table lists the main cost components and drivers of a vSphere to CloudStack move and the controls that keep each one manageable. Read each row as a lever: the driver explains why it changes effort, and the control shows what to fix in scope before work starts. No fixed figures are given, so use the table to build a written scope and a quote.
| Driver or component | Why it changes cost or effort | How to keep it under control |
|---|---|---|
| Staff time for inventory and testing | Every VM needs an owner, a dependency map and a test plan. Undocumented applications extend the work more than any other item. | Build the inventory from vCenter exports before scoping. Ask the partner to price inventory and test effort as a separate line item. |
| KVM host preparation | Each destination host needs a supported distribution (AlmaLinux, RHEL, Rocky Linux 8 or 9, or Ubuntu 22.04 or 24.04 LTS) and virt-v2v installed manually, because the CloudStack agent does not install it. | Standardize on one supported distribution and automate the virt-v2v install across all conversion hosts. Confirm the exact package set with the CloudStack import documentation. |
| Storage and network build-out | Primary storage pools, secondary storage and VLAN or bridge layout must exist before the first wave. Moving data to a new pool type adds copy time and verification work. | Map existing SAN or NFS datastores to CloudStack pools early. Decide whether direct-to-storage-pool conversion (added in CloudStack 4.22) fits each pool type, and test it on a non-critical VM. |
| Windows VM share | Windows VMs must be shut down gracefully before import, so each one adds an outage window and manual checks for drivers and activation. | Group Windows workloads into planned maintenance windows. Ask for a per-OS runbook that covers driver checks and post-import validation. |
| Running Linux VMs (clone versus shutdown) | Cloning running Linux VMs avoids downtime but yields a crash-consistent copy, which needs application-level checks for databases and stateful services. | Classify each Linux VM by data consistency needs. Reserve the clone path for stateless or well-journaled systems and schedule shutdowns for the rest. |
| Shutdown windows and change approvals | Each wave needs business sign-off, rollback steps and a cutover time. Late approvals often cost more than the technical work. | Agree the wave plan and approval calendar in the written scope. Use a pilot wave to confirm timings before committing dates. |
| Network complexity | Firewall rules, load balancers, DNS entries and IP changes tied to VMware distributed switches or NSX must be rebuilt in CloudStack networking. | Document flows and dependencies per application. Limit the number of network models in the first phase and confirm NSX replacements separately if they are in use. |
| Operations skills and training | CloudStack operations differ from vCenter, covering zones, accounts, the API and resource accounting. Training and early operator time carry a real cost. | Budget training for the operators who will run the cloud, and ask the partner to include knowledge transfer and runbooks in the scope. |
| Ongoing support subscriptions (optional) | A paid support agreement with a vendor or partner recurs each year, while the software itself is Apache-2.0 licensed with no license fee. | Compare support options in the quote separately from migration work. For comparison, Proxmox VE publishes per-socket subscription tiers and Broadcom sells VVF or VCF per-core subscriptions, so ask what recurring cost each option carries. |
| Parallel running during the move | Running vSphere and CloudStack side by side means paying for both platforms, both sets of hardware and double monitoring until the last wave completes. | Shorten the parallel period by moving VMs in ordered waves and retiring hosts as soon as each wave is verified. Confirm renewal dates for vSphere subscriptions before setting the timeline. |
What usually goes wrong when moving vSphere VMs to CloudStack KVM
Most failed CloudStack migrations from vSphere trace back to a few preventable gaps: a missing conversion tool, the wrong VM state at import, unsupported hosts, and unclear mapping between the two hypervisors. Each card names one failure mode and the check that prevents it before the first wave runs.
Virt-v2v missing on destination hosts
CloudStack does not install the virt-v2v binary with its KVM agent, so the VMware import fails on any host where it was never added by hand. The failure often shows up only when the first VM is imported, which can be weeks after the hosts were built. Before scheduling a wave, confirm that virt-v2v is present and runs on every KVM host that could receive a converted VM, including hosts added later to the zone.
Crash-consistent clones of running Linux
Running Linux VMs can be cloned and imported while powered on, but the copy is crash-consistent, not application-consistent. Databases, message queues and any service holding writes in memory may need recovery on first boot, and some will not start cleanly. Plan a validation step for each application: check database integrity, replay or drain queues, and confirm services start before the VM is returned to users.
Windows VMs not shut down gracefully
Windows VMs must be shut down gracefully before CloudStack imports them. Forced power-off or a guest that is still applying updates can leave disks in an inconsistent state, and the import then looks successful while the guest fails at boot. Set a shutdown window per VM, record who owns the change, and confirm the guest reaches a powered-off state before the import task starts.
Unsupported KVM host distributions
The documented KVM host distributions are AlmaLinux, Red Hat Enterprise Linux and Rocky Linux 8 and 9, and Ubuntu 22.04 and 24.04 LTS. Hosts built on other distributions, or on a different release of these families, may run CloudStack but fall outside the import path that the project documents. Check every host against the supported list during build, and treat any exception as a risk to be accepted in writing.
Unclear network and account mapping
Running vSphere and KVM under one CloudStack management layer means port groups, VLANs, zones and accounts must map to each other explicitly. Imported VMs that land on the wrong network or under the wrong account lose access or cross tenant boundaries without an obvious error. Write a mapping table covering each VMware network, its KVM counterpart and the owning CloudStack account before the first wave, and review it with the network and tenant owners.
How the move differs by estate size and starting point
A small estate with a few vSphere hosts and mostly Linux virtual machines has the simplest path into CloudStack. The main work is building one KVM zone with a small number of hosts, installing the conversion tooling on each destination host and proving the pipeline on a handful of non-critical servers. Because Linux guests can be cloned while running, the cutover window is usually driven by application owners rather than by shutdown rules.
- Zone count: one KVM zone is usually enough to start, and the zone design can be revisited once the hosts are stable.
- Wave order: start with stateless or easily rebuilt Linux services, then move databases and stateful applications after the process has been rehearsed.
- Tenant model: a single account or a small set of accounts covers the estate, so resource accounting can stay simple at first.
- Host prerequisites: check that each host runs one of the supported KVM distributions listed in the CloudStack import documentation and that virt-v2v is installed on every host before the first clone.
- Operations load: one or two administrators can usually run the CloudStack management server, the database and the KVM hosts, but confirm this against your own on-call expectations.
Before committing, ask your partner to confirm which Linux guests have VMware Tools, custom disk layouts or vSAN-backed disks, since these determine which VMs need a different path. CloudStack VMware import documentation is the reference for the exact requirements.
A mixed estate with many Windows servers changes the sequence more than the architecture. Windows virtual machines must be shut down gracefully before import, so every Windows wave needs an approved maintenance window, a rollback plan and an owner who can confirm the application is healthy afterwards. Groups of Windows servers with shared dependencies, such as domain controllers, file servers and line-of-business applications, should move in the same wave.
- Wave order: move Linux and low-impact Windows workloads first to prove the tooling, then schedule Windows domain services and dependent applications as separate, tightly controlled waves.
- Zone count: plan one KVM zone for the first waves and add zones only where a separate failure domain, site or compliance boundary requires it.
- Shutdown planning: agree graceful shutdown timeouts per application so that a stuck service does not extend the window without a decision.
- Driver and tools checks: confirm which Windows guests need drivers or agents to run on KVM after conversion, and test each image type on a copy first.
- Account structure: keep accounts aligned with the business owners of the applications, so that quotas and resource reports match who approves each wave.
Before scheduling, ask for a written list of every Windows VM with its shutdown tolerance and dependencies, and confirm with the application owners who signs off each wave.
A service provider already running tenant accounts, quotas and self-service access starts with CloudStack's accounting model in place, so the migration is mainly about mapping existing tenants onto CloudStack accounts and domains. The decision that matters most is how many KVM zones to create and whether each tenant needs isolation that a shared zone cannot give. Tenant moves are negotiated with customers, so the wave order follows contract dates and change windows rather than technical convenience alone.
- Tenant model: map each existing tenant to a CloudStack account and decide whether sub-accounts or domains are needed for departments within it.
- Zone count: size zones around failure domains, data residency and any tenant that needs dedicated capacity, and document why each zone exists.
- Wave order: move tenants with the least customization first, and leave tenants with Windows-heavy or regulated workloads for later waves once the runbook has been proven.
- Quota and billing mapping: confirm how existing usage reports translate into CloudStack resource accounting before customers see the first invoice from the new platform.
- Dual running: keep tenants on vSphere and KVM under the same CloudStack management layer during the transition, with clear rules about which API each team uses.
Before committing a schedule, ask your partner to confirm how tenant networks, public IP ranges and existing self-service portal integrations will behave in each zone.
Questions teams ask before moving vSphere to CloudStack
What drives the cost of moving vSphere to CloudStack?
The cost is driven mainly by labor, the number and type of VMs, and the state of your hosts, not by a license fee, since CloudStack is Apache-2.0 licensed. Your one-time costs are planning, host preparation, conversion testing, cutover work and staff training. Recurring costs are your own operations staff, hardware, storage, backup tooling and any support contract you choose. Ask any partner for a quote that separates these components, lists which VMs are in scope, and states what is excluded, such as application testing or decommissioning. Your existing vSphere subscription terms also set how long you need to run both platforms.
How long does a vSphere to CloudStack migration usually take?
Duration depends on the number of VMs, their operating systems, how many application owners must sign off, how much storage must be converted, and how long your change windows are. Windows VMs need a graceful shutdown before import, so their waves are paced by downtime windows, while running Linux VMs can be cloned first. Your timeline should come from a written scope and a wave plan, not from a generic figure. Ask for a schedule that shows pilot, test, production waves and rollback steps.
Can our internal team run the migration without outside help?
Yes, if you have people who already operate KVM hosts, Linux, MariaDB or MySQL, storage and networking, and who can test conversions carefully. The main risks are gaps in CloudStack zone design, virt-v2v setup on every destination host and rollback planning. Teams with a small platform group often bring in a fixed-scope partner for planning, pilot waves or runbook documentation, then take over operations. DeployOpen plans, implements, documents and supports self-hosted platforms inside your environment, and any engagement is agreed in writing before work starts.
What skills, change windows and storage access does the work need?
Plan for skills in KVM administration, Linux, CloudStack management through its web interface, CloudMonkey or API, MariaDB or MySQL, and network design. You need change windows for Windows VMs, which must shut down gracefully before import, and approved windows for cutover waves. The import also needs network paths and credentials to the vSphere environment and access to the storage pools where converted disks will land. Confirm these access requirements with your security and storage teams before the first pilot.
Is it safe to run vSphere and KVM under CloudStack at the same time?
Yes, CloudStack is designed to orchestrate VMware vSphere and KVM hosts side by side under one management layer, which allows a phased move. Keep the two environments separated by zones, clusters and network design, and test that each cluster's storage, backup and monitoring work before moving workloads. Plan which VMs stay on vSphere until their wave, and document the rollback path for each wave. Confirm the coexistence model against the CloudStack documentation for your release.
Which KVM host distributions does CloudStack support for VMware imports?
The CloudStack VMware to KVM import documentation lists AlmaLinux, Red Hat Enterprise Linux and Rocky Linux 8 and 9, and Ubuntu 22.04 and 24.04 LTS as supported KVM host distributions. Check the current documentation for your chosen release before you build hosts, because support lists change between versions. The current release listed on the CloudStack downloads page is 4.23.0.0, with 4.22.1.1 as the current LTS release. Choose an LTS line for production unless you have a specific reason to use a regular release.
Does CloudStack need virt-v2v installed on each host?
Yes. CloudStack can import VMware VMs into KVM, but the virt-v2v binary is not installed with the CloudStack agent. You must install it manually on each destination KVM host, or the migration fails. Add this step to your host build checklist and verify it on every host before any wave. Release 4.22 also added direct-to-storage-pool conversion and a VM Import Tasks view, which you should test against your storage layout during the pilot.
How DeployOpen scopes and runs a CloudStack migration
DeployOpen plans, implements, integrates, hardens, documents and supports open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For a move from vSphere to Apache CloudStack, that work usually spans the CloudStack management server and its MySQL-compatible database, the KVM host build, the network and storage design that both hypervisors will share during the transition, and the runbooks for each wave. The first decision is where CloudStack will run and which hosts become KVM zone members, because that choice sets the host distribution baseline, the virt-v2v installation on each destination host and the change control around them.
Engagements are fixed-scope. Before work starts, scope, deliverables and timelines are agreed in writing, and a quote follows from that document rather than from a generic template. A useful scope for this migration names the number of VMs and their operating systems, which workloads are Linux VMs that will be cloned while running and which are Windows VMs that need a graceful shutdown, the storage pools in use, the networks that must keep their addressing, and the acceptance tests each wave must pass. Ask any provider, including DeployOpen, to list what is out of scope, such as application testing performed by your team, hardware procurement or vCenter decommissioning.
Ongoing support, upgrades and continuous testing are available as retainers. This matters for CloudStack because LTS releases receive fixes for a fixed window and both hypervisors must be kept patched while the estate is split. Confirm with the vendor and your own change board which CloudStack release line you will run and who owns each upgrade after handover. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications. Independent auditors and certification bodies perform those assessments, so the scope should say which evidence will be delivered to them.
