If Docker Swarm is still running your production workloads, you're actually a testament to something genuinely rare in software: a tool that did exactly what it promised, reliably, for years. That deserves some respect before we talk about anything else.
Docker Swarm peaked around 2019. When Docker Enterprise was sold to Mirantis in late that year, the trajectory was set. Swarm didn't die, but it stopped growing. What you're running today is, in most meaningful ways, the same product it was in 2022. Incremental patches, yes. A living ecosystem with active tooling investment? No. The broader industry made its call, and it called Kubernetes.
That matters more than it might seem. Tooling isn't a nice-to-have; it's the core capability that makes a container platform viable. Monitoring integrations, CI/CD plugins, security scanners, registry tooling, secrets management, observability pipelines, fleet management, user authentication and authorization. These days, almost all of it is written for Kubernetes. With the Docker 29 release breaking compatibility with a significant slice of legacy tooling, many of which haven't seen a commit in years, that tooling deficiency just got more critical.
Then there are the harder conversations. Persistent volumes backed by aging volume drivers that were never designed for the failure modes (or performance) of modern infrastructure. Overlay networking built on VXLAN, which plays reasonably well in a clean on-premises environment, but creates real headaches on cloud IaaS VMs and requires manual workarounds even on VMware estates. These aren't theoretical risks. They are the kinds of issues that surface years after the initial build, when you try to add another host. Problem is, Swarm now has limited documentation, in a community that has largely moved on to solving different problems.
None of this is your fault. Swarm worked. It still works, mostly. The loyalty to it is rational. But there's a difference between a tool that works and a platform with a future, and those two things have been quietly diverging for a while now.
The obvious answer is Kubernetes. The honest answer is that Kubernetes has a real operational cost, and anyone who tells you otherwise is selling you something. It is a more complex system. It requires more knowledge to run well. That gap is real, and it's reasonable to have used it as a reason to stay put.
Here's where that reasoning starts to break down: the gap is closable, and the risk of not crossing it is now larger than the risk of crossing it.
Portainer has been working with Swarm environments for 8 years (we even started with swarmmode before switching to swarm-kit). Those 8 years of experience have seen us support over 30,000 swarm users, so we know where it shines, and where it struggles, and we know the technologies that really tie you to Swarm (MACVLAN for a start). We also know that what most Swarm users actually need from Kubernetes is a fraction of what Kubernetes can do, and that fraction is entirely manageable. That's the exact problem the Portainer Kubernetes management solution was built to solve. You don't have to boil the ocean. You need a plan, a migration path you can actually execute, and a platform that doesn't abandon you mid-crossing.
That's what we're here for. If you're ready to start the conversation, we are too.



