OpenStack is not a failed platform. It is a platform whose operating cost is paid in scarce people. This page covers when that trade stops working, what the move to a Kubernetes-native control plane actually involves service by service, and which parts are genuinely hard.
Pairs with: Ænix Public Cloud Platform if the OpenStack cloud is sold to external customers (hosters, MSPs, telcos, national operators); Ænix Private Cloud Platform if it serves internal consumers under DORA / NIS2 / sectoral rules.
When you should not migrate
Say this plainly first, because most OpenStack content skips it.
Stay on OpenStack if you have a functioning operations team that knows the release cadence, you are current on a maintained release, your upgrade path is exercised rather than theoretical, and you use enough of the service surface — Ironic for bare metal, Octavia, Manila, Designate, Barbican — that a replacement would mean rebuilding several of them. OpenStack does things Kubernetes-native platforms do not: multi-hypervisor compute, mature bare-metal provisioning, an API surface that a decade of tooling already speaks.
The migration case is an operational one, not a technical-superiority one. It gets strong when:
- Upgrades have stalled. The estate is two or more releases behind, the upgrade is a project rather than a maintenance window, and each deferral makes the next one worse.
- The team is a bus-factor problem. One or two engineers hold the whole control plane. OpenStack skills are not being replenished from the market at the rate they are leaving it.
- The service surface used is narrow. In practice many clouds run Keystone, Nova, Glance, Cinder, Neutron and Horizon, and nothing else. That is a footprint a Kubernetes control plane replaces without loss.
- Containers are already the majority workload. You are running Kubernetes on top of OpenStack VMs, paying for two control planes and debugging across both.
- Distribution economics changed. Vendor-supported OpenStack subscriptions renewed at a number that no longer matches the value of the support.
If none of these apply, the honest recommendation is to stay and invest in your upgrade pipeline instead.
Service-by-service mapping
This is the part that decides scope. Each OpenStack project has a destination, a no-destination, or a redesign.
| OpenStack | Cozystack destination | Migration character |
|---|---|---|
| Keystone (identity, domains, projects) | Tenant CRD plus Kubernetes RBAC, OIDC to your existing IdP | Redesign. Project trees do not map one-to-one; tenant hierarchy is modelled during the assessment. |
| Nova (compute) | KubeVirt VMs on the same cluster as containers | Mechanical. Both sides are libvirt/KVM underneath. |
| Glance (images) | Container Data Importer (CDI) DataVolumes, backed by object storage | Mechanical. QCOW2 and raw carry over. |
| Cinder (block) | LINSTOR/DRBD, or keep your existing Ceph cluster via Ceph CSI | Mechanical if Ceph stays; a data move if you consolidate onto LINSTOR. |
| Neutron (networking) | Cilium (eBPF) with L2 announcements or BGP; MetalLB where already standardised | Redesign. This is the hard part — see below. |
| Swift / Ceph RGW (object) | S3-compatible object storage on the platform, or keep RGW | Usually keep. Object endpoints are long-lived and customer-facing. |
| Octavia (load balancing) | Kubernetes Service type LoadBalancer plus an ingress layer | Redesign. Per-tenant LB semantics differ. |
| Ironic (bare metal) | No direct equivalent | Gap. If Ironic is load-bearing, keep it or keep OpenStack for that slice. |
| Magnum (Kubernetes as a service) | Tenant Kubernetes clusters with hosted control planes | Simplification. This is what the platform is built around. |
| Trove (DBaaS) | Managed database applications in the tenant catalogue | Replacement, not migration. Data moves by logical dump/replica. |
| Heat (orchestration) | Helm plus GitOps reconciliation | Rewrite. Heat templates do not convert. |
| Horizon (dashboard) | Cozystack tenant dashboard | Replacement. Retrain, do not port. |
| Ceilometer / Gnocchi | Prometheus-compatible metrics stack with long-term storage | Replacement. Billing integrations must be re-pointed. |
Two entries deserve emphasis because they are where migrations overrun.
Neutron is the redesign. Tenant networks, routers, floating IPs, security groups and provider VLANs are an addressing and policy model, not just plumbing. Cilium expresses the same outcomes with different primitives: network policy instead of security groups, LB IPAM and BGP or L2 announcements instead of floating IPs and the L3 agent. Customer-visible IPs have to survive the move or be renumbered on a schedule your customers agree to. Budget real design time here; skipping it is the most common cause of a stalled OpenStack migration.
Heat and Horizon do not port. Anything a tenant automated against the OpenStack API — Terraform providers, Heat stacks, internal scripts — is rewritten against the Kubernetes API. For an internal cloud that is a training cost. For a public cloud with API-consuming customers, it is a product decision with a deprecation timeline attached, and it belongs in the plan on day one rather than month nine.
How the migration runs
- Architecture review (2-4 weeks). Full service inventory — which OpenStack projects are actually in use, which have tenant-visible APIs, which have integrations behind them. Tenant model design. Address plan. The output is a written target architecture and a cohort sequence, and it is where a no-go decision is still cheap.
- Parallel deployment. Cozystack is built alongside the running OpenStack cloud, not on top of it. Both control planes coexist for the duration; there is no point at which the estate depends on a single cutover.
- Cohort migration. The disk transfer itself is done by Konveyor Forklift, which ships in the Ænix platform and supports OpenStack as a source provider. Datastore-to-StorageClass and network-to-network mappings are declared as Kubernetes objects, and
virt-v2vhandles guest-side conversion. Note the constraint: from OpenStack, Forklift does cold migration only — warm, incremental transfer is available from vSphere and RHV, not from OpenStack — so every OpenStack instance has a real power-off window, and cohort sizing is driven by how many of those windows you can schedule at once. Workloads move in defined groups — typically by tenant, or by application tier for an internal cloud. Each cohort is validated in parallel run before its OpenStack side is released. Compute moves first, storage follows the compute, networking is cut over per cohort against the agreed address plan. - Decommission. OpenStack nodes are drained and rebuilt into the new cluster as cohorts complete, so the estate does not need double the hardware for the full duration — only enough headroom for the largest in-flight cohort.
Typical duration: 4-12 months for a mid-size deployment; 12-18 months where Neutron carries a complex provider-network topology or tenants consume the OpenStack API directly.
What moves cleanly, and what does not
Moves cleanly. VM disks — both sides are KVM, so a QCOW2 or raw image imports into a KubeVirt DataVolume without guest changes, driven by Forklift. Linux guests generally boot on first attempt. Ceph, if you keep it. Object storage endpoints. Anything already containerised.
Needs design work. Tenant hierarchy, if you used Keystone domains and nested projects. Load balancer semantics. Quota and rate-limit models. Anything that assumed a floating-IP pool.
Has to be rebuilt. Heat stacks. Horizon customisations. Billing and metering integrations, which read Ceilometer and must be re-pointed at the new metrics source — for a service provider this is usually the longest single work item after networking, and it gates revenue, so it is scheduled early rather than late.
May not move at all. Ironic-managed bare metal. Windows guests need the same VirtIO driver handling as any other virtualisation migration. Appliances shipped as vendor VMs need their vendor’s blessing on the new hypervisor before you plan around them.
For the platform comparison behind these choices, see OpenStack vs Cozystack modernization and the OpenStack alternative page. To model the cost side, use the TCO calculator.
How Ænix engages
- Platform Readiness Assessment (fixed price, agreed up front) — service inventory, target architecture, tenant and address design, cohort plan, risk register. See Platform Readiness Assessment.
- Pilot cohort — the first tenant group migrated with Ænix engineers working inside your team, producing the runbooks the rest of the estate uses.
- Rolling migration — cohort by cohort, parallel-run validated, with OpenStack hardware recycled into the target cluster as it frees up.
- Operations — either your team runs it with Cozystack enterprise support behind them, or Ænix operates it.
Ænix is the team behind Cozystack (CNCF project, Apache 2.0).