Docker Enterprise became Mirantis Kubernetes Engine (MKE) after Mirantis acquired the Docker EE business, and with it came a per-node control-plane subscription that scales with cluster size. Plenty of teams now run that workload on upstream, CNCF-conformant Kubernetes instead, removing the license and the UCP/Swarm layer. The good news: if your workloads already run as containers, the application contract barely changes. The work is in replacing the management plane and translating any Swarm-specific or compose-specific config into native Kubernetes objects.
Know which layer you are leaving
MKE bundles several things: the Kubernetes distribution, the legacy Swarm/UCP orchestration, DTR/MSR (the registry), and RBAC/UI on top. Your migration effort depends entirely on what you actually use:
- Already on MKE’s Kubernetes: mostly a cluster rebuild plus RBAC and ingress re-wiring. The manifests largely carry over.
- Still on Swarm/UCP: more work, you are converting an orchestration model, not just a distro.
Inventory this first, it determines whether this is a weekend or a quarter.
The conveniences Swarm handed you for free
Naming what the subscription bundled keeps the rebuild grounded. MKE packaged the Kubernetes distribution, the legacy Swarm/UCP orchestration, the DTR/MSR registry, and a unified RBAC and UI as one supported stack. Swarm in particular made some things effortless that Kubernetes makes explicit: the routing mesh published a port cluster-wide with no ingress object, overlay networks connected services without a CNI to choose, and compose files described a whole app in one place. Upstream Kubernetes trades that simplicity for flexibility. You choose the CNI, the ingress controller, the storage class, the registry, and the monitoring stack, and you own keeping them working across upgrades. The application contract barely moves because your services are already containers. The work, and the ongoing cost, is reproducing the management plane and the conveniences Swarm gave you for free.
Turning compose files into manifests
For Swarm or compose-based services, kompose converts docker-compose/stack files into Kubernetes manifests as a starting point, not a finished product. Expect to refine:
- Services become Deployments (or StatefulSets for stateful apps) plus Services.
- Published ports / routing become an Ingress controller (NGINX, Traefik) instead of Swarm’s routing mesh.
- Secrets and configs map to Kubernetes Secrets and ConfigMaps, re-create them, do not copy plaintext.
- Overlay networks map to Kubernetes networking + NetworkPolicies.
- Volumes map to PersistentVolumeClaims with a real storage class.
Stand up the cluster and cut over
- Pick a distribution: upstream via kubeadm, or a conformant build (k3s, Talos, RKE2) sized for your environment, with a real CNI, ingress controller, and storage class.
- Move the registry: repoint images from DTR/MSR to your new registry (Harbor is the common open-source choice); update image references in manifests.
- Rebuild RBAC: MKE’s RBAC and teams do not transfer, recreate roles and bindings in Kubernetes RBAC.
- Migrate namespace by namespace: deploy a workload to the new cluster, validate, shift traffic, then move the next. Keep MKE running until the last namespace is across.
Validation and cutover, namespace by namespace
Migrate one namespace at a time and validate it before touching the next. Deploy the converted workloads to the new cluster and confirm pods schedule with the resource limits and probes you added, that PVCs bind to a real storage class and mount the migrated data, and that Ingress resolves the hostnames Swarm used to publish. Verify images pull from the new registry, that the rebuilt RBAC grants each namespace exactly what it needs, and that NetworkPolicies enforce the isolation the overlay network used to imply. Shift traffic only after a namespace serves real requests cleanly, and keep MKE running until the last namespace is across so any wave can roll back.
The details that bite
- kompose is a draft. Treat its output as scaffolding, review every manifest for resource limits, probes, and security context that Swarm did not require.
- Stateful workloads need a plan. Databases and queues need StatefulSets, real storage classes, and a data-migration step, do not lift-and-shift their volumes blindly.
- Ingress and TLS. Swarm’s routing mesh has no direct equivalent, design ingress and certificate management (cert-manager) deliberately.
- Operational tooling is yours now. MKE’s UI, monitoring, and upgrades were managed, plan for upstream equivalents (Prometheus/Grafana, an upgrade cadence, backups via Velero) or you trade license cost for operational gaps.
Standing up the operational layer first
The mistake that turns a clean migration into an incident is moving workloads before the operations around them exist. MKE gave you a console, monitoring, an upgrade path, and a backup story as managed features, and none of that arrives with an empty upstream cluster. Before the first production namespace moves, stand up monitoring with Prometheus and Grafana, log shipping to a store you can query, an ingress controller with certificate management through cert-manager, a real storage class for stateful workloads, and Velero for scheduled backups. Decide an upgrade cadence for the distribution and its add-ons, and write down who owns it. Building this ahead of the workloads means each namespace lands on a platform that can already observe, back up, and recover it, rather than one you are assembling under pressure after something breaks.
The short version
MKE to upstream Kubernetes removes the per-node subscription in exchange for owning the cluster yourself. Scope the effort by how much Swarm/UCP you still use, convert compose/stack files with kompose as a draft and refine every manifest, move the registry and rebuild RBAC, then migrate namespace by namespace while MKE keeps running. Stand up the operational layer (ingress, storage, monitoring, backups) before you cut over, and model the removed subscription against the engineering time to run Kubernetes in the calculator above.