Migrating off Istio: what to plan for

Istio is the most widely deployed service mesh, and it is also the one teams most often want to leave. The reasons vary: control plane complexity, resource overhead, upgrade friction, or simply the desire to understand what is actually running in their infrastructure. Whatever the reason, the migration is tractable if you plan the steps in the right order.

Inventory before you touch anything ¶

Before changing any configuration, build a complete inventory of what Istio is currently doing in your cluster. This means: every VirtualService and DestinationRule, every AuthorizationPolicy, every PeerAuthentication, and every ServiceEntry. Export them all to YAML and read them. Teams frequently discover policies that nobody remembers writing and services that nobody knew were in the mesh.

This inventory becomes your migration checklist. Every item in it needs an equivalent in the new mesh before you cut over.

Policy translation ¶

Istio's AuthorizationPolicy maps reasonably well to Tuft Mesh Vault's policy language. The main structural difference is that Istio policies are Kubernetes resources scoped to a namespace, while Tuft Mesh Vault policies are flat files scoped to a service or to the whole mesh. The translation is mostly mechanical, but watch for policies that use Istio-specific source principal formats. These need to be rewritten in terms of SPIFFE URIs.

The dry-run mode is the right tool for validating translated policies. Run the translated policy against a live traffic snapshot from your current mesh before cutting over any traffic.

Certificate migration ¶

Istio uses its own CA (Citadel, or an external CA if you configured one). Tuft Mesh Vault uses its embedded SPIFFE CA. The two trust domains are different, which means you cannot simply swap the control plane and expect existing mTLS connections to continue working.

The standard approach is to run both meshes in parallel during the migration, with each service registered in both. Traffic is cut over service by service, with the old mesh handling traffic until the new mesh is verified for each service. This requires that both meshes can coexist on the same hosts, which they can as long as they operate on non-overlapping service sets.

Traffic cutover ¶

Cut over one service at a time, starting with the least critical. Verify metrics and error rates after each cutover before proceeding. Keep the old mesh running until all services are migrated and you have run in the new mesh for at least one full rotation cycle (24 hours at the default interval). Then deregister from the old mesh and remove the Istio control plane.

If you are planning an Istio migration and want to talk through the specifics of your setup, the Enterprise plan includes an assisted migration session. Email hello@tuftmeshvault.com to start that conversation.