Modernize OpenStack without putting production at risk
We assess your release gap, storage and workloads, then choose the safest path: parallel platform, controlled export/import or sequential in-place upgrade. Every path includes testing, rollback criteria and production stabilization.
- 1Audit and inventoryReleases, storage, networks, workloads and their acceptable outage windows.
- 2Parallel target platformBuilt with Kolla-Ansible next to the legacy cloud, sharing the Ceph cluster when possible.
- 3Pilot groupValidates the procedure, acceptance criteria and rollback before critical workloads move.
- 4Controlled waves and cutoverVolumes adopted by the new Cinder without copying data; legacy cloud kept as rollback until acceptance.
Three migration paths for legacy OpenStack environments
Option A: Shared Ceph cluster
The Ceph pool is connected to both old and new OpenStack deployments. Volumes are unmanaged from legacy Cinder and reimported into the new Cinder service without network copy.
Option B: Snapshot, export and import
For isolated storage backends, we create snapshots, export images to Glance/S3, move them, and recreate the environment in the target OpenStack cluster.
Option C: In-place upgrade (kolla-ansible upgrade)
The existing cluster is upgraded in place through a path supported by Kolla-Ansible and every deployed service, without deploying a parallel environment. Faster and cheaper, but it carries real risk for the hosted workloads.
Options A and B are documented command by command in our technical guide: Migrate Cinder volumes between two OpenStack clouds →
In-place upgrade with kolla-ansible
kolla-ansible upgrade rolls newer container images out on the existing multi-AZ cluster without building a parallel target. Use adjacent releases, or a skip between two consecutive SLURP releases only when Kolla-Ansible and every deployed service support it. A legacy source can therefore require several qualified maintenance windows.
Technical guide: release-by-release upgrade procedure →We do not recommend this path by default
An in-place Kolla-Ansible upgrade changes the live control plane and compute services. A failed step can extend the maintenance window or disrupt APIs and workloads. We only retain this path after validating backups, rollback options, application resilience, compatibility between each release and explicit risk acceptance.
Audit and inventory
We map services, storage, network, and OpenStack versions before proposing the migration path.
Parallel deployment
We build the target platform alongside the legacy environment to minimize business disruption.
Cutover and control
We validate workloads, ensure HA, and stabilize production before final cutover.
What your team receives
A version and dependency inventory, tested migration runbooks, pilot report, per-wave cutover and rollback plans, acceptance evidence, updated architecture documentation and knowledge transfer.
Assess my OpenStack migration