Platform
From Docker Swarm to Kubernetes without downtime: what made it work
Infomentor connects teachers, students, and parents across Europe, so downtime is not an option during the school year. Their platform had outgrown Docker Swarm: not every application was containerized, deployments needed manual steps, and routing lived in a tangle of Nginx configuration on a single shared server. Together with their IT team, we moved everything to an on-premises Kubernetes platform. These are the decisions that made it work.
Containerize everything first
Before touching the cluster, we made sure every application ran in a container with a consistent build. It is unglamorous work, but it turns the migration from “move this unusual server” into “deploy this image somewhere else,” and it removes a whole class of surprises later.
One deployment framework, not one chart per app
Instead of writing a Helm chart for every application, we built a shared chart framework with reusable templates. Each team only edits a short values file for its environment variables, resources, and routing. Best practices come built in, every service is deployed the same way, and teams can still adjust what is genuinely specific to them.
Git as the source of truth
With ArgoCD, the desired state of every application lives in Git, and the cluster continuously syncs to it. A deployment is a reviewed change, a rollback is a revert, and anyone can see exactly what is running and why. For a team used to manual steps, that transparency mattered as much as the automation.
Untangle routing as part of the move
The shared Nginx setup was one of the riskiest parts of the old platform, because every change touched everyone. In Kubernetes, each application got its own ingress, with routing and TLS handled centrally by the ingress controller. Changes became local, and certificates stopped being anyone's manual job.
Templates for the pipelines too
Reusable Azure DevOps pipeline templates build, test, and package every service the same way and hand off to ArgoCD for delivery. A new team can adopt the whole flow in an afternoon instead of designing its own.
Migrate service by service
Nothing moved in one big switch. Services were migrated in phases, each one verified in the new environment before traffic followed it, with the old setup still available behind it. That is what kept the platform online for schools throughout, with no disruption for the people using it.
Bottom line
The technology choices, Kubernetes, Helm, ArgoCD, matter less than the order of the work: standardize first, make deployments boring and visible, then move in small, reversible steps. If you're facing a similar migration, we're happy to help you plan it.