‍

Why Teams Are Leaving VMware Tanzu and What a Real Migration Path Actually Looks Like

Over the last few years, many organizations adopted VMware Tanzu with the right intentions: standardize Kubernetes, bring order to infrastructure sprawl, and give development teams a consistent platform to build on.

For some teams, Tanzu delivered on that promise.
For many others, it has become increasingly difficult to justify—financially, operationally, and culturally.

What we’re seeing now is not a rejection of Kubernetes or platforms.
It’s a growing realization that owning the platform is very different from operating the system.

This post walks through:

• Why teams are moving away from VMware & Tanzu
• The common migration paths (and where they go wrong)
• The real costs and risks teams underestimate
• What a more pragmatic Kubernetes migration can look like using Codiac

This is not a “rip and replace” argument. It’s a check of what is realistic and which approaches work well together.

‍

‍

Why Teams Are Re-Evaluating Tanzu

The most common reasons teams cite for leaving Tanzu fall into three categories.

1. Cost Has Become Hard to Defend

Tanzu’s licensing, combined with underlying VMware infrastructure and extended support costs, often grows faster than expected. What started as a consolidation play can turn into one of the largest line items in the infrastructure budget.

This is especially painful when:

• Clusters lag behind supported Kubernetes versions
• Extended support multipliers kick in
• Platform upgrades require multi-quarter planning cycles

The platform becomes something the organization serves, rather than something that serves the organization.

2. Platform Complexity Outpaced Team Capacity

Tanzu works best when you have a dedicated platform engineering function. Many teams don’t.

As environments grow, teams often find themselves juggling:

• GitOps pipelines
• Helm charts for internal apps
• Cluster-specific scripts and patches
• Manual fixes applied through tools like Lens
• Tribal knowledge that lives with a few senior engineers

The result is not standardization.
It’s fragile uniformity.

3. Developer Experience Quietly Degraded

One of Tanzu’s original promises was developer enablement. In practice, many teams report the opposite.

Developers often:

• Wait on platform teams for environments
• Avoid touching Kubernetes directly
• Work around the platform instead of with it
• Lose confidence that environments reflect production

When the platform slows delivery, teams stop trusting it.

‍

‍

The Common Tanzu Exit Paths (and Their Tradeoffs)

When organizations decide to move on, they typically explore one of three paths.

Path 1: Cloud-Native Kubernetes + DIY Tooling

This usually means managed Kubernetes (EKS, AKS, GKE) plus a combination of:

• ArgoCD or Flux
• Helm for everything
• CI/CD pipelines doing more and more orchestration
• Secrets tools, ingress controllers, policy engines, and custom scripts

This path lowers vendor lock-in, but shifts complexity back onto the team.

Many organizations underestimate how much ongoing engineering this requires to keep things uniform, secure, and auditable at scale.

This approach is usually endorsed by an ambitious internal team.  You must be prepared to 'own it'. Shifting timelines and budgets are just the tip of the iceberg. Brain-drain, tech-debt, and generally slower delivery is well established with this approach.

Path 2: Another Internal Developer Platform

Some teams evaluate platforms like Harness, Humanitec, or Kubermatic.

These tools can be powerful, but often:

• Still require significant platform engineering
• Focus heavily on pipelines or provisioning
• Don’t manage the running system holistically

Teams can end up recreating the same operational gravity they were trying to escape.

These tools can be thought of as buying a Lego set. All the individual pieces of the death star are there, you now have to assemble it brick by brick.

Path 3: Incremental, System-Focused Migration

A smaller—but growing—set of teams are taking a different approach:

• Keep Terraform (or existing provisioning)
• Standardize what happens inside the cluster
• Reduce the number of day-to-day tools
• Make environments repeatable by default
• Treat the system as a versioned whole

This is where Codiac fits.

Unlike path 1 & 2, an internal development platform to manage app systems wholistically reduces config & cluster drift and makes environments-on-demand repeatable, without overloading on tool-chains.

‍

What a Codiac-Based Migration Looks Like in Practice

Codiac does not replace Terraform or your cloud provider or your on-prem resources.
It sits after infrastructure is provisioned and focuses on operating Kubernetes consistently at scale. From the perspective of an SRE & development team.

Teams typically start with:

1. One non-production cluster
2. A handful of real workloads
3. Existing CI/CD or local CLI workflows

From there, they gain:

Snapshot-Based System Management

Instead of managing dozens of independent deployments (wall of YAML), configs, secrets, Codiac captures system snapshots that include:

• All workloads
• Configurations and secrets
• Resource footprint - mem/cpu, replica, HPA, etc.
• Routing and certificates
• Streaming logs, status, conditions

Upgrades and rollbacks become deterministic, not hopeful.

Blue/Green Across Clusters (Not Just Deployments)

Rather than upgrading clusters in place, teams create a new cluster, deploy the full system snapshot, and switch traffic when ready.

What used to take months becomes routine.

Self-Service Without Losing Control

Developers can deploy, test, and share environments without learning Kubernetes internals, while production remains guarded with RBAC and policy enforcement.

This mirrors what many teams wanted from Tanzu, without the operational overhead.

Infra IaC & k8s Infra

External provisioning of things like storage and managed services either stay as they are and executed s normal, or they can be added and triggered by a Codiac event, e.g. system deployment, namespace create/destroy, cluster create/destroy, etc.

Cluster uniformity and repeatability with components like CRDs, controllers, third-party agents is crucial for teams to stay productive. Disallowing cluster wide objects to drift from code is more of a myth these days.  Instead manage them fleetwide without git repos and branches stacking up.

‍

‍

A Real Example: A large Telco Tanzu-Like Goals, Without the Weight

A large telco who evaluated several platforms while looking to transition off Tanzu for their Kubernetes operations, including Harness, Humanitec, and Kubermatic.

What they were looking for wasn’t just tooling—it was:

• Developer ease of use
• System-level visibility
• A platform that felt closer to Tanzu’s promise

Using Codiac:

• Cut their proof-of-concept timeline by more than 50%
• Stood up a full system implementation with multiple clusters
• Enabled multiple engineers to work safely without deep Kubernetes expertise

Instead of spending months assembling a platform, they focused on validating outcomes.

Costs, Risks, and Value — Side by Side

Typical Tanzu Exit (DIY)

• Lower licensing cost
• Higher ongoing engineering effort
• Increased risk of drift
• Longer time to standardization

Codiac-Assisted Migration

• Predictable platform cost
• Reduced tool sprawl
• Faster upgrades and rollbacks
• Lower operational risk
• Faster developer onboarding

For many teams, the deciding factor isn’t cost alone—it’s confidence.

‍

‍

The Bigger Shift: From Platform Ownership to System Reliability

The teams leaving Tanzu are not anti-platform.
They are pro-delivery.

They want:

• Fewer tools
• Clearer operational models
• Repeatability without heroics
• A platform that enforces best practices instead of documenting them

Kubernetes is still the right runtime for many applications.
But how you operate it matters more than ever.

‍

Final Thought

Leaving Tanzu doesn’t have to mean starting over. In fact I would argue you have to leave all of it.
It doesn’t require rewriting everything, retraining everyone, or betting the business on a six-month platform rebuild.

For teams that want to move faster, reduce risk, and regain confidence in their systems, a more incremental, system-focused approach is often the safest path forward.

‍