OpenShift support dates through 2027: which clusters run out first and how to plan the upgrades

Term 2 of EUSdefinitionRed Hat's Extended Update Support for OpenShift 4.x. Odd versions don't get it, and 5.x has none. On an even 4.x version, buying all the terms keeps you supported for as long as 48 months. for OpenShift 4.14 ran out on October 31, 2026. Clusters with the Term 3 add-on are fine until October 31, 2027, and the rest are on their own. 4.19 goes next, on December 17. OpenShift 5.0 came out on November 3 without any EUS, so if you want to sit on one version for years, 4.22 is the longest option you can install today, to June 30, 2029 with Term 2. In 5.x, that role starts with 5.2 and its Extended Life Cycle add-on. If your company runs OpenShift, find out today which version each cluster is on and when its support ends. The rest of this guide gives you every date, the options for each version and the upgrade order that wastes the fewest weekends.

Your apps won't fall over the day support ends. What you lose is someone to call. Red Hat's policy says that after maintenance ends, the only help you get is help upgrading. Security fixes stop as well, and Red Hat warns that some of the hosted services a cluster leans on may not keep working for old versions.

For a regulated business that turns into an audit finding before it turns into an outage. Expect an auditor to ask whether your platforms still get vendor patches. For an unsupported cluster, that's an awkward answer. The bigger cost is time. OpenShift upgrades go one version at a time, so a cluster two or three versions behind needs several planned weekends, and no supported way back if one goes wrong.

Not every version is in the same spot. A cluster on 4.19 has the hardest wall, because odd versions can't buy extra time. A cluster on 4.14 is covered only if someone bought Term 3, and that runs out in October 2027. A cluster on 4.18 or 4.20 has time, as long as someone puts the next hop in next year's plan.

For engineers: the control plane still passes through the intermediate minor, so every check for that minor still applies. Red Hat's docs say the master pool can't be paused, only clusters with separate non-control-plane pools can use the paused-pool method, and Control Plane Only updates are only offered once updates between all the versions involved are available. Nodes that are both control plane and worker get none of the saving. On Server Fault, an operator whose three control-plane nodes also ran workloads asked how to canary-update those nodes. Red Hat doesn't support custom pools made from control-plane nodes, which is why it's awkward.

These come from Red Hat's own support dates for OpenShift, which we checked again on November 4. Standard support means Full plus Maintenance, which your normal subscription covers. EUS Term 1 comes with Premium subscriptions and is an add-on for Standard ones. Terms 2 and 3 are separate add-ons.

Two things in that table catch people out. Moving a 4.14 cluster up one EUS step to 4.16 buys less time than staying put: 4.16's last term ends June 2027, while 4.14 with Term 3 runs to October 2027. And the odd versions look current but run out fast. Teams that follow the stable channel one minor at a time often land on 4.19 or 4.21 and only notice when the end date shows up in a vendor email.

Where does 5.0 fit? It's an in-place update from 4.22, and on November 4 Red Hat's update graph offered it only from 4.22.17 or later, on the fast-5.0 and candidate-5.0 channels. Red Hat dropped EUS for 5.x. Each minor gets 12 months of Full Support and 12 of Maintenance, and only every third minor, starting with 5.2, can buy an Extended Life Cycle add-on. EUS terms you already hold on 4.x run to their published dates. Clusters that upgrade keep their RHCOS 9 nodes until you move every node to RHCOS 10.2. Mixed RHCOS 9 and 10.2 nodes aren't supported, and Red Hat plans to remove RHCOS 9 support in 5.3. Stopping on 4.22 or carrying on to 5.0 walks through both routes.

Right now 4.14 is where the pressure is, so we've laid that decision out below. You can use the same reasoning for 4.12, 4.16 and 4.19. Find the row that fits your budget and network plugin, and the number of weekends your team can actually spare.

If Term 3 is in budget, buying it and planning a careful climb next year is usually the calm choice. Term 2 and Term 3 do cover less than standard support, though. Red Hat's policy limits their fixes to platform-aligned operators and the select operators listed on its operator life cycle page, so check what you run before you rely on them. Without the extension money, start the network migration now, because nothing beyond 4.16 happens until it's done.

For 4.19, the only way out is forward: 4.20 is one minor away and has standard support to April 2027. For 4.12, Term 3 ends in January and the cluster is four EUS hops from 4.20. That many hops in three months is a lot to ask, so a fresh cluster on 4.20 or 4.22 with the workloads moved across is often less risky than climbing one hop after another. For 4.16 and 4.18, put the next hop into 2027's plan before anyone decides the extended terms are fine. Standard support for 4.20 ends April 21, 2027, so a climb that finishes later in the year should aim for 4.22.

Red Hat removes old pieces along the way, and some of them have to be dealt with before the cluster will let you continue. These are the ones we'd check first on any path from 4.14 or 4.16 to 4.20 or 4.22.

The network migration is the one that eats calendars. Red Hat calls limited live migration the preferred method, but it isn't supported for hosted control planes or for clusters running SDN in multitenant mode, and egress router pods have to go first. Red Hat's docs list more prerequisites, so read them against your cluster before you pick a method. Teams that rely on egress IPs, multicast or hand-written network policies should test those on a non-production cluster that has been migrated, because those are the things users notice on Monday morning.

# Version, channel and recommended updates
$ oc get clusterversion
$ oc adm upgrade
# Network plugin: OVNKubernetes or OpenShiftSDN
$ oc get network.config cluster -o jsonpath='{.status.networkType}'
# APIs your target release removes, and who still calls them
$ oc get apirequestcounts
# Worker pools you can pause during an EUS hop
$ oc get mcp
# Cluster operators that are degraded or blocking the next minor
$ oc get clusteroperators

Most teams end up in a squeeze like this one because upgrades were treated as projects instead of a schedule. A Red Hat minor arrives about every four months. If one hop a year is planned like a normal release, nobody has to rush three of them before an end date.

Operators deserve their own line in the plan. On Server Fault, one operator owner described a Data Grid operator update that stalled with a message that its CSV owned resources needing a certificate refresh, even though the install plan had been approved. That kind of stall sits outside the cluster update itself, so it's easy to miss until the maintenance window. On Hacker News, a practitioner described a vendor product that would only run on one specific OpenShift and RHEL version. If something you own is pinned like that, it decides your upgrade date more than Red Hat does.

We plan and run this work with platform teams: the cluster inventory, the SDN to OVN-KubernetesdefinitionThe network plugin that carries traffic between pods and out of the cluster. It replaced OpenShift SDN. From 4.17 on, OpenShift SDN is no longer an option. migration, the operator and API checks, rehearsals and the production hops. The OpenShift page covers what we do on the platform, you can hire OpenShift engineers for a fixed stretch of upgrades, and our cloud management team can keep running the clusters with yours afterwards. If you'd rather start with a list of what's at risk, ask for an assessment.