OpenShift upgrades planned ahead, so clusters stay on a supported minor release.
Extended Update Support Term 2 for OpenShift 4.14 ends on 31 October 2026, and 4.16 is already out of maintenance. We plan EUS-to-EUS upgrades and move clusters off OpenShift SDN. We can also run the platform alongside your team.
Cohash upgrades, builds and supports Red Hat OpenShift Container Platform.
We plan EUS-to-EUS paths, for example 4.16 to 4.18 or 4.18 to 4.20. Clusters on OpenShift SDN have to move to OVN-Kubernetes before 4.17, and we do that migration. We check operators and deprecated APIs and rehearse on a non-production cluster first. The newest minor is OpenShift 4.22, released 9 June 2026 on Kubernetes 1.35.
you probably need this if
Clusters run 4.14 and the EUS Term 2 end on 31 October 2026 is close.
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.
Cluster inventory with version, channel, network plugin and support date
Operator compatibility matrix for the target release
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
09 Jun 2026OpenShift 4.22 Newest minor. Kubernetes 1.35 with CRI-O, RHCOS on RHEL 9.8 packages, RHCOS 10.2 in Technology Preview, runC deprecated. An EUS release with Term 1 to June 2028. source ↗
25 Aug 20264.18 maintenance ended 4.18 maintenance support ended 25 August 2026. EUS Term 1 runs to 25 February 2027 and Term 2 to 25 February 2028. source ↗
today · Oct 22, 2026
31 Oct 2026ahead4.14 EUS Term 2 ends 4.14 Extended Update Support Term 2 ends 31 October 2026. Term 3 runs to 31 October 2027. source ↗
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.source ↗
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.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · red hat openshift estate3 open
openClusters run 4.14 and the EUS Term 2 end on 31 October 2026 is close.
recurringThe network plugin is still OpenShift SDN and nobody has scheduled the migration.
blockedEvery upgrade is followed by a week of broken operators and failed deployments.
exposure
EUS-to-EUS upgrade planningOpenShift SDN to OVN-Kubernetes…Cluster builds and platform…OpenShift VirtualizationOperator and API readinessRun support
startrehearsehandover
Cluster health and inventory
Upgrade path
Rehearsal
Production and handover
we are here
ready to hand over
All clusters run a supported EUS release on OVN-Kubernetes, and the team has a tested…
The decision on how many VMs to move rests on pilot results, and the clusters have…
Cluster inventory with version, channel, network plugin and support date
Operator compatibility matrix for the target release
chapter 01 · where it hurts
Why teams reach out
Clusters run 4.14 and the EUS Term 2 end on 31 October 2026 is close.
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.
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
chapter 03 · how it runs
Our approach
Cluster health and inventory
Upgrade path
Rehearsal
Production and handover
chapter 04 · where you end up
What changes
All clusters run a supported EUS release on OVN-Kubernetes, and the team has a tested path for the next hop to 4.20.
The decision on how many VMs to move rests on pilot results, and the clusters have storage and backup designed for VMs.
Cluster inventory with version, channel, network plugin and support date
Operator compatibility matrix for the target release
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.
Paths between even-numbered EUS releases, with control plane-only updates, paused worker pools and operator compatibility checked for every hop.
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.
New clusters on bare metal, VMware or public cloud, with GitOps for cluster configuration, identity provider integration and quota models per team.
VM workloads planned and moved onto OpenShift Virtualization, with storage, networking and backup designed for VMs as well as containers.
Installed operators checked against the target release, deprecated Kubernetes APIs found in manifests and Helm charts, and owners told before the upgrade.
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.
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.
Installed operators checked against the target release, deprecated Kubernetes APIs found in manifests and Helm charts, and owners told before the upgrade.
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
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.
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.
Afterwhere you end up
All clusters run a supported EUS release on OVN-Kubernetes, and the team has a tested path for the next hop to 4.20.
case file 02
Moving two hundred VMware VMs onto OpenShift Virtualization
composite · not a client story
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.
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.
Afterwhere you end up
The decision on how many VMs to move rests on pilot results, and the clusters have storage and backup designed for VMs.
We don't start a step until the last one has produced something you can check.
step 01
Cluster health and inventory
We record each cluster's version, update channel, network plugin, installed operators, deprecated API usage and etcd health, plus who owns the workloads.
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.
step 03
Rehearsal
The full path runs on a non-production cluster built the same way as production, with application smoke tests and timings recorded.
step 04
Production and handover
Production clusters upgrade in a planned order, worker pools unpaused in batches, and the team gets runbooks and GitOps-managed 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.
Where OpenShift sits between developers, infrastructure and operations
Developers push code through CI into OpenShift, which runs containers and VMs on bare metal, VMware or cloud infrastructure. Identity comes from Entra ID or Okta, secrets from Vault, and alerts flow to ServiceNow for incident handling.
These are working documents, written against your configuration, so your team can run them without us.
inventory01
Cluster inventory with version, channel, network plugin and support date
yours to keep
document02
Operator compatibility matrix for the target release
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
OpenShift SDN to OVN-Kubernetes migration plan and test results
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.
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.
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.
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.
Q3
Which operators and Helm charts will break on the target release?
Most post-upgrade incidents trace back to third-party operators and deprecated APIs. Those need to be found and fixed before the maintenance window.
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.
Q5
Who on your team holds current Red Hat OpenShift certifications?
Red Hat renamed its certifications in May 2026. Ask for the current names and exam codes, for example EX280 and EX316.
01How long is each OpenShift minor supported?
Red Hat's policy gives each minor Full Support until six months or 90 days after the next minor's GA, and Maintenance to 18 months after GA. Even-numbered minors are EUS releases with optional terms that extend support to 36 or 48 months in total.
02Can 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.
03How 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.
04Should we use OpenShift Virtualization instead of 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.
05Do you staff OpenShift engineers?
Yes. We place OpenShift administrators, platform engineers and SREs on contract, contract-to-hire and permanent terms, onsite in the US or nearshore and offshore, across all time zones.
services
Related services
Projects on Red Hat OpenShift usually end up touching one of these, so they're worth a look.
