Managed Kubernetes platforms carry per-core or per-node subscriptions on top of the infrastructure. Upstream Kubernetes, Rancher/RKE2, and K3s remove or reduce that licensing, in exchange for owning more of the platform yourself. Because workloads are already containerized, the move is mostly about the platform layer, not the apps.
What the subscription was actually buying
Every one of these platforms bundles more than an orchestrator. OpenShift adds an integrated registry, source-to-image builds, Routes, and SecurityContextConstraints. Tanzu ties cluster lifecycle, fleet policy, and builds to vSphere. Mirantis Kubernetes Engine (formerly Docker EE) wraps a Kubernetes distribution around legacy Swarm/UCP, a registry, and a unified RBAC layer. Cloud Foundry hides the whole path from source to running process behind cf push. The license removes a line item, but each bundled convenience becomes a component you now choose, install, and keep compatible across upgrades. Scoping that platform-team effort honestly is the real decision, not the sticker price.
How much of the platform do you want to own
- Upstream Kubernetes (kubeadm / Cluster API), maximum control, no vendor layer.
- Rancher / RKE2 (SUSE), managed multi-cluster with an easier operational on-ramp.
- K3s, lightweight, great for edge and smaller footprints.
Provision the target
Build clusters with matching storage classes, ingress controllers, and CNI/network policies, then set up registries, GitOps (Argo CD/Flux), and observability. Inventory namespaces, workloads, CRDs, RBAC, and operators on the source first.
Migrate with Velero, Helm, and kompose
Velero backs up namespaces plus persistent volumes to object storage and restores them onto the target cluster, and it is the common backbone for OpenShift and Tanzu workload moves. Helm packages the applications and platform add-ons you reinstall on the target. For Docker EE/Swarm estates, kompose converts compose and stack files into Kubernetes manifests as a starting point, not a finished product: expect to add resource limits, probes, and a securityContext by hand. The source-specific conversion work varies by platform: OpenShift means Routes → Ingress, BuildConfigs/ImageStreams → external CI + a registry, and SCCs → PodSecurity admission; Cloud Foundry means rebuilding buildpack apps with Paketo or Dockerfiles and mapping brokers to operators. Sync registries and re-point ingress DNS per namespace.
Moving one namespace at a time
Cut over namespace-by-namespace: restore, fix ingress/RBAC/storage, smoke-test workloads and autoscaling, then move ingress traffic. Validate RBAC, network policies, persistent storage, and a rolling-update + node-drain/HA test. Keep the source namespace running and re-point ingress back if a wave fails.
Rebuild the platform layer before you migrate
Test a Velero backup/restore of a non-critical namespace first, and reconcile via GitOps so the target is declarative and repeatable. Sequence coupled migrations rather than stacking them: if you are leaving both Tanzu and vSphere, or both Docker EE and Swarm, do one, validate, then the other, so a failure has a single obvious cause. Rebuild the operational layer, ingress, storage, registry, monitoring, and backups, before the first production namespace moves, otherwise you trade a license cost for operational gaps that surface at the worst moment.
Weighing the trade
The subscription savings are straightforward to model. The offsetting cost, a platform team owning the components the vendor used to integrate, is the number that decides whether the move pencils out. Softer bridges exist where a full rebuild is too much velocity to spend at once: Korifi keeps the cf push workflow on Kubernetes, and Rancher/RKE2 gives multi-cluster management with an easier operational on-ramp than pure kubeadm. Weigh those against a clean upstream target rather than assuming an all-or-nothing choice.
Open a source→target page for the Velero/Helm commands and a per-core TCO model.