The part that catches teams out is not the deadline. It is that adopting Red Hat's next OpenStack means running OpenShift underneath it.
Red Hat OpenStack Platform 17.1 is the last release with the classic director-deployed control plane. Its successor, Red Hat OpenStack Services on OpenShift, hosts the control plane natively on OpenShift Container Platform and manages the RHEL data plane nodes with Ansible. That is not an upgrade in the ordinary sense. It is a different operating model, and whoever signs off on it is signing up to run a Kubernetes distribution as a dependency of their cloud. We run OpenStack private clouds for operators and institutions across Kenya and East Africa, and this is the migration we are asked about most often right now.
What Red Hat has published
Red Hat has published that the Red Hat OpenStack Platform director Operator is scheduled for deprecation on 22 September 2027, after which no support is granted beyond assistance moving to a supported version. RHOSO 18.0 runs on OpenShift 4.16 and above with RHEL 9.4, and later feature releases extend that to OpenShift 4.20 and RHEL 9.6. Greenfield deployments are supported only on the latest OpenShift in Red Hat's matrix.
Confirm your own dates against the Red Hat OpenStack Platform life cycle page rather than against any vendor's slide, including ours. Support windows differ by subscription and by whether extended lifecycle applies to you, and this is the one fact in the whole decision that is worth ten minutes of your own reading.
Route one: adopt Red Hat OpenStack Services on OpenShift
Red Hat has done the engineering here properly. There is a documented adoption procedure from a 17.1 deployment that moves the existing overcloud to an 18.0 data plane, covering Instance HA environments and the common storage backends. Your workloads stay where they are. It is an adoption, not a rebuild, and that is a real advantage over anything we could offer you.
The cost is the platform underneath. You now operate OpenShift: its upgrade cadence, its certificates, its etcd, its operators, and the cluster capacity to host a control plane. For a telco or a bank that already runs OpenShift with a platform team behind it, that cost is close to zero and the answer is obvious. Take route one.
For an institution whose only Kubernetes is a small cluster somebody set up for a project, this is where it goes wrong. You are adding a second platform to keep current so that the first one keeps working, and the DevOps and platform capability to do that is a hiring decision, not a project line. Two subscriptions, two upgrade calendars, two on-call skill sets.
Route two: exit to upstream OpenStack
The other honest option is to leave the Red Hat distribution and run upstream OpenStack, deployed with Kolla-Ansible or OpenStack-Ansible, with the inventory and configuration in your own git repository. Same projects, same APIs, same Keystone, Nova, Neutron and Cinder your team already knows. No OpenShift dependency, no per-node subscription unless you want one. The cost model shifts rather than disappearing, into hardware, network and the engineering to run it.
What you give up is real and we will not pretend otherwise. There is no vendor to escalate to at three in the morning unless you contract someone, no certified reference architecture to point an auditor at, and no Red Hat name on the support line when a regulator asks who backs the platform. For some institutions that last one alone decides it, and it should.
What you gain is that the upgrade path stops being somebody else's product roadmap. Upstream releases run on a published cadence with skip-level upgrades between SLURP releases, so you move on your own schedule, and the thing you upgrade is the thing you already operate.
Inventory this before you choose
The decision is usually made on four facts, and most teams have only two of them written down:
- Does an OpenShift platform team already exist, with a budget line and an on-call rota, or would this create one
- Which storage backend you are on, because Ceph integration adopts cleanly and appliance-backed Cinder drivers need checking against the 18.0 support matrix one by one
- Whether anything outside OpenStack calls your APIs, since billing systems, Terraform pipelines and tenant portals written against the 17.1 endpoints need testing, not assuming
- Your compliance position, specifically whether an auditor or regulator has ever been shown "Red Hat supported" as part of the control narrative
That fourth one is the one clients discover late. If your risk register names the vendor, changing the vendor is a governance exercise with a longer lead time than the technical migration.
How we would run the migration
Rehearse on a clone before anything touches production. We restore the 17.1 database and a representative slice of the estate onto scratch hardware and run the adoption there first, because the failures worth finding are in your specific Cinder backends and your specific Neutron layout, not in Red Hat's documentation. That rehearsal is also what turns a change advisory board conversation from a debate into a review of evidence.
Then move in waves, smallest tenant first, with a tested rollback for each wave rather than one for the whole programme. Keep the old control plane recoverable until the last wave is signed off. And do the API consumer testing before the first wave rather than after the second, because a billing integration that quietly stops reconciling is the failure that gets noticed a month late.
If you are weighing the two routes, the honest starting point is whether you already run OpenShift. If you do, adopt. If you do not, get someone to price both properly before the 2027 date makes it urgent, and be open to the answer that neither is right and a simpler virtualisation platform covers what you actually use. Send us your 17.1 topology and your subscription position and we will scope both routes side by side: start here or on WhatsApp at +254 713 403 044.