The Tanzu portfolio is winding down in waves. The first wave hit in 2025. The second wave is hitting now.
Tanzu Platform SaaS got an End of Availability notice in May 2025. Three Tanzu Application Platform components — App Live View, App Accelerator, App Configuration Service — went out of support in August 2025. The surviving pieces of the Tanzu Platform portfolio got renamed and repositioned toward AI and private PaaS use cases through October 2025 and April 2026.
The second wave is the Kubernetes layer. Tanzu Kubernetes Grid Standalone v2.5.4 is the final enterprise release. Broadcom is migrating customers to vSphere Kubernetes Service — the product formerly known as TKG Service — which runs as a Supervisor Service on vSphere 8.0 Update 3 or later and lives most naturally inside VMware Cloud Foundation 9.
For teams who built their Kubernetes architecture on Tanzu products, the decision point is here. Three migration paths look credible. Each one carries different costs and reaches a different end state.
Path One: Migrate to VKS within VMware Cloud Foundation
Broadcom wants every Tanzu Kubernetes customer on Path One. VMware Cloud Foundation 9.0.1 added VKS Cluster Management directly into VCF Automation, which means the cluster lifecycle, backup, and upgrade story now sits inside VCF rather than running alongside it.
The technical requirement is real. VKS only deploys against vSphere Supervisor, which in turn requires vSphere 8.0 Update 3 or the equivalent VCF 9 release. Teams running older vSphere versions cannot move to VKS without an underlying hypervisor upgrade. The hypervisor upgrade cycle and the Kubernetes platform upgrade cycle converge into one motion, which is convenient for some teams and inconvenient for others.
The licensing reality is also real. VKS makes the most economic sense as part of the VCF bundle. Teams running vSphere standalone licensing are increasingly being pushed into VCF subscriptions at renewal, which is one of the reasons Broadcom’s per-core pricing trajectory has gotten so much attention.
This path makes sense for teams that have significant Tanzu-specific tooling investments they cannot easily move, that have already accepted the move into VCF for other reasons, and that want their Kubernetes platform tightly integrated with their hypervisor refresh cadence.
Path Two: Migrate to OpenShift or Rancher Prime on Existing vSphere
Path Two replaces the Kubernetes distribution but keeps the hypervisor underneath. The lateral move changes who runs the Kubernetes layer without disrupting the infrastructure layer.
OpenShift carries the closest set of commercial developer-platform features to what TAP and TKG offered together. Red Hat OpenShift GitOps, OpenShift Pipelines, OpenShift Service Mesh, and OpenShift Serverless are all part of the core platform. Teams that valued TAP for its developer-experience features find OpenShift the closest commercial equivalent, with a different operator surface and a different license model. The Red Hat ecosystem is large enough that the move feels familiar to most operations teams.
Rancher Prime carries the lighter app-platform layer and the richer multi-cluster management layer. SUSE positions Rancher Prime as the operator-friendly option, with strong cluster lifecycle, fleet management, and observability tooling. The app-platform features are mostly opt-in rather than baked in. Teams that want Kubernetes distribution support without the opinionated app-platform layer often find Rancher Prime closer to the mark.
Both paths keep vSphere underneath. Both replace the Tanzu Kubernetes layer with a different commercial distribution and a different vendor relationship. Both add a license line and an account team. Neither path retires the hypervisor cost, which means the Broadcom relationship continues on the infrastructure side even if the Kubernetes layer changes hands.
This path makes sense for teams that want Kubernetes vendor diversity without changing the hypervisor, that have operations teams comfortable picking up a new commercial distribution, and that are not interested in revisiting the deeper infrastructure architecture this cycle.
Path Three: Collapse the Stack with a Unified Platform
Path Three uses the Kubernetes replatform as the moment to reset the architecture. The hypervisor layer comes out at the same time.
The argument for this path is structural rather than tactical. VMware Kubernetes customers run three independent systems coordinated through APIs. The hypervisor is one vendor. The Kubernetes distribution is a second vendor. The overlay storage that fills the gap when vSphere storage policies do not extend cleanly into Kubernetes is often a third vendor.
What separates Path Three from the other two is what happens when storage, networking, virtualization, containers, data availability, and data protection all run on the same unified platform. The boundaries between them dissolve. A persistent volume for a Kubernetes pod and a virtual disk for a VM become the same storage primitive. A snapshot covers both. A replication policy covers both. Disaster-recovery failover treats them as one environment rather than two. The same Kubernetes backup approach that protects a containerized workload protects its VM-based dependencies in one motion. The network fabric is shared. The data services are shared. The control plane is shared.
That architecture rewrites the operations math. Snapshot policy management collapses into one engine instead of three. Replication and disaster recovery span containers and virtual machines from a single console. Backup architecture follows the workload rather than the boundary between infrastructure layers. Telemetry stitches together across what used to be three independent observability domains. The seams where outages live disappear because the seams themselves disappear.
The five-year cost picture shifts as a result. Three vendor contracts collapse to one. Three patch schedules become one. Three teams to staff, or one team running three runbooks, becomes one team running one platform. Failure recovery time scales with the number of vendors involved in a single outage, and Path Three reduces that number from three to one.
The TAP and TKG-Standalone wind-down forces a Kubernetes replatform decision regardless. The question is whether to replatform only the Kubernetes layer (Paths One and Two) or to replatform the whole stack in one motion. Replatforming the whole stack is bigger up front. It retires three vendor relationships instead of one. It produces an environment where containers and virtual machines run side by side on the same storage fabric, the same network, and the same control plane.
This path makes sense for teams whose vSphere renewal is also approaching, who are open to revisiting the broader infrastructure architecture, and whose operations teams can absorb a platform change rather than a distribution change.
The VergeOS Example
VergeOS is one example of a platform built for the third path. The Kubernetes integration ships as four upstream Helm charts on the verge-io GitHub repository — a CSI driver, a Cloud Controller Manager, a Cluster Autoscaler, and a Rancher node driver. The cluster that comes up is vanilla upstream Kubernetes. There is no fork. There are no proprietary CRDs to track every upstream release on the vendor’s timeline.
Rancher remains the management plane. The teams running Rancher today keep running Rancher. The platform underneath changes. The cluster object, the namespace policy, and the operator UI stay the same. VergeIO has production validation on a regulated sports-betting platform — over 180 Kubernetes nodes carrying live transaction workload, zero cross-vendor support tickets, one platform contract.
The Tanzu wind-down has forced a Kubernetes replatform decision on every VMware-based Kubernetes customer. The question is what to do with that decision. Paths One and Two keep the three-vendor architecture intact and replatform only the Kubernetes layer. Path Three uses the same motion to retire the hypervisor and the overlay storage at the same time. The work up front is bigger. The architecture that comes out the other end is smaller, simpler, and cheaper to run. Platform-level decisions hit a team’s calendar once every five to seven years. The Tanzu wind-down put that decision on the calendar today. Spending it on a single-layer replatform is the more expensive choice over five years, not the cheaper one.
Choosing
Four questions worth asking before picking a path.
How much Tanzu-specific tooling is woven through your stack today? The more Tanzu-specific the tooling, the harder Paths Two and Three become and the more attractive Path One becomes.
What is your vSphere renewal timing? Path One requires moving to recent vSphere versions and accepting deeper VCF integration. Path Three is most viable when the hypervisor renewal is also on the table.
Do you run AI or GPU workloads alongside the Kubernetes clusters? Platform-level GPU virtualization changes the calculus for unified-platform paths, again making Path Three attractive.
What is the operations team’s appetite for a platform change? Paths One and Two are distribution changes. Path Three is a platform change.
Each path has defenders. Each path has tradeoffs. The wrong move is to wait for the situation to clarify, because the wind-down dates are real.
##
George Crump is the CMO of VergeIO and the founder of StorageSwiss.
