# Migrate a Kubernetes platform to Quake AI Source: https://docs.quake.ai/docs/platform/migration/migrate-kubernetes-platforms-to-quake-ai Markdown: https://docs.quake.ai/docs/platform/migration/migrate-kubernetes-platforms-to-quake-ai.md > Move an existing Kubernetes platform from EKS, GKE, AKS, or DOKS to Quake AI Magnum by standing up the k8s-cluster template, syncing workloads and images through primitive migration guides, and cutting over ingress with rollback. --- # Migrate a Kubernetes platform to Quake AI In this migration guide, you move an existing Kubernetes platform to Quake AI. You stand up the [Kubernetes cluster template](/build/iac-templates/k8s-cluster) on Magnum, sync container images and persistent data from the source cluster, and cut over ingress and DNS with a workload drain plan and rollback. Quake AI runs a **managed control plane through Magnum**; worker nodes are Nova instances you size and patch. You operate cluster add-ons, ingress, and Helm releases on top of Magnum. **What you will migrate:** a platform on Amazon EKS, Google GKE, Azure AKS, DigitalOcean Kubernetes (DOKS), or a self-managed cluster elsewhere. **What you will learn:** - How to provision the `k8s-cluster` template as the migration target - How to pick the correct primitive migration page ([EKS](/docs/kubernetes/migration/migrate-from-eks), [GKE](/docs/kubernetes/migration/migrate-from-gke), [AKS](/docs/kubernetes/migration/migrate-from-aks), or [DOKS](/docs/kubernetes/migration/migrate-from-doks)) - How to mirror images and sync backup objects with [Migrate from S3](/docs/object/migration/migrate-from-s3) - How to cut over ingress, drain source nodes, and roll back if workloads fail on Magnum **Time estimate:** 75 minutes (excluding image mirror and PV copy time)
```d2 direction: right source: Source cluster\n(EKS / GKE / AKS / DOKS) magnum: k8s-cluster\nMagnum target migrate: Primitive k8s\nmigration page registry: Mirror container\nimages pv: PV / backup sync ingress: Ingress + DNS\ncutover source -> migrate -> magnum source -> registry -> magnum source -> pv -> magnum magnum -> ingress ```
## Prerequisites Before you start, confirm you have: - `kubectl` access to the source cluster and cluster-admin on the target Magnum cluster after provision - OpenTofu installed locally and [application credentials](/docs/platform/access/generate-app-credentials) for Quake AI - Enough quota for a Magnum cluster, worker nodes, and the public IPs your ingress design requires - The concept-translation page for your source: [Coming from AWS](/docs/platform/migration/coming-from-aws), [Coming from Azure](/docs/platform/migration/coming-from-azure), [Coming from GCP](/docs/platform/migration/coming-from-gcp), or [Coming from DigitalOcean](/docs/platform/migration/coming-from-digitalocean) Skim [Deploy the Kubernetes cluster template with OpenTofu](/build/deployments/deploy-k8s-cluster-template) if you have not provisioned Magnum through the template before. ## Step 1: Map the source provider Inventory namespaces, ingress hostnames, storage classes, container registries, and StatefulSets with PersistentVolumeClaims. Note API version differences between the source distribution and Magnum. ## Step 2: Stand up the target cluster 1. Download **k8s-cluster.zip** from the [Kubernetes Cluster Bootstrap](/build/iac-templates/k8s-cluster) template page and unzip it into a working directory. 2. Set cluster name, node count, and flavor variables in `terraform.tfvars`. 3. Run `tofu apply` and configure `kubectl` against the Magnum kubeconfig output. Record how many **floating IPs** your ingress design allocates. The template reference page documents the default count; add public addresses for `LoadBalancer` services or edge-proxy VMs when your architecture requires them. ## Step 3: Move Kubernetes workloads Follow the primitive migration page for your source control plane: | Source | Migration page | | --- | --- | | Amazon EKS | [Migrate from EKS](/docs/kubernetes/migration/migrate-from-eks) | | Google GKE | [Migrate from GKE](/docs/kubernetes/migration/migrate-from-gke) | | Azure AKS | [Migrate from AKS](/docs/kubernetes/migration/migrate-from-aks) | | DigitalOcean DOKS | [Migrate from DOKS](/docs/kubernetes/migration/migrate-from-doks) | Those pages cover manifest export, API mapping, and workload rescheduling. Run `helm template` or `kubectl diff` against Magnum before you drain production traffic. ## Step 4: Move images and artifact data Mirror container images to a registry Magnum worker nodes can reach (Quake AI-hosted registry, Docker Hub, or a registry you operate). Update image references in manifests before cutover. Sync Helm chart archives, backup tarballs, and checkpoint objects with [Migrate from S3](/docs/object/migration/migrate-from-s3) when your pipeline stores artifacts in object storage. ## Step 5: Migrate persistent volume data Snapshot or copy data bound to PersistentVolumeClaims before you reschedule stateful workloads. Validate restore on Magnum worker nodes with matching [storage classes](/docs/block). Update PVC manifests to reference Magnum-compatible classes. ## Step 6: Cut over ingress and DNS 1. Deploy or reconfigure your ingress controller on Magnum. Publish it through a Kubernetes `LoadBalancer` service or an edge proxy on a floating IP. 2. Configure TLS certificates through your ingress controller or certificate operator. 3. Lower DNS TTL in advance, then point hostnames at the Magnum ingress address when health checks pass. **Workload drain and rollback:** cordon and drain source nodes only after Magnum passes health checks and error budgets hold. If error rates spike, switch DNS back to the source ingress and uncordon source nodes. ## Step 7: Verify the migrated platform - Confirm critical Deployments reach `Ready` state on Magnum. - Run application smoke tests against production hostnames. - Validate PVC mounts and database connectivity for stateful services. ## Step 8: Clean up migration scaffolding Delete temporary mirror registries, drop staging namespaces, and decommission the source cluster only after traffic stabilizes on Magnum for the window your team requires. ## What you migrated You moved a Kubernetes platform to Quake AI Magnum with the [Kubernetes cluster template](/build/iac-templates/k8s-cluster) as the target, composed primitive Kubernetes and object migration pages, and cut over ingress with an explicit drain and rollback plan. Return to the [Kubernetes platforms](/build/solutions/kubernetes-platforms) solutions leaf for the workload-shaped migration overview.