VMware vSphere vs OpenStack: which fits your next platform decision
If you must renew or restructure vSphere now, the decision is a like-for-like virtualization cluster or a self-service private cloud. vSphere fits when you run a stable estate of VMs managed by a small team that wants the same operating model it has today. OpenStack fits when multiple internal teams or tenants need to request projects, networks, images and volumes through APIs, and when you can staff a platform team to run it. Broadcom now sells vSphere Enterprise Plus, vSAN, NSX and related tools only inside VMware vSphere Foundation (VVF) or VMware Cloud Foundation (VCF), so both paths start from a subscription decision. Perpetual ESXi hosts keep running after Support and Subscription expires, but you lose patch downloads and major version upgrades until you renew, which sets a deadline for either choice.
The decision turns on four things. First, tenancy: OpenStack Keystone organizes access by projects, roles and groups, and its federation documentation covers SAML 2.0 and OpenID Connect, so confirm whether your identity provider and mapping rules can match users to projects without manual work. Second, team size and skills: OpenStack is typically operated by a dedicated platform team, and the OpenStack 2026.1 deployment guides describe Kolla-Ansible and OpenStack-Ansible as two installation paths you must choose and maintain. Third, storage: Ceph can back Glance, Cinder and Nova disks, but a Ceph cluster is a separate system to size, benchmark and monitor. Fourth, upgrade tolerance: OpenStack releases twice a year, and you should plan which SLURP release you will stay on and when you will move.
Before you commit, write down the number of tenants, the self-service actions they need, the storage performance you must hit, and the staff hours you can give to operations. If the answer is one IT group managing a fixed set of VMs, a like-for-like hypervisor usually costs less to run. If the answer is several business units asking for capacity every week, OpenStack's API model may justify the operating cost. Ask any vendor or integrator to price both paths from the same written scope, including Ceph, backup, identity integration and training, so you compare one set of assumptions.
Which option fits which scenario
This table matches common situations to the platform that usually fits them better, with the condition that drives each choice. Read each row by asking which condition matches your estate, then check the trade-off before shortlisting. The main takeaway is that OpenStack earns its operations cost when self-service tenancy and API consumers are real requirements, not when the estate is simply large.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Single-site cluster run by a small team | Proxmox VE or XCP-ng | Workloads are mostly VMs, one site, and staff manage hosts directly through a web interface. Few people can absorb a full OpenStack control plane. |
| Multi-department private cloud with project isolation | OpenStack, or Apache CloudStack as a lighter alternative | Several internal teams need separate projects, quotas and networks, and the business expects self-service provisioning rather than tickets to a central admin. |
| Heavy consumption of APIs by internal tools | OpenStack | Automation pipelines, portals or billing systems call compute, network and block storage APIs directly, and the organization can staff an OpenStack operations team to maintain them. |
| Kubernetes-first estate | Harvester or KubeVirt, with OpenStack only if tenancy needs stay broad | Most new workloads are containers, and VMs are a minority that must sit next to them on the same Kubernetes skills. Confirm whether the team already operates Kubernetes in production. |
| Existing Ceph investment | OpenStack with Ceph, or Proxmox VE with Ceph | Ceph already runs in production with trained operators. OpenStack can back Glance, Cinder and Nova disks from Ceph, so the storage team's skills carry over. Confirm Ceph release support windows before choosing. |
| Mostly like-for-like replacement of a vSphere cluster | Proxmox VE or XCP-ng | The goal is to keep the same VM count and management model with fewer moving parts. OpenStack adds services to run that a like-for-like move does not require. |
| Phased exit from vSphere under one management layer | Apache CloudStack or OpenStack | Some hosts must stay on ESXi during the move and one API should manage both hypervisors. Confirm the VMware import path and KVM host requirements for the chosen platform. |
| Upgrade cadence the team can keep up with | Proxmox VE or XCP-ng for slower change, OpenStack for planned upgrades | OpenStack moves on a six-month cycle with SLURP releases between them. Teams that cannot schedule regular upgrades should weigh that cadence before committing. |
How data location, identity and compliance differ between the two
Both platforms can run entirely inside your own data centers, colocation space or client cloud accounts, so the differences lie in where data and control planes sit, how users authenticate, and what evidence an assessor can collect. The cards below set these decision points side by side so each can be checked against your own control requirements.
Where VM data and storage live
With vSphere, VM disks sit on VMFS, NFS or vSAN datastores managed by vCenter. An OpenStack deployment usually stores disks in Cinder, Glance and Nova backends, and a common choice is Ceph, where block devices back images, volumes and guest disks. Ask which datastore or pool holds each data class, who can read it at the storage layer, and whether backups and replicas stay in the same jurisdiction as the primary copy.
Hosting model on-premises and colocation
vSphere and OpenStack both run on hardware you control in your own data center or in a colocation facility, which keeps physical access and cage controls with your team and provider. Confirm how management networks, out-of-band access and the OpenStack control plane are placed, since OpenStack adds API endpoints that must be segmented and inventoried in the same way as the hypervisor hosts.
Client cloud accounts as a hosting model
OpenStack can be deployed inside a client's cloud account on virtual machines, which changes the shared responsibility split for the underlying hardware and hypervisor. This is an illustrative pattern, not a default. Confirm with the cloud provider which controls they inherit and which fall to your team, and document the boundary before any regulated workload is placed in that environment.
Identity integration with Keystone federation
OpenStack Keystone can federate with an external identity provider over SAML 2.0 or OpenID Connect, and mapping rules translate federated users into OpenStack groups, roles and projects. vCenter relies on its own identity sources, so the access model moves from vCenter roles to project-level role assignments. Test the mapping rules with each group your auditors will sample, because an incorrect rule can grant broader project access than intended.
Audit evidence for access and changes
Auditors will ask who changed a VM, a network or a storage pool and when. vCenter provides an event trail for its inventory, while OpenStack spreads evidence across Keystone, Nova, Neutron, Cinder and the Ceph layer, so log forwarding from each service must be designed deliberately. DeployOpen prepares controls and evidence for assessments but does not issue audit reports. Confirm the required control coverage and the evidence format with your auditor before you build the collection process.
Control ownership across the stack
Map each control to the team that operates it: hypervisor patching, Ceph and OSD health, OpenStack service upgrades, identity federation and backup restore testing. The split is wider on OpenStack than on a single vSphere cluster, so a responsibility matrix should exist before the first workload moves. Ask your auditor which controls they expect to see tested at each layer, and which they will accept from documentation alone.
Capabilities side by side, from supplied facts
This table compares vSphere, OpenStack and Ceph on the capabilities that decide between a like-for-like cluster and a self-service private cloud. Where the supplied evidence is silent, the cell tells you what to confirm with the vendor or in a proof of concept. Read it as a map of what is documented and what still needs testing in your environment.
| Capability | VMware vSphere | OpenStack and Ceph |
|---|---|---|
| Licensing and cost model | Perpetual licensing has ended. vSphere is sold only inside VMware VSphere Foundation or VMware Cloud Foundation as subscriptions, per Broadcom's licensing change. | OpenStack projects must be Apache-2.0 licensed. Ceph is LGPL-2.1 or LGPL-3 with no paid edition from the project itself, so cost sits in hardware, staff and any commercial support you buy. |
| Hypervisor and management plane | ESXi hosts managed through vCenter, the single management layer for a vSphere cluster. | OpenStack manages compute through Nova and can deploy on KVM. Confirm which hypervisor and compute drivers your chosen distribution supports before committing. |
| Multi-tenant projects and quotas | Tenant separation is typically handled with folders, resource pools and permissions. Confirm how far this meets your tenant isolation needs. | OpenStack is built around projects, roles and quotas for self-service. Confirm quota and role design with your own tenant model in a proof of concept. |
| APIs and automation | vSphere has its own management APIs and client tools. Confirm the coverage your existing automation depends on. | OpenStack exposes service APIs for compute, image, block and identity. Confirm API parity for the workflows your teams already script. |
| Block storage | vSAN is the VMware-native option, and it is sold within the same licensing bundles. Confirm the storage features you rely on before comparing. | Ceph block devices can back Glance images, Cinder volumes and Nova guest disks, so VMs can boot from Ceph without local hypervisor storage. |
| Object storage | Not covered by the supplied facts. Confirm with VMware whether any object service fits your requirement. | Ceph Object Gateway offers S3-compatible and Swift-compatible APIs, with multisite configuration and Keystone and LDAP authentication. Confirm S3 feature coverage for your applications. |
| Identity federation | Confirm federation options with your identity provider and VMware licensing before design. | Keystone federation covers SAML 2.0 and OpenID Connect and maps federated users to groups, roles and projects. Ceph Dashboard supports SAML 2.0 single sign-on. |
| Release cadence and upgrades | Broadcom's knowledge base states that downloads of new patches and major version upgrades require an active support contract. | OpenStack releases on a six-month cycle, with upgrades supported between SLURP releases. Stable branches are maintained for about 18 months, so plan regular upgrades. |
| Support model | Support is delivered through the VMware subscription and its support contract. | Community support is available, and commercial support comes from distributions or partners. Ceph's active releases, Tentacle and Squid, receive backports and security fixes, but confirm support terms with your chosen provider. |
What each side costs to own, one-time and recurring
Under Broadcom's current model, vSphere is sold as per-core subscriptions in VMware vSphere Foundation (VVF) or VMware Cloud Foundation (VCF). That subscription is the recurring line in the budget, and it renews on a term schedule. Perpetual licenses still define a support boundary: according to Broadcom's knowledge base, hosts and vCenter on perpetual licenses keep running after Support and Subscription expires, but new patches and major version upgrades require an active support contract.
- Recurring subscription: VVF and VCF fees recur each term and scale with licensed cores, not with the number of VMs.
- Core growth: adding hosts or cores during a hardware refresh raises the subscription directly. Ask how cores are counted per CPU and whether a minimum applies to your hosts.
- Unpatched perpetual hosts: hardware that runs after support lapses carries no new fixes, so exposure grows with each unpatched release. Budget for that risk as a real cost.
- Bundled components: vSAN, NSX, Site Recovery Manager and Aria Suite now come inside VCF or VVF, so a quote may include components you do not use.
- Exit work: migration has one-time engineering cost and temporary parallel hardware, both of which fall as migration waves complete.
Ask the vendor or reseller for a written quote that lists core counts, term length, bundled components and the renewal date for each perpetual host.
OpenStack carries no license fee for the software itself. Official projects must be licensed under the Apache License, Version 2.0, as set out in the OpenStack licensing requirements, and the OpenInfra Foundation hosts the project under the Linux Foundation. The cost therefore moves into people, support and upgrades. Deployment choice shapes the skills you need: the 2026.1 deployment guides cover Kolla-Ansible, which runs OpenStack in Docker containers, and OpenStack-Ansible, which deploys in LXC containers or on bare metal.
- No license line: you pay for staff, any support or partner work you buy, and the infrastructure you choose. The software itself adds no recurring fee.
- Operations team: a private cloud needs people for identity, networking, block and object storage, images, monitoring and on-call. This is usually the largest recurring cost, and it rises quickly when the team is thin.
- Upgrade labor: OpenStack releases on a six-month cycle, with SLURP releases such as 2026.1 Gazpacho (released 2026-04-01) supporting upgrades between SLURP releases. Stable branches are maintained for approximately 18 months, so each upgrade is recurring work.
- Partner or support time: fixed-scope implementation is one-time, while retainers for upgrades and monitoring recur. The cost depends on how much of the platform your own staff will run.
- Training and hiring: the choice of Kolla-Ansible or OpenStack-Ansible determines the skills to hire or train, which affects one-time onboarding cost.
Ask for a staffing plan with named roles, on-call coverage, the upgrade calendar and the release your partner will support.
Ceph is licensed under LGPL-2.1 or LGPL-3, and the project itself offers no paid edition, so storage cost is mainly hardware, networking and the people who run it. Ceph serves OpenStack images, volumes, backups and guest disks, so storage design often carries more budget than the OpenStack control plane. The Ceph hardware recommendations advise a dedicated drive per OSD, moving WAL and DB to shared SSDs on HDD-based OSDs, using enterprise-class SSDs for metadata, and bonding network links across two switches.
- One-time hardware: servers, data drives, shared SSDs for WAL and DB, and two switches for bonded links make up the largest up-front purchase.
- Sizing and benchmarking: Ceph's guidance is to size memory for peak use rather than calm periods and to benchmark before buying, since no two clusters are alike. Skipping this step is the most common way to overspend or underbuild.
- Recurring replacement: failed drives, spares and hardware warranty renewals recur over the life of the cluster. Enterprise SSDs cost more at purchase but reduce some of this risk.
- Release planning: the actively maintained releases are Tentacle (20.2.x, first released November 18, 2025) and Squid (19.2.x, estimated end of life October 31, 2026). Plan the move to a supported release before Squid reaches end of life.
- Support and skills: cephadm runs clusters as containers, and Rook is the alternative for Kubernetes. Third-party support is optional and recurs when you buy it.
Ask for a bill of materials with drive counts, memory per node, switch models and warranty terms, along with a benchmark plan completed before purchase.
How much operations effort OpenStack adds to a vSphere team
OpenStack is not one management console. It is a set of services: Keystone for identity, Nova for compute, Neutron for networking, Cinder for block storage and Glance for images, each with its own API and configuration. A vSphere team that works in vCenter will need to learn tenant design, where projects, roles and quotas replace folders and permissions, and API-driven provisioning, where a request that used to be a wizard becomes a template or script. Plan for a deployment tool as well. The OpenStack 2026.1 deployment guides cover Kolla-Ansible, which runs OpenStack in Docker containers driven by Ansible, and OpenStack-Ansible, which deploys into LXC containers or on bare metal. Pick one, then confirm with your integrator who will own its playbooks after handover.
Upgrades are the recurring cost most vSphere teams underestimate. OpenStack historically released on a six-month cycle, and since the 2022 cadence change, upgrades are supported between SLURP releases as well as between adjacent releases. Plan your estate around SLURP releases. The 2026.1 Gazpacho release is a SLURP release, and 2025.1 Epoxy is also a SLURP release still in the maintained phase, along with 2025.2 Flamingo. Stable branches are maintained for approximately 18 months, after which only SLURP releases may enter an unmaintained phase before end of life. Check the current phase of your release on the OpenStack releases site before you commit to a version.
Treat each cycle as a standing project: an upgrade routine, a staging lab that mirrors production networking and Ceph storage, and a rollback plan tested on that lab before production. Ask the operator or integrator to state in writing which releases they will support, how long each branch is covered, and what the upgrade work includes per cycle. Confirm your team's capacity for this routine against the skills gap above, because an OpenStack cluster that falls behind its release line becomes a security exposure rather than a cheaper platform.
Replacing vSAN-style storage with Ceph under OpenStack
In an OpenStack private cloud, Ceph block devices take the role that vSAN plays in a vSphere cluster: they hold the data that VMs depend on, so compute hosts do not need local disks for guest storage. Ceph RBD volumes can back Glance images, Cinder volumes and backups, and Nova guest disks, which lets a VM boot directly from Ceph without local hypervisor storage. That separation matters for live migration and host replacement, because a failed compute node does not take its guests' disks with it. It also means the storage design becomes a first-class decision that has to be made before the first workload moves, not after.
The Ceph project publishes hardware guidance that should drive the purchase. It recommends a dedicated drive per OSD, moving WAL and DB onto shared SSDs when OSDs sit on HDDs, and enterprise-class SSDs for metadata. Network links should be bonded across two switches so a single switch failure does not isolate storage. Memory should be sized for peak recovery load rather than calm periods, and the project advises benchmarking before buying because no two clusters behave alike. Ask your hardware vendor for a quote that states drive models, SSD endpoint ratings and switch redundancy so you can compare it against the guidance line by line.
Deployment choices follow from the platform team's skills. Ceph Tentacle (20.2.x) and Squid (19.2.x) are the actively maintained releases according to the Ceph releases page, so confirm which one your OpenStack release targets before you order hardware. The cephadm tool deploys the cluster as containers and bootstraps it from one Monitor and one Manager, and the Kubernetes route is Rook, a CNCF Graduated project. Ceph's source is licensed under LGPL-2.1 or LGPL-3, and the project itself offers no paid edition, so the recurring cost is staff time, support contracts from third parties if you choose them, and hardware refresh rather than a software subscription.
What a move from vSphere to OpenStack involves
The sequence turns a set of vSphere clusters into an OpenStack private cloud with tenants, self-service APIs and Ceph-backed storage, and moves workloads in waves with a rollback point for each. Each step ends with a check that the team can show to the business owners who approve the next one.
Inventory and classify workloads by tenant
Export the vCenter inventory, including VM hardware settings, networks, datastores, guest operating systems and owning teams. Classify each workload by owning tenant, by whether it needs an API to request resources on demand, and by whether it can run on KVM at all. Note any dependencies on vSAN, vSphere-only features, appliances that require VMware support, and software licensed per host. The output is a signed-off register that lists every VM, its tenant and its target wave, reviewed by the application owners and the security team.
Design projects, networks and quotas
Map each tenant to an OpenStack project, then define roles, Keystone group mappings from the identity provider, and the quota limits for compute, storage and networks. Design the Neutron provider and tenant networks, overlay ranges, floating IP pools and firewall policy, and decide how existing VLAN-based segments will be carried over. This is usually the longest step, because it needs agreement from tenant owners, networking, security and finance on who consumes what. The step is complete when the design document has been approved and each tenant has a test project with the agreed quotas.
Build the Ceph and OpenStack lab
Build a non-production OpenStack deployment, using Kolla-Ansible or OpenStack-Ansible as the 2026.1 deployment guides describe, and a Ceph cluster deployed with cephadm or Rook if you run Kubernetes. Follow the Ceph hardware recommendations for dedicated OSD drives, shared SSDs for WAL and DB where HDDs are used, and bonded network links across two switches. Benchmark storage and compute with workloads that resemble your production estate before choosing hardware. The step is complete when Glance, Cinder and Nova can all use Ceph, backups restore successfully, and a failure of one host or switch is tested and documented.
Convert and import images
Convert VMware disks to formats OpenStack accepts, typically by exporting VMDK files and converting them to raw or qcow2 with standard tooling, and build golden images with the drivers and guest agents that KVM needs. Remove VMware Tools and install the virtio drivers on Windows guests. Upload the images to Glance on Ceph and test that each one boots, gets an address, and passes the application owner's acceptance checks. The step is complete when a short list of approved images is available to each tenant and the conversion steps are written down as a repeatable runbook.
Run pilot tenants
Choose one or two tenants with low risk and a willingness to test the self-service model. Move a small set of workloads, have the tenants create and delete resources through the Horizon dashboard and the APIs, and record every issue in a defect log. Test backups, restores, live migration where it is in use, and the monitoring that the operations team will rely on during an incident. The step is complete when the pilot tenants have run their own workloads for a defined review period and the business owners accept the operating model in writing.
Migrate in waves with rollback points
Move workloads in waves grouped by tenant, dependency and business criticality. Before each wave, take a verified backup of every VM and record the source configuration so the VM can be started again on vSphere if the cutover fails. Schedule each cutover with the application owner, validate network connectivity, DNS and certificates, and keep the source VM powered off but intact until the owner signs off. The step is complete for a wave when each VM passes its checks and the rollback window agreed with the owner has closed without a need to revert.
Train the operations team before production
Operating OpenStack needs skills in Keystone, Nova, Neutron, Cinder, Glance, Ceph and the deployment tooling, and most vSphere administrators will need structured training and hands-on practice before they take on production duties. Confirm the on-call model, upgrade procedures and the release calendar for the OpenStack version you deploy, including which releases are SLURP releases. Ask any partner you hire to document the runbooks and to hand over the operations work in stages. The step is complete when the staff who will run production have passed their own restore, upgrade and incident drills in the lab.
Retire vSphere hosts
Once every workload in scope has run on OpenStack through its agreed review period, decommission the vSphere clusters in order of the wave plan. Keep the final backups and the vCenter configuration for the retention period set by your compliance team, remove licenses that are no longer needed at their renewal dates, and securely wipe the hosts before reuse. Update the configuration management database, the asset register and the disaster recovery plan. The step is complete when the vSphere environment has no production workloads, the retention copies are verified, and the decommissioning record is signed by the infrastructure owner.
Questions buyers ask before choosing OpenStack or staying with vSphere
How much does moving from vSphere to OpenStack cost over time?
The cost depends mostly on what you pay for each component and whether it recurs. OpenStack is licensed under Apache-2.0, so there is no license fee for the software itself. Your spend goes to hardware, storage (often Ceph), networking, operations staff, migration labor, training and any support contract you buy from a vendor. vSphere under Broadcom is a recurring subscription per core in VMware Cloud Foundation or vSphere Foundation, so its cost renews each term. OpenStack's recurring costs are mainly staff time, hardware refresh and optional support. Ask for a quote that separates one-time items (design, build, migration, training) from recurring items (support, staff, hardware replacement), and that states which assumptions drive each line.
How long does a vSphere to OpenStack migration take?
No single duration applies to every estate, so treat any published timeline as a starting point to check against your own inventory. The main drivers are the number of workloads, application dependencies, the network and tenant design you need, how much storage must be built before the first wave, and how quickly your team learns the platform. Release timing also matters. OpenStack 2026.1 Gazpacho, a SLURP release, came out on 2026-04-01, and 2026.2 Hibiscus followed on 2026-09-30. Upgrades are supported between SLURP releases, so choosing a SLURP release for production simplifies later upgrades. Ask the provider for a wave plan with dependencies, cutover criteria and a schedule written into the scope.
What skills does an OpenStack team need that vCenter administrators may not have?
vCenter administrators already understand hypervisors, clusters and storage, but OpenStack adds several services that work together. You need people who can operate identity (Keystone), compute (Nova), networking (Neutron), images (Glance), block storage (Cinder) and the deployment tooling. Kolla-Ansible deploys OpenStack in Docker containers with Ansible, and OpenStack-Ansible deploys in LXC containers or on bare metal, so your team must know one of these methods well. Storage usually means Ceph, which requires its own skills. Upgrades need a planned process because stable branches are maintained for about 18 months. Map each service to a named owner, and ask for a training and handover plan in writing before the build starts.
Can our own team run an OpenStack migration without an outside partner?
Yes, some teams do, but it depends on prior OpenStack experience, available staff time and how much risk you can accept in the first production cluster. The questions to answer honestly are whether someone has already built and upgraded an OpenStack cloud, whether you can staff the build and the migration without pulling people from daily operations, and whether you have a rollback plan for each wave. A partner can take on fixed-scope work such as design, deployment, hardening, backup configuration, documentation and migration support, while your team keeps ownership of operations. Ask for a split of responsibilities in the written scope so you know which tasks your staff must complete and when.
How does Ceph compare with vSAN for VM storage?
Ceph is open source, licensed under LGPL-2.1 or LGPL-3, and the project itself has no paid edition, while vSAN is sold only inside VMware Cloud Foundation or vSphere Foundation. Ceph can back Glance images, Cinder volumes, backups and Nova guest disks, so VMs can boot from Ceph without local hypervisor storage. Ceph needs more design attention. The hardware guidance recommends a dedicated drive per OSD, moving WAL and DB to shared SSDs for HDD-based OSDs, enterprise-class SSDs for metadata, and bonded network links across two switches. It also advises sizing memory for peak use and benchmarking before buying, because no two clusters are alike. Confirm with your Ceph support provider which distribution and support model you will use.
What happens to perpetual VMware hosts after Support and Subscription expires?
Perpetual ESXi hosts and vCenter keep running after Support and Subscription expires, according to Broadcom's knowledge base. What stops is access to new patches and major version upgrades, which require an active support contract. Broadcom announced on December 11, 2023 the end of availability of perpetual licensing, with customers moved to subscription offerings at renewal. For planning, this means a host can keep serving workloads while it falls behind on security fixes, which affects your risk register and any compliance evidence you must produce. Confirm current terms with Broadcom or your reseller, and set a dated plan for either renewing, migrating workloads in waves or keeping isolated hosts with compensating controls.
When is an implementation partner worth the cost for an OpenStack move?
A partner is worth considering when the work exceeds your team's current capacity or experience, such as a multi-tenant design, a Ceph build, compliance evidence or a tight cutover window. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own infrastructure, and most engagements are fixed-scope with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications.
How DeployOpen helps evaluate, implement or migrate
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a vSphere to OpenStack decision, we start with the workloads and the operations team you actually have, then build only what that evidence supports.
How we scope
- We inventory VMs, storage, network segments and tenant requirements before recommending OpenStack or a like-for-like cluster.
- The written scope names the services, Ceph design, identity federation and migration waves that the engagement covers.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the chosen OpenStack release with a documented deployment method in your cloud, data center or air-gapped network.
- We design Ceph-backed storage for Glance, Cinder and Nova, with sizing reviewed against your own benchmarks.
- We configure Keystone federation and mapping rules so identities from your existing provider map to projects and roles.
How we hand over
- We document the architecture, runbooks, upgrade path and release lifecycle so your team can operate the cloud.
- We test failover, backup restores and tenant isolation, and record the results as evidence for your own reviewers.
- We train your operators on day-to-day administration, and deliver prepared controls and evidence for compliance assessments.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retainers can cover planned moves between OpenStack releases, including the SLURP releases your upgrade policy targets.
- Independent auditors and certification bodies issue any audit reports or certifications; DeployOpen prepares the evidence for them.
