Broadcom’s repackaging raised VMware Tanzu pricing and bundle minimums, often layered on top of vSphere licensing you’re already re-evaluating. Moving to upstream Kubernetes removes the Tanzu subscription, but as with any opinionated platform, the work is replacing what Tanzu added and unwinding its vSphere coupling. Go in knowing what you’re rebuilding.
What Tanzu layered on top of Kubernetes
Tanzu is a portfolio, and what you’re replacing depends on what you used:
- TKG (Tanzu Kubernetes Grid), cluster lifecycle, often integrated with vSphere (Supervisor clusters, vSphere with Tanzu).
- Tanzu Mission Control, multi-cluster management/policy.
- Tanzu observability, build service (kpack), and packages, add-on tooling.
- Tight vSphere integration, the Supervisor and vSphere networking/storage hooks.
Inventory which of these you actually depend on; that scopes the migration.
The value hiding in the bundle
The value in the bundle is integration, and naming it makes the rebuild concrete. Tanzu ties cluster lifecycle, fleet policy, builds, and storage and networking to vSphere so that provisioning a cluster and wiring it into your infrastructure is a supported, largely turnkey path. Supervisor clusters let vSphere itself provision Kubernetes, and Tanzu Mission Control gives one place to apply policy across the fleet. On upstream Kubernetes those become separate decisions you assemble: a lifecycle tool, a management plane, a CI system, a registry, and CSI and CNI drivers you select and keep compatible. The workloads move easily because they are already containers. The effort and the ongoing cost sit in reproducing that integration and owning its upgrades, so scope a platform team for it rather than assuming the license line is the whole saving.
Which distribution to land on
“Upstream Kubernetes” still needs an owner for lifecycle and upgrades. Common choices:
- kubeadm / Cluster API, roll-your-own clusters, maximum control.
- RKE2 / Rancher, a supported open distribution with a management plane (a natural fit if you want Tanzu-Mission-Control-like multi-cluster management).
- k3s / Talos, lightweight or immutable options.
Decide this first, it drives node provisioning, upgrades, and HA.
Component-by-component replacements
- TKG cluster lifecycle → Cluster API / RKE2 / kubeadm.
- Tanzu Mission Control → Rancher (or Argo CD/Flux + policy engine) for fleet management.
- kpack / build service → external CI (Tekton, Argo Workflows, GitHub Actions) + a registry like Harbor.
- Tanzu packages → Helm charts / Operators.
- vSphere Supervisor networking & storage → standard CNI (Cilium/Calico) and CSI drivers (you can still run on vSphere via the vSphere CSI/CPI, just without the Tanzu Supervisor layer).
The migration flow
- Inventory Tanzu clusters, workloads, the Tanzu components in use, and vSphere integrations.
- Stand up the target clusters on your chosen distribution, with CNI, CSI, ingress, a registry, and CI.
- Migrate workloads with Velero (back up namespaces + persistent volumes from Tanzu, restore to the new cluster); convert any Tanzu-specific manifests/packages to standard Kubernetes resources and Helm.
- Re-map networking/storage and RBAC, and wire up GitOps (Argo CD/Flux) for redeploys.
- Validate per namespace: pods schedule, ingress resolves, storage binds, images pull, CI rebuilds.
- Cut over namespace by namespace, keeping the Tanzu cluster available for rollback through hypercare.
Validation before cutover
Because Tanzu couples storage and networking to vSphere, validation focuses on the seams that coupling hid. Per namespace, confirm that pods schedule on the new distribution, that PVCs bind to the storage class you mapped them to and mount with the right data, and that your CNI applies the network policies you re-created. Check that ingress resolves and images pull from the new registry, and run a CI build so a source change flows through to a redeploy. Reconcile the namespace through GitOps so the declared state matches what is live. Keep the Tanzu cluster available so you can re-point back if a wave regresses, and only retire a namespace once its replacement has served real traffic through hypercare.
Unwinding the vSphere coupling in storage, networking, and RBAC
The parts of Tanzu most coupled to vSphere need the most deliberate re-mapping. Storage classes that resolved through the vSphere CSI under a Supervisor cluster must be re-declared on the target with provisioners it can actually use, and every PVC has to bind to a class that exists there. Network policies that leaned on Supervisor networking become explicit NetworkPolicy objects enforced by your chosen CNI, so audit which flows were implicitly allowed before you lock them down. Tanzu’s RBAC and any Mission Control policies do not transfer, so recreate roles and bindings in native Kubernetes RBAC per namespace. Doing this in version control keeps the target declarative and lets GitOps reconcile it, rather than hand-tuning a live cluster.
The vSphere question
If you’re also leaving vSphere (Broadcom), sequence it: you can run upstream Kubernetes on your new hypervisor (Proxmox, Nutanix, etc.) or bare metal. Don’t migrate Tanzu→K8s and the underlying platform in one step, do one, validate, then the other.
Our take
Tanzu → upstream Kubernetes removes the Broadcom-bundled subscription but turns a managed platform into assemble-and-own. Choose a distribution first, rebuild the platform services (management, builds, registry), migrate workloads with Velero + GitOps, and unwind the vSphere Supervisor coupling deliberately. Model the per-core savings against your new platform-team effort in the calculator above, and treat the figures as provisional until you scope your target stack.