VMware Tanzu EOL: Mapping a Migration Path to Open Source Alternatives

The Tanzu Landscape After Broadcom

Broadcom's acquisition of VMware introduced abrupt changes to the Tanzu product lineup: bundle-only pricing, elimination of perpetual licenses for several SKUs, and support timelines shortened for components that were previously positioned as long-term supported releases. For platform teams that built internal developer platforms on Tanzu Application Service or Tanzu Kubernetes Grid, the calculus of staying versus migrating has shifted sharply.

Inventory Before Architecture

The first mistake most teams make is jumping straight to evaluating replacement technologies before they have a clear picture of what they are actually running. A thorough inventory should cover:

• Every Tanzu component version in production, including Build Service, Application Catalog, and Service Mesh.
• Custom resource definitions (CRDs) that application teams have taken dependencies on.
• Integration points with adjacent systems: CI/CD pipelines, secrets management, observability stacks, and identity providers.
• Internal automation scripts and Terraform modules that call VMware-specific APIs.

Candidate Replacement Stack

For most enterprise use cases the replacement stack converges on a small set of CNCF-graduated projects. Vanilla upstream Kubernetes — whether self-managed or via a distribution like RKE2 or k0s — replaces TKG as the runtime layer. Crossplane or Cluster API handles multi-cluster lifecycle where Tanzu Mission Control previously did. Paketo Buildpacks, which are open source and spec-compliant, replace Tanzu Build Service for most workloads. cert-manager, Contour, and Flux or Argo CD cover the remaining surface area that TAS provided via buildpack conventions.

What Does Not Have a Direct Replacement

Tanzu Application Service's developer experience — particularly its cf push abstraction — has no single drop-in replacement. Teams that want to preserve that abstraction typically evaluate Korifi (the open source Cloud Foundry on Kubernetes project) or invest in a thin internal developer platform layer built on top of Backstage and standard Kubernetes primitives.

Migration Sequencing

OSSeva's Exit Tanzu engagement follows a three-phase sequence: assess (inventory and risk-rank workloads), pilot (migrate a representative low-risk workload to validate the replacement stack), and migrate (batch-migrate remaining workloads with automated pipeline conversion). This sequencing ensures that the replacement stack is validated under real conditions before the main migration wave begins, and that rollback paths are preserved throughout.

Licensing Risk During Transition

A frequently overlooked risk during Tanzu migrations is continued usage of Broadcom-licensed components past their support or license renewal dates. Teams sometimes extend migration timelines without realising that running an expired Tanzu license exposes the organisation to compliance and audit risk. A parallel track for license compliance tracking, separate from the technical migration work, is essential.

Conclusion

Migrating off Tanzu is a well-scoped engineering problem, not an existential platform rebuild. The CNCF ecosystem provides capable replacements for every major Tanzu component. The key is sequencing the work carefully, starting with a rigorous inventory, and validating the replacement stack incrementally before committing to a full migration.