Start a project
Menu
ServicesAll servicesCybersecurityCloud EngineeringApplication ServicesEnterprise PlatformsData & AnalyticsAI & Machine LearningInternet of ThingsMobilize Talent
PlatformsAll platformsIdentity and accessPrivileged access and secretsERP, HCM and financeCRM, ITSM and automationHealthcareInsurance and bankingData and integrationCloud and AIIndustrial, utilities and mainframeSkills matrix
Case studiesAll case studiesIdentity and accessPrivileged accessSecurity operationsCloud and infrastructureApplicationsERP and HCMCRM, ITSM and automationIndustry platformsData and analyticsAI and agents
IndustriesAll industriesEnergy, oil & gasHealthcare payersBanking & financial servicesInsurancePublic sectorManufacturingLocations
InsightsField notesLearning tracks
CompanyAbout CohashPortfolioSkills matrixCareersTrust and securityContact
Start a project
container platform

OpenShift upgrades planned before the support date, so no cluster gets stuck on an old minor.

OpenShift 4.14 loses EUS Term 2 on 31 October 2026, and 4.19 drops out of maintenance in December with no EUS to fall back on. We plan the EUS-to-EUS hops, move clusters off OpenShift SDN first, and can run the platform alongside your team afterwards.

Talk to a Red Hat OpenShift engineerWhat changed recently
platform dossierRed Hat OpenShiftContainer platform
Vendor
Red Hat
Newest minor
OpenShift 4.22, GA 9 Jun 2026, Kubernetes 1.35
Support model
Full, then Maintenance to 18 months, plus EUS terms
Next deadline
4.14 EUS Term 2 ends 31 Oct 2026
release watch
  • OpenShift 4.22 is the newest minor09 Jun 2026
  • When does OpenShift 4.14 EUS Term 2 end?31 Oct 2026
connects with
z/OS
in short·15-second read

OpenShift 4.14 EUS Term 2 ends on 31 October 2026.

After that, only the paid Term 3 keeps it supported, to 31 October 2027. Cohash plans EUS-to-EUS upgrades, moves clusters from OpenShift SDN to OVN-Kubernetes before 4.17, and rehearses on non-production first. The newest minor is 4.22, out since 9 June 2026.

you probably need this if
  • Clusters still run 4.14, EUS Term 2 ends on 31 October 2026, and nobody has priced Term 3.
  • The network plugin is still OpenShift SDN and nobody has scheduled the migration.
  • Every upgrade is followed by a week of broken operators and failed deployments.
terms on this page EUSdefinitionExtended Update Support, the paid add-on that kept even-numbered 4.x versions supported longer. Odd versions like 4.19 never got it, and 5.x replaces it with ELC.explained in a field note →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.explained in a field note →OpenShift VirtualizationdefinitionPart of OpenShift, Red Hat's Kubernetes platform, that runs virtual machines next to containers on the same cluster. Under the hood it's the KubeVirt project.explained in a field note →
Ask an engineer facts checked 2026-10-25
how it runs
  1. 01Cluster health and inventory
  2. 02Upgrade path
  3. 03Rehearsal
  4. 04Production and handover
you keep
  • A list of every cluster with its version, update channel, network plugin and support end date, so you can see which one runs out first
  • An operator compatibility matrix for the target release, so you know which operators need updating before the upgrade starts
  • Deprecated API report by namespace and owner
+ 3 more documents
who does it
OpenShift platform engineer (cluster upgrades, EUS)OpenShift networking engineer (OVN-Kubernetes)OpenShift Virtualization engineer Red Hat Certified System Administrator in OpenShift Red Hat Certified Specialist in OpenShift Virtualization
platforms
z/OS
proof
4 case studies on this
background
HOLD ON 4.22 EUS to June 2029 Kubernetes 1.35 RHCOS 9, HAProxy 2.8 MOVE TO 5.0 Support to Nov 2028 Kubernetes 1.36 RHCOS 10.2, HAProxy3.2
field note · 16 minOpenShift 4.19 is running out of support. Do you park on 4.22 or keep going to 5.0?
openshift · release timeline
  1. 09 Jun 2026 OpenShift 4.22 is the newest minor It runs Kubernetes 1.35 with CRI-O, and RHCOS now uses RHEL 9.8 packages. RHCOS 10.2 is there as a Technology Preview, and runC is deprecated, so check anything that still sets it. It's an EUS release, with Term 1 running to June 2028.
  2. 31 Oct 2026 When does OpenShift 4.14 EUS Term 2 end? On 31 October 2026. Clusters still on 4.14 after that need the paid Term 3, which runs to 31 October 2027 and is the last date Red Hat lists for 4.14. Plan the move now, because from 4.14 it's several hops to anything current.
  3. today · Nov 09, 2026
  4. 17 Dec 2026ahead 4.19 maintenance support ends 4.19 is an odd minor, so there's no EUS term to buy. Maintenance ends on 17 December 2026, and a 4.19 cluster has to be on 4.20 or later by then to keep getting fixes.
  5. 31 Dec 2026ahead 4.22 leaves Full Support Red Hat's life cycle data puts the end of 4.22 Full Support at 31 December 2026. Treat that as planned, because it can move when the next minor comes out. After it, 4.22 still gets qualifying security fixes until 31 December 2027, and EUS Term 2 carries it to 30 June 2029.
  6. 25 Feb 2027ahead 4.18 EUS Term 1 ends If you're on 4.18 with Premium or the EUS add-on, you've been on EUS Term 1 since maintenance ended on 25 August 2026. Term 1 runs out on 25 February 2027. Renew for Term 2 and you get to 25 February 2028; skip it and the hop to 4.20 has to happen this winter.
  7. 21 Apr 2027ahead 4.20 maintenance support ends If you're climbing to 4.20, its maintenance support ends on 21 April 2027. EUS terms carry it to 21 October 2027 and then 21 October 2028. Anyone who won't finish until late 2027 should probably aim for 4.22 instead.
  8. 27 Jun 2027ahead When does OpenShift 4.16 support end? 4.16 clusters have been on EUS Term 2 since Term 1 ended on 27 June 2026. Term 2 is the last one Red Hat lists for 4.16, and it ends on 27 June 2027. Put the hop to 4.18 or 4.20 in the first half of next year.
  9. 03 Aug 2027ahead 4.21 maintenance support ends 4.21 dropped from Full Support to Maintenance on 9 September 2026. It's an odd minor, so nothing extends it past 3 August 2027. Clusters on it should move to 4.22 before then.
  10. no date yetOpenShift SDN removed in 4.17SDN support stops at 4.17. If a cluster isn't on OVN-Kubernetes yet, it stays on 4.16 until it is.
the story · red hat openshift estate

From the first call to a setup your own team can run.

Here's what usually prompts a call about your Red Hat OpenShift estate, what we do about it and in which order, and where you end up.

  1. chapter 01 · where it hurts

    Why teams reach out

    • Clusters still run 4.14, EUS Term 2 ends on 31 October 2026, and nobody has priced Term 3.
    • The network plugin is still OpenShift SDN and nobody has scheduled the migration.
    • Every upgrade is followed by a week of broken operators and failed deployments.
  2. chapter 02 · what we change

    How we solve it

    • EUS-to-EUS upgrade planning
    • OpenShift SDN to OVN-Kubernetes migration
    • Cluster builds and platform engineering
    • OpenShift Virtualization
    • Operator and API readiness
    • Run support
  3. chapter 03 · how it runs

    Our approach

    • Cluster health and inventory
    • Upgrade path
    • Rehearsal
    • Production and handover
  4. chapter 04 · where you end up

    What changes

    • Every cluster ends up on OVN-Kubernetes and a supported EUS release.
    • How many VMs move is decided from the pilot results instead of a guess.
    • A list of every cluster with its version, update channel, network plugin and support end date, so you can see which one runs out first
    • An operator compatibility matrix for the target release, so you know which operators need updating before the upgrade starts
what we do

Our Red Hat OpenShift work

6 kinds of Red Hat OpenShift work, each run by engineers who have done it on live tenants.

  1. Paths between even-numbered EUS releases, with control plane-only updates, paused worker pools and operator compatibility checked for every hop.

  2. Network plugin migration on 4.16 or earlier, with egress IPs, network policies and multicast rules mapped and tested before the cluster can move past 4.16.

  3. New clusters on bare metal, VMware or public cloud, with GitOps for cluster configuration, identity provider integration and quota models per team.

  4. VM workloads planned and moved onto OpenShift Virtualization, with storage, networking and backup designed for VMs as well as containers.

  5. Installed operators checked against the target release, deprecated Kubernetes APIs found in manifests and Helm charts, and owners told before the upgrade.

  6. Upgrade cadence, certificate rotation, etcd health, alert tuning and capacity reviews, with runbooks your platform team keeps.

capability 01 / 06in production

EUS-to-EUS upgrade planning

Paths between even-numbered EUS releases, with control plane-only updates, paused worker pools and operator compatibility checked for every hop.

talk to an engineer about this →
capability 02 / 06in production

OpenShift SDN to OVN-Kubernetes migration

Network plugin migration on 4.16 or earlier, with egress IPs, network policies and multicast rules mapped and tested before the cluster can move past 4.16.

talk to an engineer about this →
capability 03 / 06in production

Cluster builds and platform engineering

New clusters on bare metal, VMware or public cloud, with GitOps for cluster configuration, identity provider integration and quota models per team.

talk to an engineer about this →
capability 04 / 06in production

OpenShift Virtualization

VM workloads planned and moved onto OpenShift Virtualization, with storage, networking and backup designed for VMs as well as containers.

talk to an engineer about this →
capability 05 / 06in production

Operator and API readiness

Installed operators checked against the target release, deprecated Kubernetes APIs found in manifests and Helm charts, and owners told before the upgrade.

talk to an engineer about this →
capability 06 / 06in production

Run support

Upgrade cadence, certificate rotation, etcd health, alert tuning and capacity reviews, with runbooks your platform team keeps.

talk to an engineer about this →
typical situations

Red Hat OpenShift situations we walk into

We pieced these together from Red Hat OpenShift situations that come up a lot. They're patterns. You won't find a specific client in them.

case file 01

Six clusters on 4.14 with OpenShift SDN and EUS Term 2 ending

composite · not a client story
  1. Beforethe situation

    Six production clusters are on 4.14 with OpenShift SDN, and EUS Term 2 ends on 31 October 2026. Several teams depend on egress IPs and custom network policies.

  2. What we dothe work

    We map egress IPs and network policies, migrate one non-production cluster to OVN-Kubernetes on 4.14 and test, then run an EUS-to-EUS update to 4.16 and on to 4.18. Production follows cluster by cluster.

  3. Afterwhere you end up

    Every cluster ends up on OVN-Kubernetes and a supported EUS release. The team also has a tested path for the next hop, to 4.20.

case file 02

About two hundred VMware VMs headed for OpenShift Virtualization

composite · not a client story
  1. Beforethe situation

    The VMware renewal is coming up, and the platform team wants to move about two hundred VMs onto the existing OpenShift clusters. Storage and backup there were designed with only containers in mind.

  2. What we dothe work

    We pick a representative set of VMs, size storage classes and networking for them, test backup and restore, and run a pilot on a dedicated worker pool before planning migration waves.

  3. Afterwhere you end up

    How many VMs move is decided from the pilot results instead of a guess. The clusters also have storage and backup built with VMs in mind.

case studies

Red Hat OpenShift case studies

All case studies
migration Cloud and infrastructure

VMware exit after the Broadcom licensing changes

Planning a VMware exit after Broadcom's move to subscriptions built around VCF, to OpenShift Virtualization, Azure VMware Solution or native cloud.

read the case study
upgrade Data and analytics

Apache Airflow 2 to Airflow 3

Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.

read the case study
upgrade Cloud and infrastructure

Kubernetes, EKS and OpenShift version upgrades

Keeping EKS, AKS and OpenShift clusters on supported Kubernetes minors, and dealing with deprecated APIs, add-ons and node pools before each upgrade.

read the case study
approach

How a Red Hat OpenShift engagement runs

We don't start a step until the last one has produced something you can check.

  1. step 01

    Cluster health and inventory

    For every cluster we write down the version, update channel, network plugin, installed operators, deprecated API usage and etcd health. Then we find out who owns the workloads running on it.

  2. step 02

    Upgrade path

    Each cluster gets its own path, EUS-to-EUS or one minor at a time. SDN migration, operator updates and API fixes are slotted into that path in the order they have to happen.

  3. step 03

    Rehearsal

    We run the whole path first on a non-production cluster built like production. Application smoke tests run along the way, and we write down how long every step took.

  4. step 04

    Production and handover

    Production clusters go in the agreed order. We unpause worker pools a batch at a time, then hand your team the runbooks and the GitOps repo that holds the configuration.

ai on red hat openshift

Where AI fits on Red Hat OpenShift, and where it needs guardrails.

Red Hat made OpenShift Lightspeed generally available in May 2025. It's a generative AI assistant inside OpenShift, and it runs against an LLM provider you configure. Red Hat has published guides for connecting it to MCP servers such as Advanced Cluster Management and Satellite. Platform teams get faster troubleshooting, but cluster RBAC still decides what anyone can change.

AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
Red Hat OpenShiftdoes the work

Red Hat doesn't ship a supported MCP server for OpenShift itself. Agents should use the Kubernetes API through a service account bound to narrow RBAC roles. Make it read-only by default and deny Secrets. Rely on the API audit logs, and send changes through GitOps pull requests that a person approves.

OpenShift Lightspeed

OpenShift has Lightspeed built in. It answers questions and helps troubleshoot, and it runs on whichever supported LLM provider you connect (Azure OpenAI, for example). We pick the provider with your security team, and we agree with them what cluster data it may send.

Lightspeed with MCP servers

Red Hat has published guides connecting Lightspeed to MCP servers for Advanced Cluster Management fleet health, Satellite and GitHub. Its own note says the IDE connection is a proof of concept and not yet supported. We'd try them on non-production clusters first.

Kubernetes MCP server

There's also an open-source Kubernetes MCP server in the containers GitHub organization. It understands OpenShift projects and routes, has a read_only setting and can deny resources such as Secrets. We run it read-only, under its own service account.

AI help with upgrades

Clusters have to be on OVN-Kubernetes before they cross 4.16. An AI assistant can work through must-gather output and deprecated API reports and draft the list of fixes. Then an engineer checks it on a staging cluster.

architecture

Where OpenShift fits, with code arriving from Git and alerts ending up in ServiceNow

Developers push code through CI into OpenShift, which runs containers and VMs on bare metal, VMware or cloud. Logins come from Entra ID or Okta and secrets from Vault. When something breaks, the alert lands in ServiceNow as an incident.

Where OpenShift fits, with code arriving from Git and alerts ending up in ServiceNow Developers push code through CI into OpenShift, which runs containers and VMs on bare metal, VMware or cloud. Logins come from Entra ID or Okta and secrets from Vault. When something breaks, the alert lands in ServiceNow as an incident. 01 · DELIVERY 02 · OPENSHIFT 03 · PLATFORM SERVICES 04 · OPERATIONS deploy OIDC login provision infra secrets run VMs metrics alerts Git and CI pipelines · GitOps repos Ex Entra ID OIDC for clusterlogin OP OpenShift 4.22 OVN-Kubernetes ·operators OpenShiftVirtualization VM workloads HashiCorp Vault secrets injection Terraform infrastructureprovisioning Monitoring Prometheus · Alertmanager SE ServiceNow incidents · CMDB © Cohash · cohash.com
01 · DELIVERY02 · OPENSHIFT03 · PLATFORM SERVICES04 · OPERATIONS Git and CI: pipelines · GitOps repos Git and CI pipelines · GitOpsrepos Entra ID: OIDC for cluster login Entra ID OIDC for clusterlogin OpenShift 4.22: OVN-Kubernetes · operators OpenShift 4.22 OVN-Kubernetes ·operators OpenShift Virtualization: VM workloads OpenShiftVirtualization VM workloads HashiCorp Vault: secrets injection HashiCorp Vault secrets injection Terraform: infrastructure provisioning Terraform infrastructureprovisioning Monitoring: Prometheus · Alertmanager Monitoring Prometheus ·Alertmanager ServiceNow: incidents · CMDB ServiceNow incidents · CMDB deploy OIDC login provision infra secrets metrics © Cohash · cohash.com
use cases

Typical Red Hat OpenShift projects

The work teams usually bring us, and the platforms Red Hat OpenShift has to talk to while we do it.

  1. OPE-01 Clusters sit on 4.14 or 4.16 and support terms run out within months common request
  2. OPE-02 Clusters run 4.19, an odd minor with no EUS. Once maintenance ends in December 2026, they stop getting fixes. common request
  3. OPE-03 Clusters still use OpenShift SDN and cannot upgrade past 4.16 common request
  4. OPE-04 Each upgrade breaks a third-party operator or an old Helm chart common request
  5. OPE-05 You're weighing a move of VMware VMs onto OpenShift Virtualization before the next renewal common request
  6. OPE-06 Only one person really knows the platform. Upgrades wait until they're free. common request
Red Hat OpenShift · connected platforms
TerraformHashiCorp VaultMicrosoft Entra IDOktaServiceNowIBM Z Mainframe
you keep

What a Red Hat OpenShift engagement leaves behind

These are working documents, written against your configuration, so your team can run them without us.

  • inventory01

    A list of every cluster with its version, update channel, network plugin and support end date, so you can see which one runs out first

    yours to keep
  • document02

    An operator compatibility matrix for the target release, so you know which operators need updating before the upgrade starts

    yours to keep
  • code03

    Deprecated API report by namespace and owner

    yours to keep
  • runbook04

    EUS-to-EUS upgrade runbook with timed rehearsal results

    yours to keep
  • tests05

    The plan for moving off OpenShift SDN to OVN-Kubernetes, with the test results from the non-production run

    yours to keep
  • document06

    GitOps repository for cluster configuration

    yours to keep
talent and delivery · red hat openshift

Certified engineers, wherever you need them.

Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.

Onsite

Engineers at your sites in the US

Nearshore

Overlapping hours with US teams

Offshore

Overnight progress on your backlog

All time zones

Coverage handed over across time zones

24-hour coverage · US Central time
OnsiteUS business hours
Nearshoreoverlapping US hours
Offshoreovernight progress
Combinedhandover, not hand-off
certifications our engineers hold
  • Red Hat Certified System Administrator in OpenShiftRed Hat
  • Red Hat Certified Specialist in OpenShift VirtualizationRed Hat
  • Red Hat Certified Advanced Developer in Cloud-native ApplicationsRed Hat
  • Red Hat Certified Architect in OpenShiftRed Hat
roles we staff
  • OpenShift platform engineer (cluster upgrades, EUS)
  • OpenShift networking engineer (OVN-Kubernetes)
  • OpenShift Virtualization engineer
  • Site reliability engineer for OpenShift
  • Kubernetes developer for operators and GitOps
due diligence · red hat openshift

Questions to ask any partner, including us.

Put these to anyone bidding on your Red Hat OpenShift work. The ones who've done it answer differently from the ones who've read about it.

  1. Q1

    What's the support end date for each of our clusters, including EUS terms?

    Full, Maintenance and EUS terms don't end together. Ask for a plan that names the date for every cluster and every subscription.

  2. Q2

    Which clusters still run OpenShift SDN, and when will you migrate them?

    SDN was removed in 4.17. Until someone finishes the network plugin migration, a cluster on SDN isn't going anywhere past 4.16.

  3. Q3

    Which of our operators and Helm charts will break on the target release?

    Most incidents after an upgrade trace back to a third-party operator or a deprecated API. Find and fix those before the maintenance window, while there's still time to test the change.

  4. Q4

    How will you keep cluster configuration off individual laptops?

    A cluster you can rebuild from Git comes back faster than one somebody configured by hand, and its upgrades hold fewer surprises.

  5. Q5

    Which of the engineers you'd put on our clusters have passed Red Hat's OpenShift exams, and which exams were they?

    Red Hat renamed its certifications in May 2026, so an older CV can list a title that's gone. Ask for the current name and the exam code, say EX280 or EX316. The codes didn't change.

01When does OpenShift 4.14 EUS support end?

EUS Term 2 for 4.14 ends on 31 October 2026. If you bought Term 3, you're covered to 31 October 2027, and that's the end of the line for 4.14. Without it, start the climb to 4.16 and 4.18 now, or build a new cluster on 4.20 or 4.22 and move the workloads across.

02Which OpenShift versions run out of support next?

4.19 is next after 4.14. It has no EUS to buy, so those clusters need to reach 4.20 before 17 December 2026. Then 4.18 EUS Term 1 ends on 25 February 2027, 4.20 standard support on 21 April 2027 and 4.16 EUS Term 2 on 27 June 2027. Check which add-ons each cluster really has, because EUS terms are separate add-on subscriptions.

03How long is each OpenShift minor supported?

Full Support lasts six months from GA or until 90 days after the next minor ships, whichever is later. Maintenance then runs to 18 months after GA. Even-numbered minors are EUS releases. Term 1 comes with Premium subscriptions; Terms 2 and 3 are paid add-ons that stretch support to 36 or 48 months in total, so put them in the budget before you need them.

04Can we go straight from 4.16 to 4.18?

Yes. Do it as an EUS-to-EUS update, where the control plane goes through 4.17 and the worker pools stay paused. If you're still on OpenShift SDN, the OVN-Kubernetes migration comes first, since 4.17 removed SDN.

05How long does an OpenShift upgrade take?

The cluster update itself is usually hours. The time goes into operator compatibility, deprecated API clean-up, network plugin migration and application testing. We size it from an operator and workload inventory.

06Is OpenShift Virtualization a real option for getting off VMware?

It depends on your VM count, storage, backup tooling and how much your teams already know Kubernetes. We run a pilot with representative VMs before anyone commits to a migration schedule.

07Do you staff OpenShift engineers?

Yes. We place OpenShift administrators, platform engineers and SREs on contract, contract-to-hire or permanent terms. They can sit onsite in the US or work nearshore or offshore, so someone's covering whatever time zone you're in.

services

Related services

Projects on Red Hat OpenShift usually end up touching one of these, so they're worth a look.

you are hereRed Hat OpenShift
fact-checked Checked against vendor and official documentation last checked 2026-10-25 content fingerprint 00a120a0
  1. 01Book a 30-minute working sessionsenior engineer
  2. 02Talk to an engineer about your setupreply within 24 hours
  3. 03See how similar projects wentcase studies
Reviewed by the Cohash team Red Hat OpenShift is a trademark of its owner, used here to identify the platform. how we handle facts and data →
next step

Tell us what you're running. We'll tell you what we'd do first.

A 30-minute working session with a senior engineer. No slides.

Book a working session See the case studies
useful to bring
  • The platform and the version you're on
  • Where you need to get to, and by when
  • What's custom: rules, plugins, integrations
  • Any audit finding or deadline driving it