Moving from Docker Swarm to Kubernetes is a change of object model rather than a change of tool, which is why its costs arrive in a predictable order. This plan follows that order: the objects replacing a stack file, the staffing question behind managed clusters, stateful workloads, the traffic cutover, and the roles that keep a cluster alive.
Quick Overview
What you’ll learn:
- Which Swarm concepts map straight across and which need parameters Swarm never asked for
- Why choosing a managed cluster is a staffing decision, not a technical one
- Which part of the migration consumes the effort, and why it is not configuration
- What has to be named on the team side for the cluster to survive its first quarter
Who this article is for:
- Managers of teams running containerised services in production
- Technical leads planning to leave Swarm before its usefulness runs out
- People accountable for platform headcount and budget
Reading time: 7 minutes
The Object Model Is the Migration
Swarm describes a deployment in a single layer: a service has an image, a replica count and an overlay network, and the stack file holds them together. Kubernetes decomposes the same thing into separate objects, and that decomposition is what you are migrating: a Pod is the smallest deployable unit, a Deployment manages identical pods and their replacement, a Service gives them a stable address, and an Ingress admits outside traffic. The Services documentation on cloud.google.com states the third of those plainly: a Service groups pod endpoints behind one stable IP address, so a calling application need not know where the other one runs.
For a manager the consequence is a cost, not an aesthetic. A single Swarm service becomes a handful of resources, each with its own file, its own API group version (apps/v1 for a Deployment) and its own reviewer. A team that kept one stack file per service now keeps a manifest directory — the moment to introduce templating, not to postpone it.
The chart documentation on helm.sh describes a chart as a package of Kubernetes resources expressed as templates and values. One decision settles the shape of the next year: either all services share a chart parameterised per service, or each service carries its own manifests. The first costs more in week one; the second costs more on every service after the first.
The concepts whose mapping is not mechanical deserve naming up front, because they are where migrations stall. Each does have a counterpart: a global-mode service becomes a DaemonSet, placement constraints become nodeSelector and the more expressive nodeAffinity, the rolling update becomes strategy.type: RollingUpdate with maxUnavailable and maxSurge, and a secret becomes a Secret mounted as a file or an environment variable. The work is settling parameters Swarm never asked for, not finding replacements.
Managed Cluster or Your Own
This is a management decision because it settles headcount rather than technology. The GKE overview on cloud.google.com draws the line: the provider operates the cluster control plane while the team remains responsible for its workloads and their configuration. Run the cluster yourself and that layer — API server, cluster state store, controllers — returns to the team along with its upgrades.
The question on this step is blunt: who upgrades the control plane, and what happens while that person is on leave. If the answer has no name attached, a managed cluster is cheaper than a self-hosted one whatever the machine pricing says.
The reliability guidance on learn.microsoft.com is worth reading here rather than later, because it sets expectations a manager has to accept: workloads need resource requests and limits, pod disruption budgets and readiness probes before the cluster can move them safely. Those are application changes, so they land in the product backlog, not the platform’s.
Stateful Workloads Are a Separate Project
Stateless services move quickly. The effort sits in everything that writes to disk: the database, the queue. Kubernetes serves those with different objects than a plain Deployment — a stateful set giving pods durable identity, and a persistent volume claim for the storage itself. Data migration carries its own rollback plan and must not be bolted onto the service-migration step.
Networking is the second place where both systems genuinely diverge. A Swarm overlay network gave services flat visibility; in Kubernetes internal traffic is described by Service objects and external entry has historically been an Ingress plus whichever controller implements it.
This decision is worth taking now rather than later. The documentation on cloud.google.com presents Gateway API as the recommended way to expose HTTP applications and carries a separate guide for migrating off Ingress; the model splits roles across a GatewayClass from the provider, a Gateway from the cluster operator and an HTTPRoute from the application team. Choose the ingress path with that split in view, or buy a second migration in the entry layer later.
The sequence here is not negotiable: one stateless service migrated end to end with production traffic, then the remaining stateless ones, then the stateful ones. A migration that opens with the database says nothing about whether the method scales and pins the team to the hardest component.
The Roles That Have to Exist
A cluster with no named platform owner degrades quietly: versions drift, manifests start living on laptops, and access reviews have no addressee. The platform owner answers for the cluster version and the manifest standard. The on-call engineer needs a written diagnostic path, because kubectl describe pod surfaces different things than docker service ps and in the first weeks that difference costs hours. The team lead settles the migration order, because business dependencies live with the lead and not in the cluster.
Retiring Swarm is the last step and has its own exit criterion: the old environment goes dark once no service has failed back to it for an agreed period. Keeping both environments “for now” is the most expensive state of the migration, so that criterion belongs in the plan.
The CNCF project page on www.cncf.io records Kubernetes as a graduated project with an ecosystem maintained under the same foundation — an argument about interface stability and tool availability rather than about vendors. It does not follow that no further migrations await in the layers above: the ecosystem moves faster than the core.
Read Also
- Kubernetes in practice: architecture and application management — the model you are migrating onto
- Production Kubernetes cluster rollout: a complete guide — standing the target environment up
- Managing deployments with Helm charts — what replaces compose files after the migration
Build Your Skills
This topic is covered by Docker and Kubernetes and Kubernetes — from basics to advanced techniques. The first settles the relationship between image, container and orchestration; the second works through cluster objects and their configuration. Talk to us about matching the scope to the state of your environment.
Frequently Asked Questions (FAQ)
Does a working Swarm estate have to be abandoned?
Not because it fails, but because of the ecosystem around it. Swarm still runs containers, while the deployment, observability and policy tooling being written today targets Kubernetes. The case for migrating is therefore the availability of tools and of people who know them — not a defect in Swarm, and it is worth presenting that way to a board.
How many services belong in the first attempt?
One stateless service, taken end to end with production traffic. A pilot without production traffic tests none of the expensive parts: not certificates, not headers, not on-call. The second service is the real measurement — if it costs as much as the first, the team skipped templating and should return to that step.
Do we need a separate platform team to migrate?
Not from day one, but a named platform owner with protected time is required. A migration run purely in a product team’s spare hours stalls on the stateful workloads, because those need uninterrupted attention. The role can rotate, as long as its scope is written down.
What should we do with the stack files describing today’s environment?
Treat them as an input specification rather than as a source for automatic conversion. Converters produce a starting point, but the parts that need a deliberate decision come across partially or simplified: secrets, placement constraints and update strategy parameters. Conversion saves typing, not thinking.