What a VMware to OpenStack migration involves
A VMware to OpenStack migration covers far more than moving disks. Before any virtual machine moves, the team needs a complete inventory of VMs, their network and storage dependencies, owners, operating system versions, licensing terms and data sensitivity. Discovery usually pulls this data from vCenter and from the network and storage layers. Each workload then gets a disposition: rehost, rebuild, replace or keep on VMware for now. Application owners should sign off on that inventory, because gaps found here shape every later decision.
Map each VMware feature your estate depends on to an OpenStack service, and record every gap. vCenter roles and permissions correspond roughly to Keystone domains, projects and roles, but the granularity differs and needs review. Compute moves to Nova, with flavors replacing hand-sized VM templates. vSAN or datastore volumes typically become Cinder volumes, often backed by Ceph. NSX segments, distributed firewall rules and load balancers translate to Neutron networks, security groups and load balancing services. Some NSX or vSphere automation behavior may have no direct equivalent, so confirm each item against the OpenInfra VMware to OpenStack Migration Guide and your own configuration.
Choose a migration pattern for each workload before scheduling any wave. Options typically include converting and moving the VM image, rebuilding the workload on a fresh image with its configuration managed as code, and replacing the service with an existing SaaS or managed alternative. Cut over in phases. Start with low-risk test and development workloads, then move higher tiers with a defined rollback path. Keep a coexistence period in which both platforms run and networks route between them. For each wave, name the approval gate, the rollback trigger and the data synchronization method, because database cutovers usually set the schedule.
Projects usually start with a trigger: pressure at a VMware license renewal, a decision to run a self-hosted private cloud, or a data center exit that removes room for the current estate. Whether to do the work in-house depends on skills and timeline. Teams with recent OpenStack operations experience and room for a pilot can often migrate on their own. Teams without that experience, or facing a fixed exit date, often bring in a partner for inventory, mapping and the first waves while they build operating skills. Ask any partner to list the inventory and mapping deliverables in the written scope before work starts.
What the work includes
Each workstream ends in a document or configuration your team keeps. The set moves from inventory and gap analysis through the target release and pilot to cutover, rollback and handover.
Workload inventory and dependencies
A register of every VM in scope, with its OS, resource profile, attached storage, network segments, external dependencies and a named business owner and technical owner. Check that the owners have confirmed their entries, since unmapped dependencies such as licence servers, backup agents and DNS-bound services are the most common source of surprises at cutover.
Feature comparison and gap register
A side-by-side map of the VMware features your environment uses, such as distributed switching, storage policies, vMotion-style live migration, clustering and backup integrations, with the OpenStack equivalent for each. Each gap is logged with a decision: accept, work around, or build. Confirm every equivalence against the release you select, not against general feature lists.
Target OpenStack release choice
A recorded decision on which release the cloud will run, weighed against the upgrade path after go-live. The current SLURP release, 2026.1 Gazpacho (released 2026-04-01), and the maintained 2025.1 Epoxy and 2025.2 Flamingo are candidates to check against the OpenStack releases site on the day of decision. Stable branches are maintained for about 18 months, so the choice sets your upgrade calendar.
Migration pattern per workload class
A defined method for each class of workload, such as stateless application VMs, databases, legacy appliances and VMs that need a guest OS or driver change. Each pattern states how disks are converted, how IP addresses and boot settings are handled and how data is synchronized before the switch. Ask for the pattern to be tested on a representative VM from each class.
Hardware reuse assessment
A review of the existing hosts, storage arrays and network switches against the hardware the target cloud needs, with a list of what can be reused, what must be replaced and what needs firmware or driver updates. It also covers how Ceph or other storage will be placed alongside compute. Confirm each host's support status with its vendor before reuse is approved.
Pilot wave and phased cutover runbooks
A pilot wave with a small set of low-risk workloads proves the patterns before production. Each later wave gets a step-by-step cutover runbook with timings, go and no-go checks, validation tests and a named approver, plus a rollback plan that states the trigger and the steps to return a workload to VMware. Handover documentation closes the engagement, covering operations and recovery procedures.
What drives cost and duration
This table lists the migration factors that change effort and schedule in a VMware to OpenStack move, why each one matters, and how to keep it manageable.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| VM count and size | Each VM needs image conversion, validation and a cutover step, and large disks or memory extend copy windows. | Retire idle VMs first, right-size from measured utilization and batch similar VMs into migration waves. |
| OS and application stacks | Each distinct guest OS and middleware version needs its own image, driver checks and test plan. | Group workloads by stack and standardize on a small set of supported images before migration starts. |
| Storage type | vSAN or external SAN data must be copied or re-presented to Ceph or another block backend, and copy throughput sets the pace. | Confirm the target backend's performance profile early and measure copy throughput on a representative VM. |
| Network complexity | NSX rules, distributed switching and microsegmentation must be rebuilt as OpenStack networks, security groups and firewall policy. | Document traffic flows per application and confirm which NSX features the target design replaces before wave planning. |
| Application dependencies and downtime windows | Tightly coupled tiers must move together, and agreed outage windows limit how many waves can run in each cycle. | Map dependencies from flow data, move each tier group in one cutover and agree rollback criteria per application. |
| VMware features with no direct equivalent | Features such as DRS policies, vendor-specific backup integrations or custom vSphere automation need replacement or redesign. | Use the OpenInfra VMware migration guide feature comparison to list gaps, then decide to keep, replace or retire each one. |
| Compliance evidence requirements | Assessors may expect change records, access logs, encryption settings and backup evidence for each migrated system. | Agree evidence requirements before design and record migration decisions per wave. Independent auditors assess the evidence. |
| Number of environments | Dev, test and production each need rehearsal runs, configuration parity and their own cutover tests. | Rehearse in non-production first and keep environment definitions and migration runbooks under version control. |
| Hardware reuse or new hardware | Reusing VMware hosts depends on compatibility and sizing, while new hardware adds procurement time and capital cost. | Assess existing hosts against compute and storage sizing before buying, and check them against the guide's hardware recommendations. |
Project phases and outputs
The sequence moves from an agreed inventory and design to a tested cutover, a decommissioned VMware estate and a team that can run the new cloud.
Discover and inventory the VMware estate
DeployOpen's engineers collect the VMware inventory with your platform team: hosts, clusters, VMs, storage, networks, dependencies and owners. The output is an inventory register that lists each workload with its resource profile, criticality and migration candidacy, reviewed and signed off by your team before design begins.
Design the target and decide feature gaps
Using the inventory, the team maps each VMware feature your workloads depend on to its OpenStack equivalent, covering compute, networking, storage, identity and backup. The output is a target architecture document and a gap register where each gap carries a recorded decision: accept, rework the application, or build an alternative. Your owners approve the register.
Run a pilot migration
A small set of low-risk workloads is moved through the full migration path on the target environment. The team measures conversion, boot, network and performance results against the source VMs and records what needed manual work. The output is a pilot report and a tested rollback procedure, which must succeed before any production wave is scheduled.
Execute migration waves
Workloads are grouped into waves by dependency, criticality and owner, and each wave is migrated under a written runbook with validation checks agreed with the application owners. The output per wave is a completion record showing each VM's validation result, open issues and sign-off from the business owner.
Cut over in phases
For each application, traffic and data are switched to the OpenStack workloads in a controlled cutover window, with the rollback procedure ready and tested in advance. The output is a cutover log per application and confirmation from the owner that the service runs correctly on the new platform.
Decommission VMware capacity
Once workloads are confirmed on OpenStack and a retention period for source VMs has passed under your data policy, the VMware hosts, licenses and storage are removed in a controlled sequence. The output is a decommissioning record that confirms what was retired, what was archived, and where hardware is reused. Confirm retention requirements with your compliance team first.
Hand over with operations runbooks
DeployOpen delivers the operations runbooks, configuration under version control, monitoring and backup procedures, and training for your operators. The handover is complete when your team has run the agreed operational tasks, such as a host maintenance drill and a restore test, and the runbook set is accepted. Timing depends on the agreed scope, and the written scope sets the schedule.
What stays in-house and what goes to a partner
This table shows who typically owns each migration work area, which skills the internal team must hold to run the result, and where a partner usually adds the most value.
| Work area | Typical owner | Skills required |
|---|---|---|
| Application owner validation | In-house: application owners and business sponsors | Knowledge of each workload's dependencies, peak periods, licensing and acceptable downtime |
| Application testing and business sign-off | In-house: application owners and QA | Test case design for business workflows, user acceptance criteria, change approval |
| Network and storage design | Partner leads, in-house reviews against data center standards | VLAN and routing design, MTU planning, storage network sizing, Ceph or other backend design |
| OpenStack deployment and operations | Partner builds, in-house takes over operations | Linux administration, Ansible or Kolla-Ansible, Keystone, Nova, Neutron, Cinder and Glance administration |
| Identity integration decisions | Shared: in-house identity team decides, partner implements | Directory administration, SAML 2.0 and OpenID Connect concepts, Keystone mapping rules |
| Pattern selection per workload | Partner proposes, in-house application owners approve | Knowledge of VMware feature usage per VM, such as snapshots, vGPU or clustered storage |
| Migration tooling and runbooks | Partner designs and documents, in-house reviews and rehearses | Scripting, change control documentation, rollback procedure writing |
| Pilot execution | Partner runs, in-house application owners validate results | Hands-on migration of representative VMs, log review, performance comparison |
| Cutover support | Partner provides engineers on call, in-house owns go/no-go | Change window coordination, incident response, communications to users |
| Post-migration operations | In-house, with optional partner retainer | Monitoring, capacity planning, OpenStack upgrade planning within maintained release branches, backup restore tests |
What usually goes wrong
Most failed VMware to OpenStack migrations trace back to decisions made before the first workload moves. Check each risk against your inventory, hardware and team before the plan is approved.
Incomplete inventory and hidden dependencies
Inventories built from vCenter folders often miss powered-off VMs, workloads created outside standard tooling, and systems on isolated networks. Dependencies such as DNS records, license servers, backup jobs and hard-coded IP addresses tend to surface only after cutover. Reconcile vCenter, your CMDB and network flow data, and have each application owner confirm the dependencies of their workloads.
VMware features without direct equivalents
Some VMware capabilities have no one-to-one OpenStack counterpart, and teams often assume parity until a gap appears during testing. Review distributed switch policies, vMotion-dependent maintenance habits, storage policies and third-party management tools against the feature comparison in the OpenInfra migration guide. For each gap, record a replacement, a workaround or a decision to retire the workload.
Hardware and storage sized after the design
Reused hosts are often selected by age or availability, without checking them against the hardware recommendations in the migration guide. Storage chosen for convenience, without sizing for the capacity, IOPS and latency of the migrated workloads, leads to slow boots and volume contention. Benchmark representative workloads and size compute, network and storage, including Ceph if you plan to use it, before reusing or ordering hardware.
Release selected without a support window
Teams sometimes choose the newest OpenStack release, or the one an existing deployment already runs, without checking its maintenance status. Stable branches are maintained for approximately 18 months, and after that only SLURP releases may enter an unmaintained phase. Confirm that your target release is in the maintained phase on the OpenStack releases site and plan the upgrade path beyond go-live.
Cutover without a pilot or rollback
Moving production workloads first, without a pilot group, leaves the team learning the tooling under business pressure. Without a tested rollback plan, a failed wave can strand workloads across two platforms with unclear ownership of their data. Run a pilot with representative applications, rehearse each wave, and define the rollback trigger, the decision owner and the data consistency steps before any production move.
Operator skills missing after handover
A migration can succeed technically and still fail if the team that inherits the cloud cannot operate it. Compute, networking, storage and identity components each need runbooks for patching, upgrades and incident response. Ask for runbooks, hands-on operator training and configuration kept under version control, and confirm in writing who owns each component after handover.
How the work changes by starting point
A small estate with few workload types keeps discovery manageable. The main effort is confirming that each workload has a named owner and a known dependency list.
- Discovery: Export the VM inventory from vCenter and check each workload against its owner, backup job and network dependencies.
- Pattern choice: Expect one or two migration patterns to cover most workloads, with a small set of exceptions reviewed individually.
- Network design: If the estate is mostly flat, map existing VLANs or port groups to a small set of provider networks in OpenStack Neutron.
- Cutover planning: A single maintenance window per application group may be enough. Confirm the change window with each application owner before scheduling.
Illustrative: a 40-VM estate with three application groups may need only a few cutover windows.
A large estate with mixed legacy operating systems makes discovery the longest phase. Guest OS versions, drivers and disk layouts decide which conversion steps are safe for each VM.
- Discovery: Record guest OS version, firmware, disk layout and VMware Tools status for every VM, and flag operating systems the vendor no longer supports.
- Pattern choice: Group workloads into migrate, rebuild and retire. Legacy systems that cannot run cleanly on the target platform often need a rebuild.
- Network design: Map static IP addresses and hard-coded routes, and plan for workloads that must keep fixed addresses during the move.
- Cutover planning: Schedule waves by dependency tier and start with low-risk groups so conversion issues surface early. Define a rollback path for each wave.
When NSX provides overlay networking, distributed firewall rules and load balancing, the network design becomes the larger part of the migration. Those services do not move with the VMs themselves.
- Discovery: Export NSX segments, distributed firewall rules, security groups and load balancer configurations. Identify which rules depend on NSX-specific objects.
- Pattern choice: Decide whether security policy will be rebuilt as OpenStack security groups, a separate firewall layer or a mix of both. Confirm what the target networking backend supports.
- Network design: Plan overlay networks, provider networks and routing to the physical fabric before any VM moves. Test east-west traffic paths in a staging project.
- Cutover planning: Move network segments and their policies together with the workloads that use them. Confirm with the network team which NSX features have no direct equivalent in the chosen design.
An air-gapped or sovereign environment changes how software, evidence and data cross the boundary. Packages, container images and documentation must be staged inside the boundary before discovery begins.
- Discovery: Confirm which inventory data may leave the boundary, and run discovery tooling inside the network.
- Pattern choice: Choose deployment tooling and artifact mirrors that work without internet access. Confirm how Kolla-Ansible or OpenStack-Ansible images and packages will be staged.
- Network design: Remove assumptions about external DNS, NTP and update servers. Confirm how federated identity reaches the internal identity provider.
- Cutover planning: Set a documented procedure for transferring images and backups across the boundary, and keep transfer records for your assessors.
Illustrative: a classified enclave may require a separate approval step for each media transfer.
A migration that runs next to an existing OpenStack or Kubernetes platform needs tenancy and placement decisions before pattern choice. Workloads may move in several steps across clusters, projects or hypervisors.
- Discovery: Identify which workloads already run on the existing platform, so that no workload is migrated twice or left out of scope.
- Pattern choice: Decide whether VMs join existing OpenStack projects, a new project, or whether any of them should run as Kubernetes workloads instead.
- Network design: Reuse existing tenant networks, floating IP ranges and security group conventions where possible. Confirm that IP address ranges do not overlap.
- Cutover planning: Align migration waves with the existing platform's upgrade and maintenance calendar. Confirm how Keystone identities and project quotas will be shared during coexistence.
What your team needs to provide
Migration planning stalls quickly when inputs arrive late, so the client team should have these ready before discovery begins. Start with read-only access to vCenter and the related management tools, such as the cluster, storage and network views, so the inventory reflects what is actually running. Alongside access, provide an accurate application owner list that maps each virtual machine to a business owner and a technical contact who can answer questions about dependencies.
Next, define change windows and downtime tolerances for each application. Record which workloads can stop briefly, which need a planned cutover window, and which cannot move until a rehearsal succeeds. Decide early which licensed VMware features your environment depends on, such as distributed switching, specific storage features or backup integrations, and whether each one will be retired, replaced or accepted as a gap. Those decisions shape the mapping work and should be signed off by the people who own the licenses and the risk.
For reuse assessment, provide access to the hosts you plan to keep, including firmware levels, drive and NIC details and any out-of-band management access. Share network and IP plans for the target environment, including VLANs, address ranges, DNS and routing, because migrated workloads often keep their addresses. Identity details matter too: name the source directory, its protocol endpoints and the attributes OpenStack will need for federation, so Keystone integration can be planned rather than improvised.
Governance is the last input. Name an executive sponsor, technical owners for compute, network, storage and identity, and a decision path for disputes. Agree on who will operate OpenStack after go-live and what that team will need in staffing and skills. The client keeps ownership of its data and approves each migration wave, rollback decision and final sign-off throughout the engagement.
Frequently asked questions
How is the cost of a VMware to OpenStack migration set?
The cost is set by a fixed scope agreed in writing before work starts, and the quote follows from that scope. The scope lists the workloads in the inventory, the target OpenStack services, the hardware you reuse or buy, the network and storage design, the migration pattern for each workload group, and the verification and handover you need. Costs rise with the number of workload types that need special handling, the number of network segments and storage backends, and the number of environments to build. Ask the quote to separate one-time migration work from recurring support, and to state which tasks your own staff will carry.
What drives the effort in moving workloads from VMware to OpenStack?
The main drivers are the size and variety of the inventory, the dependencies between applications, and how much of the VMware feature set each workload relies on. Workloads tied to NSX firewalling, vSAN policies, vendor appliances or host-bound licenses need separate designs. Downtime tolerance sets the cutover pattern, and the state of the target platform sets how much build work comes first. Staff availability and change windows also shape the calendar. An inventory and mapping exercise at the start shows which drivers apply to your environment before you commit to a timeline.
Can our own team migrate from VMware to OpenStack without a partner?
Yes, a team with Linux, networking, storage and OpenStack operations skills can run the migration itself, and the OpenInfra VMware to OpenStack Migration Guide is a useful reference. The harder question is whether the team can also keep normal operations running. Plan for dedicated time from named engineers during inventory, pilot waves and each cutover window, and expect the heaviest load on the people who know the applications best. Staff time grows with the number of application owners, the number of migration waves and the testing each wave needs. Confirm those numbers against your own inventory before committing staff.
Can every VMware virtual machine move to OpenStack?
Not always. Most general-purpose Linux and Windows workloads can move, but some need redesign and some should stay on VMware for a period. Check workloads tied to hardware or USB devices, appliances that ship only as VMware images, applications licensed per host, and VMs that depend on VMware-only features your target design does not replace. For illustration, a legacy appliance that ships only as a VMware image may need a vendor-supported alternative before it can move. Build the inventory first, classify each workload as move, rebuild or retain, and agree that list with application owners.
Does VMware licensing change whether we should migrate to OpenStack?
VMware licensing affects the timing and the business case, but the decision depends on your own contract terms, renewal dates and the workloads you still need to run on VMware. Ask your VMware licensing contact for your current terms and any changes at renewal, and ask finance to model the OpenStack side, including hardware, staff time and support. Keep these items separate in the comparison, since the license is one input among several. DeployOpen does not quote VMware license prices, so take none from this page. A parallel run period adds cost, so model it explicitly.
Can OpenStack replace VMware NSX and vSAN one for one?
No, not one for one. OpenStack provides networking through Neutron and block storage through Cinder, and those services use different models from NSX and vSAN. Many teams back Glance, Cinder and Nova with Ceph block devices, which covers some vSAN use cases with a different operating model. Map each NSX feature you use, such as distributed firewalling, segmentation, load balancing and VPN, to a Neutron, security group or third-party option, and confirm each mapping against the release you target. Where no supported equivalent exists, keep that workload on VMware or redesign it.
How DeployOpen works on this
DeployOpen plans and carries out the move from VMware to OpenStack inside infrastructure you control, following a written scope agreed before work starts. Each phase produces documented deliverables your team can review, test and run after handover.
How we scope
- Inventory of VMs, hosts, networks, storage and dependencies, mapped to the OpenStack services that will replace them.
- Written feature gap review covering VMware capabilities your workloads use and how each will be handled or accepted.
- Fixed-scope agreement defining migration waves, hardware reuse, cutover windows and the deliverables for each phase.
How we build
- Deployment of the OpenStack target on the tooling you choose, with Kolla-Ansible or OpenStack-Ansible configuration kept under version control.
- Migration pilot on a small set of non-critical workloads to validate conversion steps, networking and rollback before wider waves.
- Phased cutover runbooks with test evidence for each wave, including validation checks agreed with your application owners.
How we hand over
- Documentation of the target architecture, migration runbooks, configuration and the decisions made during the feature gap review.
- Knowledge transfer sessions with your operations team on daily tasks, monitoring checks and recovery procedures for the new cloud.
- Handover of retired VMware hosts and reused hardware records, so your team knows what was decommissioned and what remains.
How we support
- Ongoing support and upgrade planning are available as a retainer, scoped separately from the migration engagement.
- Post-cutover review of workload performance and open issues, with fixes tracked against the agreed scope.
- Confirm with DeployOpen during scoping which support hours, response paths and upgrade windows apply to your environment.
