Migrate from VMware vSphere to OpenStack

Migrate from VMware vSphere to OpenStack: is a self-service private cloud the right target?

OpenStack is the right target when your estate needs self-service, multi-tenant infrastructure with APIs for projects, networks and volumes, and not just a like-for-like cluster of hypervisors. If your main pressure is the per-core VVF or VCF subscription model Broadcom now applies to vSphere, and your teams are ready to consume infrastructure as a service, OpenStack deserves a serious evaluation. If you only need to keep VMs running and replace vCenter, a KVM virtualization platform will be a smaller project. Expect OpenStack to be a larger effort than a hypervisor move, because you are standing up a cloud control plane, identity, networking, block storage and image services before the first workload arrives. OpenStack is licensed under the Apache License, Version 2.0, and official projects must use that license under the OpenStack TC licensing requirements. The OpenInfra Foundation, which hosts the project, operates as part of the Linux Foundation. The software itself carries no license fee, so your cost is people and operations: platform engineers who run the control plane, a storage specialist for Ceph or your chosen backend, and a network specialist for Neutron overlays and physical fabric. Ask any partner to price those roles, the hardware, the upgrade effort and the training as separate line items, because those are the recurring costs you will carry. The risk is mostly operational. Release upgrades follow a six-month cadence, and only SLURP releases are designed for skipping versions, so plan your upgrade path before you commit to a release. Confirm with your own team whether you can staff an on-call rotation for the control plane, and whether your storage and network skills can carry a production cluster through its first year. If the answer is not yet, a phased path that starts with a smaller KVM cluster and adds OpenStack tenants later is often the safer route.

Which vSphere capabilities map cleanly to OpenStack and which need rework

This table maps common vSphere capabilities to their OpenStack counterparts and marks each row as clean, needs rework or gap. Where the answer depends on a design choice rather than a like-for-like equivalent, the row says so. Use it to scope the design workshop, not as a guarantee of feature parity.

Capability	OpenStack equivalent	Verdict and what to decide
vCenter inventory and templates	Nova instances, Glance images, flavors and metadata	Needs rework: templates become Glance images and flavors, and VMware-specific settings must be rebuilt. Plan an image pipeline before the first wave.
vMotion and live migration	Nova live migration on KVM	Needs rework: confirm live migration behavior, storage requirements and CPU compatibility in your chosen deployment tool before promising it to application owners.
High availability	Nova evacuation and host monitoring, set up per deployment	Gap in default behavior: vSphere HA restarts VMs automatically. Decide whether restart-on-failure is acceptable and how it is automated and tested.
DRS-style placement	Nova scheduler filters and weighers, with host aggregates	Design decision: placement policy must be defined through scheduler settings, aggregates and flavors rather than a built-in automatic balancer.
vSAN datastores	Ceph RBD for Glance, Cinder and Nova disks	Needs rework: Ceph is a separate cluster to size, network and operate. Its hardware and failure-domain design must be planned from scratch.
NSX segments and distributed firewall	Neutron with OVN for networks, routers and security groups	Needs rework: security policy is rebuilt as security groups and rules. Confirm the features your policies rely on are available in your release.
Roles and permissions	Keystone roles, domains, projects and groups	Design decision: map vCenter roles to a tenant model. Projects and roles are not a one-to-one copy of vSphere folders and permissions.
Identity federation	Keystone federation with SAML 2.0 or OpenID Connect	Needs rework: connect Keystone to your existing identity provider and map groups to roles through mapping rules.
Infrastructure as code	Heat templates or Terraform with the OpenStack provider	Needs rework: existing vSphere automation must be rewritten. Terraform is widely used for this, while Heat is native to OpenStack.

What data and integrations move, and what you rebuild

Moving from vSphere to OpenStack is a rebuild of the control plane, not a file copy. Disks and images carry over after conversion, while networks, identities, backups and monitoring each need a deliberate target design in the new cloud. The cards below separate what can be exported and reimported from what your team must configure again.

VM disks and images

Export each VM disk and convert it to a format the Glance image service accepts, then register it as an image with the right properties for the hypervisor. Before export, check each disk's format, whether the VM has snapshots that must be consolidated, and whether any disk sits on vSAN or encrypted storage, since those cases change the export path. Ask your OpenStack vendor or operator which image formats and conversion tools their deployment supports. Large estates should plan conversion capacity and storage on Ceph before the first wave.

Network definitions

vSphere port groups, VLANs and distributed switch settings do not transfer as objects. You rebuild them as Neutron networks, subnets, routers and security group rules, and map each old port group to a project-level network design. Document which VLANs stay external, which become tenant networks and which firewall rules were enforced in vSphere but must now be expressed in OpenStack security groups. Confirm the network back end you choose, such as OVN, before writing the mapping.

Identity through Keystone federation

Connect your existing directory to Keystone with federation over SAML 2.0 or OpenID Connect so users sign in with corporate credentials instead of local accounts. Mapping rules then match federated users from the trusted identity provider to OpenStack groups, roles and projects. Keystone can also federate to another Keystone instance. Define your group-to-project model before cutover, because mapping rules that assign the wrong role give users either too little access or too much.

Backup jobs and recovery

vSphere backup jobs, retention rules and restore runbooks belong to the old platform and do not move with the VMs. In OpenStack you choose how volumes and instances are backed up, for example through Cinder backups to Ceph, and you define retention, restore testing and who approves a restore. Recreate every backup policy as a tested job in the new environment, and keep the old backup catalog readable until restores from it are no longer needed.

Monitoring and CMDB links

Alerts, dashboards and configuration management database records point at vCenter objects, so they break at cutover. Re-point monitoring agents, update asset records and service maps to the new project, instance and network identifiers, and retire vCenter-based checks only after the replacements alert correctly. Ask your team which fields of the CMDB are authoritative, because OpenStack identifiers differ from vSphere names and will need a mapping table during the transition.

How tenant, project and network design changes after the move

The biggest conceptual shift is that vSphere's organizing objects do not map one to one onto OpenStack. Folders, resource pools and vCenter permissions become Keystone domains, projects and role assignments, and quotas are enforced per project by the compute, block storage and network services rather than by a resource pool's shares and limits. Before the pilot, decide how many Keystone domains you need. A common starting point is one domain for internal workloads and separate domains only where identity sources or administrative boundaries genuinely differ, such as a contractor population or a regulated business unit. Each project then needs a named owner who requests quota changes, and the quota numbers should come from a capacity model agreed with finance, not from the sizes of today's resource pools. Confirm the quota defaults and the role names your deployment will use with your own OpenStack release notes before you publish them to users.

Networking is where the design changes most visibly. Each vSphere port group that carried a VLAN becomes either a provider network, which is a shared Neutron network mapped to a physical VLAN and owned by the operator, or a tenant network that projects create for themselves and connect to external networks through routers. Decide early which existing VLAN segments must stay as provider networks because they reach physical firewalls, storage or legacy hosts, and which can be recreated as tenant networks during the waves. Define the external network pools and floating IP ranges with your network team, and document which projects may use them. Security groups replace much of the perimeter logic that teams previously held in distributed firewall rules, so inventory those rules first and confirm, with your chosen networking backend and its documentation, which behaviors you can reproduce before you assume parity. Test one representative application group end to end in the pilot.

The migration sequence from inventory to decommission

This sequence turns an unplanned move off vSphere into a staged program: each step produces a written artifact, from an inventory register and tested runbooks to a cutover sign-off and a decommission record. Teams can stop or pause after any step without leaving workloads in an unknown state.

Build the inventory and dependency register
The platform team, with application owners, lists every VM, template, network, datastore and external dependency in vCenter, then records owner, OS, data sensitivity, licensing tied to the VM, and upstream and downstream connections. Anything that depends on vSphere-only features, such as vSAN-backed disks or vSphere-specific appliances, is flagged for a decision. The output is a signed inventory register that every later step refers to. Confirm each owner by name before moving on.
Choose the deployment method and release
The team chooses between Kolla-Ansible, which deploys OpenStack services in Docker containers using Ansible, and OpenStack-Ansible, which deploys into LXC containers or on bare metal. Select a release by checking the OpenStack releases site: SLURP releases such as 2026.1 Gazpacho let you upgrade between SLURP releases as well as between adjacent releases, which suits a platform you intend to keep for years. The output is a written design decision record covering the chosen tool, release, control plane layout and upgrade path, reviewed by the operations team.
Build storage with Ceph and the control plane
Deploy the control plane and a Ceph cluster sized from the hardware recommendations, with a dedicated drive per OSD, shared SSDs for WAL and DB on HDD-based OSDs, and bonded network links across two switches. Point Glance, Cinder and Nova at Ceph RBD so images, volumes and guest disks share one storage tier, which lets VMs boot from Ceph without local hypervisor storage. Ceph is licensed under LGPL and has no paid edition from the project, so the cost is hardware and skilled staff. The output is a passing health check, a tested live migration path and a documented backup target for volumes and images.
Run a pilot tenant with identity and networks
Create a pilot project with its own users, quotas, networks and images, and connect identity through Keystone federation (SAML 2.0 or OpenID Connect) using mapping rules that assign federated users to groups, roles and projects. Test tenant isolation by confirming that a pilot user cannot reach another project's networks or volumes. Mirror a small set of non-critical VMs into the pilot to measure boot, network and storage behavior. The output is a pilot acceptance report with the access model and any gaps the operations team must close.
Convert images and classify workloads
Convert each VMDK or exported disk into a Glance image in the format Nova expects, record drivers and guest tools for each OS, and remove VMware-specific tooling. Classify each workload as rehost as a standard VM, rebuild as a cloud-native image, or retire. Schedule the conversion work by wave and keep a checksum for every image so a later rollback can prove what was deployed. The output is an image catalog with conversion logs and a workload classification sheet approved by the application owners.
Run both platforms in parallel by tenant
Serve different tenants from vSphere and OpenStack during a defined overlap, with each application owned by one platform at any moment. Keep backup, monitoring and patching running on both, and document which system is the source of truth for each application. Parallel running is where most configuration drift appears, so review the inventory register weekly. The output is a tenant-to-platform ownership table and a drift log that the change board reviews before every change.
Execute wave-based cutovers with rollback
Move applications in waves, each with a tested runbook that covers the data sync, DNS or load balancer change, validation tests, the rollback trigger and who approves it. Rehearse each wave in a non-production tenant before running it. Record the start and end state, validation evidence and any deviation. The output for every wave is a cutover sign-off signed by the application owner and the platform lead, held with the runbook in the change record.
Decommission vSphere after evidence review
Once the last wave is signed off, confirm that no workload, backup job, license or integration still depends on vCenter or ESXi. Retain exported configuration and backups for the period your retention policy and auditors require, then power off and wipe the hosts with a documented procedure. Review how the retained VMware licenses, support contracts and hardware are closed out with the vendor. The output is a decommission record that lists each host, the wipe method and the evidence location, approved by security and the platform owner.

Running vSphere and OpenStack in parallel without a big-bang cutover

Keep vSphere in service for every workload that is not yet ready, and send all new self-service requests to OpenStack first. This is the safest sequence because it shrinks the vSphere estate by choice rather than by deadline. Group the move into waves by tenant or by application tier, starting with stateless or well-understood workloads owned by a single team, and leave databases, licensed appliances and anything with complex network dependencies for later waves. Each wave should have a written rollback criterion agreed before the cutover window, such as a failed application health check, a backup restore that does not complete, or an error rate above the level the owning team accepted in advance. Name a single decision owner who can stop a wave without an escalation. DNS and network cutover deserve their own runbook per wave. Lower the TTL on records for migrated services well before the window, map each vSphere port group to a Neutron network and subnet in the target design, and confirm that firewall rules and load balancer pools reference the new addresses. Keep the old VM reachable and powered on for a defined period after cutover so rollback is a DNS or routing change, not a rebuild. Backup continuity matters as much as connectivity: during the overlap, both estates need protected copies, and a restore test from the OpenStack side should pass before the vSphere backup job for that workload is removed. Confirm with your backup vendor which of them supports both hypervisors, since the answer decides whether you run two backup stacks for the overlap. The overlap has a hard limit set by the vSphere side. Under Broadcom's published rules, perpetual ESXi hosts and vCenter keep running after Support and Subscription expires, but downloads of new patches and major version upgrades require an active support contract. Before you commit to a parallel period, confirm with your Broadcom account team which support status applies to each host and vCenter, and what it costs to keep patch access for the length of the overlap. Then set a dated decommission gate for each vSphere cluster, tied to the last wave, and review it at each OpenStack upgrade decision so that the platform you are leaving does not drift into an unpatched state. The gate should trigger a go or no-go decision, not an automatic shutdown, and it should name the workloads that must move before the date.

What drives OpenStack migration cost and duration

This table breaks the cost of moving from vSphere to OpenStack into its components, marking which are one-time and which recur, and names the drivers that push each one up or down. Use it to structure a written scope request, since no fixed figures for these components are published here and each estate differs.

Cost component	Who is paid or what it covers	One-time or recurring	What drives it up or down
OpenStack build: hardware and control plane	Compute, network and storage hardware, plus the controller nodes that run Keystone, Nova, Neutron, Glance, Cinder and Horizon. Deployed with Kolla-Ansible or OpenStack-Ansible.	One-time build, then recurring hardware refresh and support contracts	Number of hypervisors, redundancy targets and whether you buy new or reuse existing servers. Ask the scope to list each node role.
Ceph storage cluster	Hardware for OSDs, monitors and managers, plus the network. Ceph is LGPL-licensed with no paid edition from the project, so cost sits in hardware, staff and any third-party support.	Mostly one-time hardware, then recurring capacity growth and drive replacement	Dedicated drive per OSD, WAL and DB on shared SSDs for HDD-based OSDs, enterprise SSDs for metadata and bonded links across two switches. Check Ceph hardware guidance and benchmark before buying.
Operations staff and training	Internal engineers or a partner for day-two operations, upgrades and on-call. Training fees and time away from projects.	Training is one-time; the operations headcount recurs	Whether you already run Linux, Ansible, Ceph and Keystone in house. Teams starting from vCenter usually need the most training time.
Migration engineering per workload class	Engineers who convert images, rebuild templates, move databases and validate application behavior. Priced per class of workload, not per VM alone.	One-time per wave	Number of workload types, Windows and legacy images, appliances with license tied to hardware, and how much application testing each class needs. Ask for a written list of workload classes.
Network and tenant design	Design of projects, networks, routers and security groups in Neutron, plus mapping of existing VLANs and firewall rules.	One-time design, then recurring change control	Number of VLANs, routed paths, existing firewall complexity and how many tenants or business units will self-serve.
Identity federation	Integrating Keystone with your existing directory through SAML 2.0 or OpenID Connect, and writing mapping rules to groups, roles and projects.	One-time integration, then recurring access reviews	Number of identity sources, quality of group data in the directory and how many role mappings are needed.
Backup and monitoring rebuild	Replacing vSphere backup jobs and monitoring with OpenStack-aware tooling, and retaining evidence of restore tests.	One-time rebuild, recurring licenses or storage for backups	Backup target type, retention periods set by your policy, restore test frequency and whether existing tools support OpenStack.
Running two platforms during overlap	Duplicate capacity, licenses and staff time while vSphere and OpenStack run side by side, including any vSphere subscription still needed for the overlap.	Recurring for the length of the overlap	Length of the wave plan, how quickly workloads move and whether hosts can be retired or repurposed as each wave completes. Confirm current vSphere renewal dates with Broadcom or your reseller.

What usually goes wrong and how to prevent it

Most OpenStack migrations from vSphere stall for operational reasons rather than technical ones. The risks below connect the staffing decision, the storage and network layer that every VM depends on, the upgrade calendar, the image pipeline and identity mapping, so each one can be checked before the first wave moves.

Underestimating the operations team

OpenStack replaces one vCenter console with many services, a message queue, database and storage backend that someone must patch, monitor and troubleshoot at night. Teams that move VMs first and hire or train later usually end up with a cloud nobody can change safely. Before the design is final, list who owns Nova, Neutron, Keystone, Glance, Cinder and the Ceph cluster, and confirm they have trained on a lab deployment. Ask your partner which deployment method they will hand over, Kolla-Ansible or OpenStack-Ansible, and who will run it after go-live.

Ceph sized without benchmarking

Ceph is often the largest cost and the largest risk in an OpenStack estate because it backs Glance, Cinder and Nova disks. The Ceph hardware guidance says to benchmark before buying because no two clusters are alike, and to size memory for peak use rather than quiet periods. Measure your current vSAN or SAN latency and IOPS during month-end or backup windows, then require the design to meet those peaks with failure of a host or OSD still in place. Set the target in writing before purchase.

Weak network bonding across switches

A Ceph cluster that shares one switch or one uplink fails the moment that device does, and every VM on it stops with the storage. The hardware guidance recommends bonding network links across two switches, so storage and replication traffic survive a single switch failure. Check the top-of-rack design, the bond mode on each Ceph and compute host, and whether the public and cluster networks are separated. Test a switch power-off during a pilot wave and record how long I/O stalls before accepting the design.

Dedicated drives and metadata devices missing

Teams often reuse mixed drives for Ceph OSDs to save money, then see slow recovery and erratic VM latency. The guidance calls for a dedicated drive per OSD, moving WAL and DB onto shared SSDs for HDD-based OSDs, and enterprise-class SSDs for metadata. Write the drive layout into the design and check each host against it during build. Cheaper hardware changes the cost of the first purchase but usually raises the cost of every recovery event later.

Unplanned upgrade cadence and stable branch end of life

OpenStack moves on a six-month cycle, and a release leaves its stable branch maintained for approximately 18 months. Choose a SLURP release such as 2026.1 Gazpacho, because upgrades are supported between SLURP releases, and plan the upgrade window before go-live. Confirm with your partner which release the design targets and when its stable branch leaves maintenance. An estate that falls behind can end up on an unmaintained branch, so put the upgrade calendar into the operating budget from the start.

Image conversion failures on legacy OS

Converting VMware VMDK disks to Glance images breaks most often on old operating systems, custom boot loaders and VMs with VMware Tools dependencies on paravirtual drivers. Build an inventory of guest operating systems, flag anything out of vendor support, and test each conversion on a copy before cutover. Confirm the virtio drivers and cloud-init configuration in every image, and keep the original VMDK until the workload passes its acceptance test. Legacy systems that cannot be converted may need a rebuild rather than a lift, and that decision should be made early.

Identity mapping mistakes in Keystone

Keystone federation maps users from an external identity provider to groups, roles and projects through mapping rules. A rule that is too broad can grant administrator rights to every employee in a directory, and a rule that is too narrow locks out the teams who need to self-serve. Document each mapping rule with its owner, test it with one user from each role, and review rules against the tenant design before any project is opened. Confirm whether your identity provider speaks SAML 2.0 or OpenID Connect before the design begins.

How the move differs by estate size and starting point

When many internal teams need self-service compute, networks and storage through APIs, OpenStack is designed for that model. The migration becomes a platform program: you define projects as tenants, set quotas, design the network topology and build the storage backend before the first workload moves. Scope is larger than a hypervisor swap because identity, images, networking and chargeback all change at once.

Scope: Tenant model, Keystone federation with your identity provider, and Neutron network design usually take as long as the compute migration itself.
Staffing: Expect dedicated platform, storage and network roles, plus an on-call rota that covers the control plane.
Sequence: Build the control plane and one pilot tenant, then onboard application teams in waves rather than moving all vSphere workloads at once.
Storage: Plan a Ceph back end for Glance, Cinder and Nova disks early, since it shapes hardware purchases.
Upgrades: Plan a release path on the OpenStack cadence, using SLURP releases where you want longer gaps between upgrades.

Confirm with the vendor and your own environment which release train you will adopt and how long each stable branch is maintained before you commit to a version.

Questions buyers ask before migrating from vSphere to OpenStack

What does an OpenStack private cloud cost to run compared with vSphere?

OpenStack carries no license fee under the Apache License, Version 2.0, so the recurring cost is people, hardware, support and storage rather than per-core subscriptions. The main cost components are the operations team that runs the cloud, the server and network hardware, distributed storage such as Ceph, and any paid support contract you choose from a commercial distributor. Your current VMware renewal is the baseline to compare against, and the Broadcom subscription terms for vSphere Foundation or Cloud Foundation are the figures to pull from your own contract. Ask any integrator for a quote that separates one-time build work from recurring operations and support, and confirm whether storage hardware is included.

How long does a migration from vSphere to OpenStack take?

The timeline depends mostly on how much of the estate is cloud-ready, not on the OpenStack install itself. Drivers include the number of VM images to convert, how many workloads depend on vSphere-specific features such as vMotion-style placement or vSAN-backed disks, the network and tenant model you choose, and how many people on your team are learning the platform in parallel. Plan for a build phase, a pilot with a small set of tenants, and then waves of workloads. No duration is fixed here, so ask for a timeline in the written scope and confirm it against your change calendar and your upgrade cadence.

Can our internal team run an OpenStack migration without outside help?

A capable team can do it, but OpenStack is a broad platform, so most teams need help during the first build and the first upgrade. The work spans identity federation, networking, block and object storage, image pipelines and monitoring, and each area has its own failure modes. Assess the team honestly against the list of skills in the next question, then decide which parts to keep in-house and which to scope externally. A fixed-scope engagement can cover planning, implementation, hardening, documentation and handover, with ongoing support available as a retainer if the team wants it.

What skills does the operations team need to run OpenStack?

The operations team needs Linux administration, networking fundamentals, and working knowledge of the OpenStack services that handle compute, networking, block storage, images and identity. Because OpenStack deployments are built on Ansible and Docker or LXC containers, engineers also need comfort with automation, configuration management and container troubleshooting. Storage is often Ceph, so you need people who can read cluster health, handle OSD failures and plan capacity. Security skills matter for Keystone federation with SAML 2.0 or OpenID Connect and for patching. Assess these skills against your roster and plan training before the first production wave.

Should we choose Kolla-Ansible or OpenStack-Ansible?

Choose Kolla-Ansible if your team is comfortable with Docker containers and wants OpenStack services packaged as container images. Choose OpenStack-Ansible if you prefer services deployed in LXC containers or directly on bare metal, which some operators find closer to traditional server management. The 2026.1 deployment guides cover both tools, so confirm which one matches your current release and your team's existing Ansible and container practices. Also ask the integrator which option they support in production, how upgrades are tested for each, and who owns the inventory and secrets once the build is handed over.

When is OpenStack the wrong target for leaving vSphere?

OpenStack is a poor fit when you mainly need to keep the same virtual machine operations with fewer licenses and a smaller team. A like-for-like hypervisor cluster such as Proxmox VE or XCP-ng is usually simpler to run for that goal. OpenStack suits organizations that need self-service projects, quotas, APIs and multi-tenant networking for many internal teams or customers, and that can staff an operations function to match. If your estate is small or your engineers have no appetite for a larger platform, compare the options in the sibling pages before committing.

What does DeployOpen do, and what must our team provide?

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, which here means OpenStack and its supporting storage. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Your team must provide the hardware or cloud accounts, network and identity access, decisions on tenant and network design, change approvals, and the staff who will operate the platform after handover. DeployOpen does not issue audit reports or certifications, so independent auditors handle that step. Ask for a written scope that lists each responsibility on both sides.

What security and compliance work does a move to OpenStack add?

Moving to OpenStack shifts control of identity, network segmentation and storage encryption to your team, so those controls need written design and evidence. Identity should be federated through Keystone, which supports SAML 2.0 and OpenID Connect, with mapping rules that match federated users to groups, roles and projects. Storage on Ceph needs access controls and encryption decisions, and the messenger v2 secure mode can protect cluster traffic. Compliance readiness means preparing those controls and their evidence for your assessor, who will decide whether they meet the standard. Confirm the exact control set with your compliance lead before the design is signed off.

How DeployOpen scopes and runs an OpenStack migration

DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure, whether that is the client's cloud accounts, data centers or air-gapped networks. For an OpenStack move, that work covers the parts that decide whether the private cloud survives its first year: the choice between Kolla-Ansible and OpenStack-Ansible as the deployment method, the Ceph back end for Glance, Cinder and Nova disks, the Keystone federation to the client's existing identity provider, and the image conversion and tenant network design that the migration waves depend on. Each of these is a decision to record before any workload moves, and the scope document is where that record lives. Most engagements are fixed-scope. Before work starts, the written scope names the target OpenStack release, the number of hosts and VMs in each wave, the workloads excluded from migration, the acceptance tests for each wave and the handover documentation the operations team will receive. Ask for the same items in any quote you request from DeployOpen or another partner, and confirm the OpenStack release against the OpenStack releases site so the scope does not name a version that is already past its maintained phase. Hardening, backup design and the runbooks for upgrades are listed as deliverables, so they should appear in the scope with their own acceptance criteria rather than as implied work. OpenStack is not a one-time project. Upgrades, security patches, backup verification and tenant onboarding continue after the cutover, and many teams prefer to keep an external partner on a retainer for those tasks while their own operators build experience. DeployOpen offers ongoing support and upgrades as retainers, and the retainer scope should state which OpenStack release train is covered, how the operations team escalates issues, and who performs the upgrade rehearsals before each production upgrade. Confirm these terms in writing before the cutover, not after it.

Migrate from VMware vSphere to OpenStack