A platform owner asked me a fair question last quarter: our TKGI clusters are stable, nobody is complaining, so why are we being told to move? He was right that the clusters were stable. He was wrong that stability buys time. What ends a platform is rarely the platform itself, it is the infrastructure underneath being taken away, and that is exactly what is happening to Tanzu Kubernetes Grid Integrated. This series is 26 parts about moving a TKGI estate onto Red Hat OpenShift Container Platform 4, and this opening part covers what forces the decision, what OpenShift actually gives a TKGI shop, and the one assumption about migration tooling that wastes the most time.

Forcing function, NSX 9.1 and the 2027 clock

Two facts set the timetable, and neither is a matter of opinion. Broadcom has published that official End of Support for TKGI takes effect in October 2027. More immediately, TKGI 1.2x is entirely incompatible with VMware Cloud Foundation 9.1 and NSX 9.1, because NSX Container Plugin 9.1 explicitly removed all support for the TKGI platform. That removal is architectural rather than commercial. NSX 9.x dropped the legacy Management Plane API, and TKGI depends on that API for cluster lifecycle and dynamic network provisioning, so the two simply cannot run together.

Read what that means for your change calendar. Your Kubernetes platform is now pinned to an infrastructure version. If any other workload, any compliance requirement or any hardware refresh pushes you toward VCF 9.1 and NSX 9.1, TKGI has to be gone first. Broadcom’s own guidance in that knowledge base article is blunt about the sequence: keep the current compatible infrastructure while TKGI runs, provision a separate modern container platform, migrate applications and data across with standard tooling such as Velero, then decommission TKGI and only then upgrade the infrastructure. Direct in place conversion is not offered.

Working out your own exposure takes about an hour and is worth doing before the first planning meeting. Write down three numbers: your current TKGI version, your current NSX version, and the date your infrastructure team has pencilled in for the next VCF major upgrade. If that third date lands before your Kubernetes migration completes, you have a collision rather than a project, and the conversation you need is with the infrastructure team rather than the application owners. I have seen this discovered late twice, and both times it turned a comfortable eighteen month plan into a scramble, because nobody had connected a storage driven VCF upgrade to the container platform sitting on top of it.

Broadcom names VKS as the destination in that article, which is reasonable given who wrote it. VKS is a genuinely good answer and this site covers it in depth in the TKGI to VKS Series. It is not the only answer. Plenty of organisations reading that same paragraph concluded that if they have to rebuild the Kubernetes layer anyway, this is the moment to stop coupling it to a hypervisor roadmap they no longer control. That conclusion leads to OpenShift, and it is the conclusion this series follows.

flowchart TD
  A[TKGI estate today] --> B{Infrastructure roadmap}
  B -->|Stay below VCF 9.1| C[No forced move yet, clock still runs to 2027]
  B -->|Adopt VCF 9.1 and NSX 9.1| D[TKGI unsupported by NCP 9.1]
  D --> E{Pick a landing place}
  E -->|Keep platform on VMware stack| F[VKS on VCF 9]
  E -->|Decouple from hypervisor vendor| G[OpenShift 4 on vSphere]
  G --> H[Velero out of TKGI, OADP into OpenShift]

OpenShift described for a TKGI operator

Strip away the marketing and OpenShift Container Platform 4 is a Kubernetes distribution that manages its own operating system. Nodes run RHEL CoreOS, an immutable image that you do not patch by hand and do not log into for routine work. Cluster components are installed and reconciled by Operators, which are controllers that hold a piece of the platform at a declared state, coordinated by Operator Lifecycle Manager. Upgrades are a single declarative act against the cluster, not a tile by tile campaign in a separate console. If you have spent years running BOSH deployments through Ops Manager, that consolidation is the headline: one control plane manages the operating system, the platform components and the workloads.

Networking is OVN-Kubernetes rather than NSX-T with NCP. Ingress runs through an ingress controller that exposes Route objects, an OpenShift resource that predates the Kubernetes Ingress API and still carries features Ingress lacks. Storage on vSphere comes through the vSphere CSI driver, which is the same interface TKGI clusters already use, so persistent volume mechanics are the most familiar part of the whole move. Identity goes through OpenShift OAuth, which happily federates to the same LDAP directory your UAA setup points at today.

Day to day operations change more than the architecture diagram suggests. On TKGI you patch by importing a tile into Ops Manager, staging it, and letting BOSH roll virtual machines according to a manifest you mostly do not read. On OpenShift you select a target version in the web console or with a single command, and cluster operators drain and replace nodes with new RHEL CoreOS images while reporting progress against the cluster version resource. Both approaches are declarative underneath. What differs is that OpenShift keeps the whole loop inside the cluster API, so your monitoring, your alerting and your access control apply to platform upgrades the same way they apply to workloads. Teams that liked BOSH tend to like this. Teams that never really learned BOSH find it a relief.

Here is the mapping I hand to teams on day one of an assessment. It is deliberately blunt about which rows are easy and which will consume real engineering weeks.

OpenShift and VKS as competing landing places

Choosing between them is an organisational decision wearing technical clothes. Both give you a supported Kubernetes platform on vSphere hardware you already own. They differ in who owns the roadmap, what your operators need to learn, and how much of your existing VMware investment carries forward. I have watched teams argue this for six weeks and land where their procurement position pointed on day one, so it pays to be honest about the signals early.

Support windows you are actually buying

One reason teams move to OpenShift is a published lifecycle they can plan against, so it is worth knowing the shape of it before you commit. Red Hat aims for a minor release roughly every four months and keeps at least four minor versions supported at once. Full Support for a given minor ends six months after general availability, or ninety days after the next minor ships, whichever is later. Maintenance Support ends at eighteen months after general availability. Even numbered minors are designated Extended Update Support, and paid add-on terms stretch a single release to twenty four, thirty six or forty eight months.

Those numbers matter for a migration because they decide how often your new platform demands attention after you land on it. A team that lifts onto a standard minor inherits an eighteen month treadmill. A team that lands on an EUS release with a purchased term buys itself years of quiet. Pick the version before you pick the install date.

Migration toolchain trap that costs a sprint

Almost every team I have worked with makes the same assumption in week one. Red Hat ships something called Migration Toolkit for Containers, so surely that is the tool for migrating containers into OpenShift. It is not, at least not from where you are standing. MTC moves application workloads between OpenShift clusters and from OpenShift 3 to OpenShift 4. Its source has to be an OpenShift cluster. A TKGI cluster is not one, and no amount of configuration makes it one.

What you actually build is a two ended toolchain. Velero runs on the TKGI side and writes backups of namespaces, resources and volume data to object storage. On the OpenShift side you install OADP, which is Red Hat’s supported packaging of Velero delivered as an Operator, and restore from that same object storage. Amusingly, installing MTC pulls OADP in behind it through Operator Lifecycle Manager, which is part of why the confusion persists. Same engine underneath, different entry point, and only one of the two entry points accepts a non OpenShift source.

Field note from a stalled platform assessment

An assessment I ran for a financial services client is the reason I now open every engagement with the admission audit. We scoped eight weeks. Four for networking design, two for storage, two for identity and cutover planning. Migration tooling was a single line item because everyone in the room assumed MTC would handle it. Both assumptions were wrong within a fortnight.

Week two, we stood up a small OpenShift cluster and restored one namespace by hand as a smoke test. Nineteen of the twenty three pods refused to start. Every failure traced to admission: images that assumed they could run as root, a monitoring agent that wanted a host path mount, and one long serving Java service whose base image hardcoded a user ID that fell outside the range OpenShift allocates to the namespace. None of that was visible in any inventory we had taken, because TKGI had simply never asked those questions. Then the MTC assumption collapsed too, when we read the supported source matrix properly and discovered we needed to build a Velero and OADP pipeline that nobody had costed.

Eight weeks became fourteen. Six weeks of overrun, and all six went to work we could have identified on day three with a single audit of pod security contexts across the estate. Nothing in that overrun was an OpenShift shortcoming. It was a planning failure, and it is entirely avoidable if you know where to look. Every assessment I have run since starts with the SCC audit, and none has slipped that far again.

Pick the landing place before you pick the tooling

My recommendation for this opening stage is narrow and it is deliberately not about technology. Settle the destination question first, in a room with whoever controls the subscription budget, using the decision signals table above rather than a feature comparison. A platform migration that changes destination in month three has burned everything built in months one and two. Once the destination is fixed, the technical work sequences itself, and this series follows that sequence: assess, design, build, migrate in waves, cut over, decommission.

What to avoid is the comfortable middle, where a team runs a proof of concept on both platforms for a quarter and calls it due diligence. Two half assessments produce less signal than one committed pilot, and the calendar is not generous. October 2027 sounds distant until you subtract procurement, training, an application remediation programme and a wave plan measured in months.

Your action for Monday: run one command against every TKGI cluster and collect the security context of every running pod, specifically which ones set runAsUser, request privileged mode, or mount host paths. Count them. That number, more than any licensing spreadsheet, tells you what this migration will really cost. Part 2 puts TKGI and OpenShift side by side component by component, and Part 5 turns that Monday audit into a full inventory procedure with the commands to run it.

If your migration is heading toward AI workloads once the platform lands, the Red Hat Gen AI Series covers OpenShift AI on top of exactly this foundation, and the full route map for this migration lives on the TKGI to OpenShift guide.

References

Broadcom KB 446224, Incompatibility between TKGI and VCF 9.1 / NSX 9.1
Red Hat OpenShift Container Platform Life Cycle Policy
Red Hat, Managing Security Context Constraints, OpenShift 4.18

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts