{"id":466,"date":"2026-09-03T21:10:03","date_gmt":"2026-09-03T19:10:03","guid":{"rendered":"https:\/\/nutanix.ma\/?p=466"},"modified":"2026-09-03T21:10:03","modified_gmt":"2026-09-03T19:10:03","slug":"migration-in-motion-nutanix-on-moving-containers-and-kubernetes-workloads","status":"publish","type":"post","link":"https:\/\/nutanix.ma\/index.php\/2026\/09\/03\/migration-in-motion-nutanix-on-moving-containers-and-kubernetes-workloads\/","title":{"rendered":"Migration in Motion: Nutanix on Moving Containers and Kubernetes Workloads"},"content":{"rendered":"<p>Kubernetes won the container orchestration argument some time ago. That&#8217;s settled. What isn&#8217;t settled \u2014 and what comes up constantly on migration projects \u2014 is what you do when the Kubernetes platform you&#8217;re already running is no longer the one you want to be on. Nutanix ran a session on exactly this as part of its <em>Migration in Motion<\/em> webinar series, and it&#8217;s worth a look if container migration is anywhere on your roadmap.<\/p>\n<h2>The session<\/h2>\n<p><strong>Migration in Motion: How to Move Containers<\/strong> is a 45-minute virtual session delivered by Nutanix professional services experts, subtitled &#8220;Practical insights on moving to Kubernetes and migrating Kubernetes across platforms.&#8221; The live run took place on Tuesday, 19 May 2026 (10:00 BST | 11:00 CEST | 13:00 GST), presented by David Rios Delgado, Senior Staff Enterprise Architect at Nutanix.<\/p>\n<p>The registration page is still live, and this session is part of Nutanix&#8217;s on-demand <em>Migration in Motion<\/em> collection \u2014 so if the date has passed by the time you read this, the material is still reachable:<\/p>\n<ul>\n<li><a href=\"https:\/\/event.nutanix.com\/migratingcontainersq426\/innovation-conference\" target=\"_blank\" rel=\"noopener\">Migration in Motion: How to Move Containers \u2014 event page<\/a><\/li>\n<li><a href=\"https:\/\/www.nutanix.com\/migration-in-motion\" target=\"_blank\" rel=\"noopener\">The full Migration in Motion on-demand series<\/a><\/li>\n<\/ul>\n<h2>What it covers<\/h2>\n<p>Three areas, per Nutanix&#8217;s own framing:<\/p>\n<ul>\n<li><strong>Migrating from other orchestration tools to Kubernetes.<\/strong> The legacy-platform problem \u2014 Docker Swarm, Mesos, OpenShift on an older footing, or a bespoke scheduler someone built in 2018 and then left the company.<\/li>\n<li><strong>Moving Kubernetes platforms across providers<\/strong>, both cloud and on-premises. This is the one that has grown teeth: repatriation from public cloud, moving between managed Kubernetes services, or standing up an on-prem platform alongside an existing cloud one.<\/li>\n<li><strong>Best practices, key considerations, and lessons learned.<\/strong> The part that&#8217;s hard to get from documentation.<\/li>\n<\/ul>\n<h2>Why container migration is harder than it looks<\/h2>\n<p>The pitch that containers make workloads portable is true in a narrow sense and misleading in a broad one. The container image really does move cleanly. Almost nothing else does.<\/p>\n<p>What actually holds a Kubernetes platform in place is everything around the workload: persistent volumes and the CSI driver behind them, load balancer and ingress implementations that differ per provider, cluster-scoped custom resources, admission and policy controllers, service mesh configuration, secrets management, image registries and their credentials, RBAC bindings mapped to an identity provider, and the CI\/CD pipelines that assume all of the above. A <code>Deployment<\/code> manifest is portable. A cluster is not.<\/p>\n<p>Two things consistently cause the most pain in practice. The first is <strong>stateful workloads<\/strong> \u2014 anything with a PersistentVolumeClaim needs a real data migration story, and &#8220;we&#8217;ll just re-deploy it&#8221; stops being an answer the moment the data matters. The second is <strong>networking<\/strong>: ingress controllers, external DNS, and the assumption that a cloud provider will hand you a load balancer on request. On-premises, that becomes an explicit design decision rather than an API call.<\/p>\n<h2>The Nutanix angle<\/h2>\n<p>Nutanix&#8217;s position here is that the Nutanix Cloud Platform gives you one place to run these workloads across on-prem and cloud, so a migration becomes a move onto a consistent platform rather than a move from one provider&#8217;s assumptions to another&#8217;s. For anyone already running Nutanix for virtual machines, the relevant point is that container platforms and CSI-backed persistent storage sit on the same infrastructure the VMs do \u2014 which removes a fair amount of the storage and networking guesswork that makes these projects slip.<\/p>\n<p>Whether that&#8217;s the right answer depends on where your workloads already live and how much of your platform tooling is tied to a specific provider. But the three questions the session organises itself around are the right ones to be asking before a container migration, regardless of which platform you land on.<\/p>\n<h2>Worth watching if\u2026<\/h2>\n<p>You&#8217;re running Kubernetes on a platform you inherited rather than chose; you&#8217;re being asked what repatriating container workloads from public cloud would actually involve; or you&#8217;re running Nutanix for VMs and want to understand where containers fit alongside them. Forty-five minutes is a reasonable price for the lessons-learned section alone.<\/p>\n<p><em>Session and series details above are from Nutanix&#8217;s own event pages, linked in full at the top of this post. Registration and availability are handled by Nutanix directly.<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Kubernetes won the container orchestration argument some time ago. That&#8217;s settled. What isn&#8217;t settled \u2014 and what comes up constantly on migration projects \u2014 is what you do when the Kubernetes platform you&#8217;re already running is no longer the one you want to be on. Nutanix ran a session on exactly this as part of [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[],"class_list":["post-466","post","type-post","status-publish","format-standard","hentry","category-infrastructure"],"_links":{"self":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts\/466","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/comments?post=466"}],"version-history":[{"count":1,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts\/466\/revisions"}],"predecessor-version":[{"id":467,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/posts\/466\/revisions\/467"}],"wp:attachment":[{"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/media?parent=466"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/categories?post=466"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/nutanix.ma\/index.php\/wp-json\/wp\/v2\/tags?post=466"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}