This article is based on a piece originally published by Armory.io. It has been expanded and rewritten for a DevOps engineering audience.
Why Kubernetes Migrations Stall
Software is increasingly the core differentiator for organizations across every industry. Banks describe themselves as software companies that happen to specialize in finance. Retailers frame themselves the same way. The pressure to modernize has driven many enterprises toward containerization and Kubernetes as the presumed solution to engineering scalability problems.
Kubernetes has earned real credibility: it solves hard problems around scheduling, resiliency, and platform consistency. But its reputation as the obvious answer to operational complexity has led many organizations to underestimate the difficulty of actually migrating to it. The result is Kubernetes projects that stretch from months into years, and platforms that are less stable than what they replaced.
Understanding why this happens is the first step to avoiding it.
A Realistic Migration Story
Consider a fictional but representative scenario. A Director of Engineering at a large technology company assigns two capable engineers — call them Allyson and Jorge — to evaluate container orchestration platforms. They do the work properly: they evaluate Docker Swarm, Amazon ECS, and multiple Kubernetes distributions before selecting Kubernetes for well-reasoned technical reasons:
- Deployments as a first-class platform primitive, giving them declarative rollout and rollback control.
- Built-in resiliency through node and container health checking and automatic restarts.
- Sidecar consolidation, allowing log aggregators, metrics agents, and security daemons to run as shared out-of-process containers rather than being independently managed per VM.
With a clear technical direction, they begin migrating a single application — the logical first step. But “one application” rapidly expands in scope once they account for every dependency that application carries:
- Translating VM-based build pipelines into container image build processes.
- Ensuring compliance and security agents work correctly inside containers.
- Adapting deployment pipelines to take advantage of Kubernetes primitives like rolling updates and health probes.
- Documenting organization-specific conventions so other teams can follow the same path.
What looked like a contained task becomes a collection of bespoke solutions. Eight months later, the first application is running on Kubernetes. Allyson and Jorge look around for other teams to migrate — and find almost no takers.
Why Other Teams Won’t Follow
This is a critical moment that many migration efforts misread. The refusal is not irrational. Most engineering teams are measured on feature delivery and system stability. They are not opposed to new technology, but they are conservative about adopting it when the value is unclear and the risk is high.
When Allyson and Jorge ask them to migrate, they are effectively asking each team to:
- Absorb months of reduced delivery velocity.
- Retrain on new tooling and operational practices.
- Accept a less-understood runtime with potential gaps in observability and compliance coverage.
- Trust that implicit migration assumptions — which took Allyson and Jorge months to discover — will not derail their own timelines.
Product owners will rarely approve more than a sprint or two for platform migration work. Eight months is a non-starter. The migration stalls not because Kubernetes is wrong, but because the migration approach failed to account for organizational risk.
The Real Risks in a Kubernetes Migration
Most migration plans start with “How do we deploy to Kubernetes?” Focusing on delivery first is understandable, but it consistently causes teams to treat the following as secondary concerns — often until something breaks:
Security
Container security models differ significantly from VM security models. Network policies, pod security contexts, RBAC configuration, image scanning, and secrets management all require deliberate design. Migrating workloads without addressing these areas produces a platform that is harder to audit and potentially less secure than what it replaced.
Observability
Kubernetes introduces ephemeral workloads, which invalidates many host-centric monitoring assumptions. Log pipelines, metrics collection, alerting rules, and distributed tracing all need to be re-evaluated for a dynamic, container-based environment. Teams that skip this step lose visibility into their own systems.
Compliance and Auditing
Compliance agents, audit logging, and data residency requirements that worked on VMs may not translate cleanly to containers. Validating these requirements before migrating production workloads avoids costly rework — or worse, a compliance incident.
Infrastructure Complexity
Kubernetes itself is operationally complex. Networking (CNI plugins, service meshes), storage (persistent volume provisioning), and cluster lifecycle management (upgrades, node scaling) all introduce new failure modes that need documented runbooks and trained on-call engineers before workloads move to production.
The “Do Everything the Kubernetes Way” Trap
A related failure mode is scope creep driven by enthusiasm for the ecosystem. A migration to Kubernetes quickly becomes a simultaneous migration to containerd, a service mesh like Istio, a GitOps controller like Argo CD or Flux, a new secrets backend, a new logging stack, and a new metrics platform — all at once.
Each of these tools has genuine merit. But adopting all of them simultaneously compounds risk, slows onboarding, and makes it nearly impossible to isolate the cause of any given failure.
As Kelsey Hightower has noted about Kubernetes adoption: “There are no best practices; everyone is just practicing.” The ecosystem evolves quickly, organizational contexts vary enormously, and what works well for one team may be wrong for another. This is not an argument against using these tools; it is an argument for introducing them one at a time, when you have a clear reason and the organizational bandwidth to absorb them.
Structuring a Lower-Risk Migration
The uncomfortable answer to most Kubernetes migration problems is not a clever tool or architectural pattern. It is disciplined incremental delivery — the same principle that led engineering organizations to adopt Agile development in the first place.
Rather than designing the full migration up front and then executing it as a single large project, define milestones that:
- Deliver measurable value independently. Each milestone should produce something a team can use or learn from, not just contribute to a future payoff.
- Are small enough to fit within normal sprint planning. If other teams cannot absorb migration work without special budget approval, the milestones are too large.
- Reduce risk before expanding scope. Prove out security, observability, and compliance requirements on low-criticality workloads before migrating anything that requires an on-call rotation.
- Produce reusable artifacts. Every migration should generate documented patterns, Helm charts, pipeline templates, or runbooks that reduce the cost of the next migration.
This approach requires patience, but it is the difference between a migration that finishes in a reasonable timeframe with organizational buy-in and one that drags on indefinitely with declining support.
Key Takeaways
- Kubernetes migrations routinely underestimate organizational risk — not just technical risk.
- Focusing exclusively on deployment mechanics causes teams to defer security, observability, and compliance until they become crises.
- Ecosystem enthusiasm (service meshes, GitOps, new runtimes) compounds complexity when introduced all at once.
- Incremental milestones with independently deliverable value reduce the activation energy required to get other teams to migrate.
- Reusable artifacts from each migration — templates, runbooks, documented conventions — lower the cost of every subsequent migration.
A Kubernetes migration is not primarily a technical project. It is an organizational change project that happens to involve significant technical work. Planning for both dimensions is what separates migrations that succeed from those that stall.
The original post was attributed to Armory.io, the company behind a Spinnaker-based continuous delivery platform for Kubernetes.