There is no upgrade button from TKGI to VKS. If you are waiting for a tile in Tanzu Operations Manager that quietly turns your BOSH managed clusters into vSphere Supervisor clusters, stop waiting, because it does not exist and it is not coming. TKGI, the platform once sold as Enterprise PKS, and VKS, the vSphere Kubernetes Service built into VMware Cloud Foundation 9, are different machines with different control planes. Moving between them is a migration you plan, not a patch you apply. This series runs 26 parts for exactly that reason, and this opening part covers what VKS is, why the old platform is winding down, and why the word migration governs every decision that follows.

What VKS actually is

VKS stands for vSphere Kubernetes Service, and until recently it went by TKG Service or TKGS, so if your notes say TKGS you are already looking at the same product under an older name. It is the piece of VMware Cloud Foundation 9 that provisions and manages Kubernetes workload clusters, and it does that work through the vSphere Supervisor. Supervisor is a Kubernetes control plane baked directly into vSphere, running on ESX hosts and exposing a declarative Kubernetes API from inside the hypervisor. You do not stand up a separate management cluster on its own pool of virtual machines to get it. You enable Supervisor on a VCF workload domain, and vSphere becomes the thing that hands out Kubernetes clusters on request.

Once Supervisor is running, an operator or a development team creates a vSphere Namespace, sets quota and permissions on that boundary, and then asks VKS for a cluster inside it. VKS builds the cluster, holds it at the declared state, and upgrades its Kubernetes version on an independent schedule without disrupting the workloads riding on top. Broadcom documents two container network options for those clusters, Antrea as the default and Calico as the alternative, and high availability that can span up to three vSphere Zones so a cluster survives the loss of an entire vSphere cluster. Storage comes from vSphere through the Container Storage Interface, the standard plug that lets a pod request a vSphere backed persistent volume. Read the pattern carefully: compute, networking and storage all come from vSphere, and Kubernetes is now a first class citizen of the platform rather than a guest bolted onto it.

That single change, Kubernetes living inside vSphere instead of beside it, is the whole story of why this migration exists. If you want the deep component tour of the target platform, the VKS Series already covers VKS on its own terms, and this migration series leans on it rather than re-teaching it. Here the job is narrower: get you from the platform you have to the platform it describes.

Why TKGI is winding down

TKGI reached the end of its road for reasons that have little to do with whether the product works and everything to do with the platform underneath it. TKGI never ran on vSphere alone. It leaned on BOSH for release engineering and virtual machine lifecycle, on Tanzu Operations Manager for tile based install and patch, and on NSX-T for pod networking and load balancing. Each of those layers is a separate product with its own patch cadence and its own support clock. VCF 9 folds the Kubernetes control plane into vSphere and retires the need for that outside scaffolding, which is the direction Broadcom has set for its Kubernetes platform since acquiring VMware. When the foundation a product stands on is deprecated, the product on top of it goes with it, however well it runs.

Broadcom has not published, at least not anywhere I could confirm this week, a single clean end of general support date for the TKGI line that I would quote to a change board without checking it live. Its last minor line is TKGI 1.20, and the direction of travel is clear even where a precise date is not. Pull your own version dates from the Broadcom Product Lifecycle Matrix before you build any timeline around them, and treat that portal as the only authority. Broadcom guidance on what end of support means in practice is blunt and worth internalising: your existing clusters keep running, you can still create, delete and upgrade them within the supported path, but you lose the ability to open a support case. For a production Kubernetes estate, losing support is the moment the platform stops being viable, whatever the console still lets you do. I mark the exact dates here as [VERIFY] on purpose, because inventing one would be worse than telling you to go and read it.

Migration, not upgrade, and what the word changes

Here is where teams lose months. Twenty years of vSphere trains one reflex: a major version is something you upgrade into. You schedule a window, run the installer, the platform returns on the new version, and the workloads never noticed. That reflex is wrong here, and clinging to it is the most expensive mistake I watch people make with this move. No code path turns a BOSH managed TKGI cluster into a Supervisor managed VKS cluster. Control planes differ, machine lifecycle differs, the networking model differs, and identity plumbing differs. You cannot convert one into the other in place any more than you can upgrade a car into a boat by changing a setting.

What you do instead is stand VKS up beside the running TKGI estate, on the same or adjacent hardware, and move workloads across in waves. You back an application up on TKGI, restore it onto VKS, prove it, cut its traffic over, and only then reclaim the old capacity. Velero, the open source backup and restore tool for Kubernetes, is the workhorse for that copy step, and later parts of this series live inside it. Carry one mental model from here forward: two platforms run at once for a while, and you are draining one into the other, not reshaping a single platform in place. Everything about budget, risk and rollback flows from that picture.

flowchart LR
  A[Assess TKGI estate] --> B[Stand up VKS on VCF 9]
  B --> C[Migrate workloads in waves]
  C --> D[Cut traffic over and validate]
  D --> E[Decommission TKGI and Ops Manager]

How the old stack maps to the new one

Keep this table. Every later part fills in one of its rows with real commands and YAML, so it doubles as a map of the series. Read it as a translation, not a swap, because in several rows the concept survives while the tool underneath it changes completely.

Two rows deserve a flag now. Networking is not a like for like port, and the shift from an NSX-T load balancer to either the Foundation Load Balancer or NSX Avi is a design decision with cost and latency consequences that Part 7 and Part 13 work through in detail. Identity changes shape too, moving from UAA and LDAP to vCenter SSO with Pinniped, which means your RBAC bindings do not copy across untouched. If NSX is where your anxiety sits, the NSX Series owns that ground and is the right place to send a networking colleague while you keep planning the migration.

What changes for you as an operator

Day to day, the biggest change is how many separate things you patch. On TKGI you keep several products current on their own schedules, and each one is a place a version can drift, a maintenance window can slip, or a support clock can expire. Count the surfaces honestly: BOSH, Ops Manager, the TKGI tile, NSX-T, and the Harbor tile are five products you version and patch independently. On VKS the platform lifecycle collapses toward one, because Supervisor rides with vSphere and VCF, and the VKS clusters upgrade their Kubernetes version asynchronously on top. Fewer moving parts is not marketing here, it is a smaller attack surface, fewer upgrade dependencies to sequence, and fewer clocks to watch.

Your muscle memory changes with it. The BOSH deployment manifests, the Ops Manager apply changes ritual, and the tile ordering you learned to sequence carefully all go away. In their place you work with vSphere and kubectl, vSphere Namespaces for tenancy, and cluster classes for shape. Some of that is a genuine relearn, and this series does not pretend otherwise. The trade is fewer independent lifecycles for a new provisioning model, and for most operators that is a good trade once the initial unfamiliarity wears off.

Signals it is time to start planning

The common advice is to wait until TKGI nears end of support, then move. That advice is wrong, and the reason is arithmetic. A real migration of a production estate takes months, not a weekend, because you migrate in waves and validate each one. If you start when the clock is nearly out, you run the hardest workloads under deadline pressure with no fallback platform left to retreat to. The estate signals below are your cue to begin, and none of them is a countdown timer.

One clause on a question that always comes up: TAS, the Cloud Foundry application platform sometimes called TAS for VMs, is not part of this. If you run TAS as well, its successor is Tanzu Platform for Cloud Foundry, a separate path, and you should not fold it into a VKS plan. This series is about Kubernetes clusters, from TKGI to VKS, and nothing else.

Start VKS beside TKGI now, not at end of life

My recommendation for anyone running TKGI today is plain: treat this as a migration project you kick off on your own schedule, not a deadline you react to. Stand VKS up beside TKGI while both can coexist, migrate the low risk workloads first to build the muscle, and keep the fallback platform alive until the last wave is proven. The teams that struggle are the ones who confused a platform change with a patch, waited for a window that never comes, and met the support cliff with the hardest work still ahead. Avoid that by starting the assessment early, even before you have budget approval to build, because the inventory itself is the input every later decision needs.

Next part sets TKGI and VKS side by side component for component, so the architecture differences behind this migration stop being abstract. Before then, go and pin down that one support date, and bring it to the assessment.

References

• Broadcom TechDocs, vSphere Kubernetes Service Architecture and Components, VCF 9
• Broadcom Knowledge, expected behavior when a TKGI release reaches End Of Life or End Of Support
• Broadcom Product Lifecycle Matrix, confirm your TKGI end of support date

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