{"slug": "migrate-first-modernize-later-a-leadership-guide-to-converging-vms-and-to-run-ai", "title": "Migrate First, Modernize Later: A Leadership Guide to Converging VMs and Containers to Run AI Workloads", "summary": "Tigera's Calico Enterprise platform now supports VMs and containers on Kubernetes with a unified networking and security model, enabling enterprises to migrate VMs to Kubernetes without renumbering IPs or rewriting firewall rules. The eBPF-powered platform, built on Calico Open Source, Istio, Envoy, and eBPF, works across all major Kubernetes distributions and infrastructure types, allowing organizations to consolidate fragmented infrastructure and reallocate resources to AI workloads.", "body_md": "## The Tipping Point\n\nEvery so often the ground under enterprise IT moves. It’s moving now. Across industries, organizations are consolidating fragmented infrastructure onto a single, self-hosted platform capable of running both containers and virtual machines side by side. The motivation is simple: simplify operations, lower cost and reallocate resources & budget to AI initiatives. Kubernetes is emerging as the primary platform for many of these workloads.\n\nFor most IT leaders, the compute and storage portions of a VM migration are manageable. Storage arrays and hypervisor CPU/memory allocation translate fairly directly to Kubernetes equivalents. Networking is where migration plans stall. A VM’s network identity — its IP, its VLAN membership, its firewall rules — is wired into surrounding infrastructure, monitoring, compliance controls, and business processes that nobody wants to touch during a migration window.\n\nTeams accustomed to NSX for this work find that native Kubernetes networking wasn’t built with VM administrators in mind, and the functionality gap becomes the reason migration projects get bigger or are stalled. If the networking problem is solved — if a VM can move to Kubernetes and keep its IP, its policy, and its security posture intact — then the rest of the platform consolidation stops being an expensive, multi-year architectural bet.\n\n**The Power of Convergence**\n\neBPF-powered Calico unified platform’s value has always been convergence and portability — collapsing separate networking domains into a platform and enabling customers to avoid vendor lock-in by platform vendors.\n\n## One Networking and Security Model for Any Kubernetes Distribution, Any Workload, Anywhere\n\nCalico Enterprise was developed to deliver three objectives for enterprise networking & security in Kubernetes in a single unified platform to enable enterprises to be ready for hosting AI workloads. Now with the launch of Calico for VMs on Kubernetes, Calico delivers a fourth objective: support for VMs & Containers on Kubernetes.\n\n**All the components required for k8s networking and network security in a single unified platform –** Built on the most trusted open-source technologies in Kubernetes — Calico Open Source, Istio, Envoy, and eBPF — the Calico platform gives platform engineering teams a single management plane to enforce, observe, and troubleshoot all workload communication**Unified platform works across any Kubernetes distribution –** Calico is Kubernetes agnostic, and supports all major distributions equally: AKS, EKS, GKE, VMware VKS, RedHat OpenShift, Canonical, SUSE, Mirantis and others. That matters strategically for a VM migration decision: it means the move of workloads from a legacy hypervisor to Kubernetes doesn’t lock the organization into a single Kubernetes vendor.**Unified platform works across infrastructure –** Calico extended one unified model across on-premises, cloud environments and edge, so connectivity, security, and observability behave identically no matter where a cluster runs.**Unified platform works across different types of workloads – Containers & VMs –** Calico enables virtual machines and containers to share one networking fabric, one policy model, and one observability plane. Seamless VM migration while maintaining L2 networking, and a single control plane for ease of management, regardless of the workload, VMs or containers.\n\n## Benefits of Adopting a Modern Networking Architecture\n\n### Migrate First, Modernize Later\n\nThe single most important idea for a migration plan to succeed is separating “get off legacy” from “redesign the network and workloads”. Trying to do both at once is what turns a migration into a multi-year modernization program. Calico’s L2 bridge capability extends existing VLANs into Kubernetes, so a VM can move to a Kubernetes cluster on day one without renumbering, without rewriting firewall rules, and without breaking the hard-coded dependencies — DNS records, monitoring agents, compliance scans — that assume a specific IP or subnet. Once workloads are safely on Kubernetes, the network architecture can evolve on its own timeline — moving from an L2, VLAN-based design to a Kubernetes-native L3 design when the team is ready, not because the migration forced the issue.\n\n### A complete stack for VM networking on Kubernetes\n\nEvery capability and outcome delivered by NSX has a direct Kubernetes-native counterpart in Calico:\n\n**Connect –** Calico Networks provide connectivity to VM workloads and to the networks and services around them. L2 Bridge capabilities can extend existing network VLANs (Segments) into Kubernetes for workloads that require Layer 2 or network continuity during and after migration. BGP-based routing, egress gateway, load balancing and ingress gateway functions support delivering applications and services to consumers.**Secure –** Calico network policy, policy tiers, staged policy and DNS policy provide Kubernetes-native controls for access enforcement and microsegmentation. Policies can be planned, monitored and validated before enforcement, helping teams maintain security posture as workloads move and apply consistent controls across VMs and containers.**Observe –** Calico Service Graph, flow logs, DNS logs, L7 visibility and packet capture provide context for troubleshooting and security operations. Teams can investigate VM-to-VM, VM-to-pod, pod-to-pod and cross-cluster flows with Kubernetes-aware workload context using eBPF-enabled deep packet inspection.\n\n### The ROI Case\n\nThe core mechanism is consolidation onto a single management plane covering network connectivity, observability, and network policy. Instead of maintaining separate stacks and separate expertise for VMs and for containers, the teams responsible for availability, performance, and security each focus on one plane, with one consistent set of tools, telemetry, and controls. Additionally, the new architecture prevents vendor lock-in by Kubernetes platform vendors.\n\n### Cost relief\n\nThe immediate driver for most organizations is reducing the costs of legacy hypervisors. Every VM that moves off legacy infrastructure onto a converged Kubernetes platform is a licensing spend that stops compounding — budget that can be redirected to AI infrastructure.\n\n### Operational efficiency\n\nRunning one policy model, one routing and observability stack, and one set of operational runbooks for both VMs and containers means fewer specialized teams, less tooling overlap, and lower mean time to resolution (MTR) when something goes wrong.\n\n### AI readiness\n\nA converged platform is also the platform production AI workloads need. Self-hosted LLMs and the agents built on them can run alongside existing VM and container workloads, close to the data they need, with the performance, latency, and scale that production AI demands.\n\n## Conclusion\n\nThe market is converging on one self-hosted platform for containers and VMs, and the economics and AI trends driving it are only accelerating. The AI-driven need for a converged, self-hosted platform is the reason to move to Kubernetes specifically, rather than to another hypervisor. Tigera already secures workloads across more than a million clusters for organizations including NVIDIA, Royal Bank of Canada, Bloomberg, Chipotle, GoDaddy, and Upwork.\n\nMigrate first. Modernize later. On your timeline.\n\n**→ Learn more:** Visit the [VM Migration page](https://www.tigera.io/tigera-products/vm-migration/)\n\n**→ See it in action:** View the [self-paced overview](https://app.arcade.software/share/Pa1kvHOZzkXI43jXoHs2)\n\nReady to see Calico for VMs on Kubernetes in action? [Walk through the live demo](https://app.arcade.software/share/Pa1kvHOZzkXI43jXoHs2).", "url": "https://wpnews.pro/news/migrate-first-modernize-later-a-leadership-guide-to-converging-vms-and-to-run-ai", "canonical_source": "https://www.tigera.io/blog/migrate-first-modernize-later-a-leadership-guide-to-converging-vms-and-containers-to-run-ai-workloads/", "published_at": "2026-07-24 21:32:47+00:00", "updated_at": "2026-07-24 21:38:08.525669+00:00", "lang": "en", "topics": ["ai-infrastructure", "artificial-intelligence"], "entities": ["Tigera", "Calico Enterprise", "Kubernetes", "eBPF", "Calico Open Source", "Istio", "Envoy", "VMware VKS"], "alternates": {"html": "https://wpnews.pro/news/migrate-first-modernize-later-a-leadership-guide-to-converging-vms-and-to-run-ai", "markdown": "https://wpnews.pro/news/migrate-first-modernize-later-a-leadership-guide-to-converging-vms-and-to-run-ai.md", "text": "https://wpnews.pro/news/migrate-first-modernize-later-a-leadership-guide-to-converging-vms-and-to-run-ai.txt", "jsonld": "https://wpnews.pro/news/migrate-first-modernize-later-a-leadership-guide-to-converging-vms-and-to-run-ai.jsonld"}}