Red Hat OpenStack Platform end of life, and where the workload lands.

Red Hat OpenStack Platform is the Red Hat supported distribution of OpenStack, sold for years as the on premise infrastructure as a service stack for telecommunications carriers, public sector data centres, and enterprises operating large multi tenant private clouds. RHOSP 17.1 is the final long term release of the platform under the original product name. Red Hat moved 17.1 to extended life support on the published roadmap and named Red Hat OpenStack Services on OpenShift as the receiving product line on the new lifecycle1.

Red Hat OpenStack Services on OpenShift is the architectural rebuild that runs the OpenStack control plane as a set of containerised services on an OpenShift cluster rather than as a set of bare metal services on dedicated controller hosts. The compute nodes still run KVM and the OpenStack neutron and nova plane still expose the OpenStack APIs to OpenStack consumers, but the entire control plane is operator deployed on OpenShift, which collapses the operational model into the broader Red Hat container platform discipline2.

The roadmap inflection is therefore both an end of life event for the original RHOSP product and a green field deployment event for the receiving product. A buyer on RHOSP today is not migrating from one OpenStack to another OpenStack with the same operational model. The buyer is migrating from a bare metal RHOSP control plane to an OpenShift hosted control plane, which is a substantial reskilling exercise as well as a contract conversation.

The first destination is Red Hat OpenStack Services on OpenShift. This is the path the buyer takes when the workload needs OpenStack semantics: neutron based networking with a service provider topology, nova based compute that the operations team has tooled extensively, cinder block storage at the OpenStack abstraction, or a tenant model that the workload's consumers depend on. Telecommunications carriers running virtualized network functions and large multi tenant private clouds typically land here. The economics are a new OpenShift cluster footprint to host the control plane plus the existing compute footprint, with the OpenStack Services entitlement layered on top.

The second destination is OpenShift Virtualization. This is the path the buyer takes when the workload only needed virtual machines and never really used the OpenStack control plane semantics. A buyer that ran RHOSP as a generic VMware alternative for general purpose virtual machine workloads typically lands here. The economics are an OpenShift contract that absorbs the virtual machine count at consolidated core count, often substantially cheaper than the OpenStack Services destination because no OpenStack control plane is required3.

The third destination is exit: a hyperscaler, VMware, or another private cloud stack. This is the path the buyer takes when the workload no longer justifies the operational cost of a private cloud at all. The economics are the cost of replatforming the workload to the destination plus the cost of the destination subscription minus the residual RHOSP cost. Workloads that ran on RHOSP because the original procurement choice was made eight years ago often fit this destination better than the buyer initially expects.

The extended life support tail on RHOSP 17.1 is the calendar runway during which the buyer pays for security backports while the migration runs. The tail is finite and the Red Hat field organisation prices renewals into it knowing the buyer's exit window. The procurement function should treat the tail as a known limited contract and price the migration against the tail's exhaustion rather than against the tail's continuation. A buyer that signs a three year RHOSP extended life support tier in 2026 has paid for runway through 2029 but is also signalling that the migration is not actually planned, which weakens the procurement function's leverage at the next conversation4.

The leverage at the migration table is the buyer's willingness to land workloads at all three destinations rather than only at the Red Hat hosted destinations. A buyer that brings only RHOSO and OpenShift Virtualization quotes to the table is negotiating one Red Hat contract against another Red Hat contract; a buyer that also brings VMware and hyperscaler quotes is negotiating across vendor portfolios. The cross portfolio quote tends to produce a better concession band on the Red Hat lines than the single portfolio quote does. The procurement function should run all three destination quotes in parallel even if the engineering team's preferred destination is unambiguously Red Hat hosted.

The labour cost of the migration is the third line that the procurement narrative should name. RHOSP to RHOSO is operationally substantial because the control plane model changes. RHOSP to OpenShift Virtualization is closer to a virtual machine migration but still nontrivial because the OpenStack abstractions do not survive the move. RHOSP to a hyperscaler is the most operationally complex of the three but is also the only destination that retires the on premise infrastructure footprint. The labour budget should be modelled across the parallel run, not just at cutover.

The procurement narrative at RHOSP end of life names the workload inventory by destination, the OpenShift cluster footprint required to host RHOSO, the OpenShift Virtualization absorption for the generic virtual machine workloads, the hyperscaler or VMware exit for the cold workloads, the extended life support tier on RHOSP through the parallel run, and the labour budget across the parallel run period. The narrative is the document that the procurement function defends at the renewal conversation; the engineering team's preferred destination is one input rather than the conclusion.

For the broader cross product reading, see the OpenShift practice hub, the OpenShift Virtualization versus RHV migration economics read for the parallel virtualization sunset story, the Red Hat Virtualization end of life planning read for the related lifecycle timing, the OpenShift Virtualization as VMware exit path read for the broader replatform narrative, and the KVM and Proxmox audit evidence read for the parallel run evidence patterns that often surface during the migration. For the engagement protocol, see renewal negotiation and contact.

Red Hat OpenStack Platform end of life is a procurement event with a firm calendar. The buyer who prices three destinations in parallel and runs the cross portfolio quote at the negotiation table walks out with a better concession band than the buyer who treats Red Hat hosted destinations as the only options. The calendar is not negotiable; the destination mix is.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.