# Migrate a B2B SaaS application to Quake AI Source: https://docs.quake.ai/docs/platform/migration/migrate-saas-b2b-to-quake-ai Markdown: https://docs.quake.ai/docs/platform/migration/migrate-saas-b2b-to-quake-ai.md > Move an existing B2B SaaS application from EKS, ECS, Heroku, or VM fleets to Quake AI by standing up the full-stack-app template, syncing tenant data through primitive migration guides, and cutting over DNS with rollback. --- # Migrate a B2B SaaS application to Quake AI In this migration guide, you move an existing B2B SaaS application to Quake AI. You stand up the [full-stack app template](/build/iac-templates/full-stack-app) as the target shape (or the [Kubernetes cluster template](/build/iac-templates/k8s-cluster) if you deploy with Helm), sync tenant data and uploads from the source, and cut over DNS with a blue/green path and rollback. The full-stack template runs self-managed MariaDB on a private subnet and exposes the Nginx web tier through a floating IP. Add a third-party CDN for static acceleration or a dedicated [edge reverse proxy](/build/iac-templates/edge-reverse-proxy) for automatic HTTPS in front of private backends. **What you will migrate:** a multi-tenant SaaS product on Amazon EKS or ECS, Azure AKS, Google GKE, Heroku, or VM fleets at another cloud. **What you will learn:** - How to pick the target template (`full-stack-app` for a compact VM stack, `k8s-cluster` for Helm-based deploys) - How to sequence [Migrate from EC2](/docs/compute/migration/migrate-from-ec2) and [Migrate from EKS](/docs/kubernetes/migration/migrate-from-eks) for your source shape - How to move tenant uploads with [Migrate from S3](/docs/object/migration/migrate-from-s3) - How to cut over API and web traffic with session continuity planning and DNS rollback **Time estimate:** 75 minutes (excluding large tenant database sync time)
```d2 direction: right source: Source SaaS\n(EKS / Heroku / VMs) target: full-stack-app\nweb + app + DB eks: Migrate from EKS ec2: Migrate from EC2 s3: Migrate from S3 cut: Blue/green DNS\ncutover source -> target source -> eks: k8s path source -> ec2: VM path target -> s3: tenant uploads target -> cut ```
## Prerequisites Before you start, confirm you have: - Admin access to the source cluster or VM fleet and tenant database export paths - OpenTofu installed locally and [application credentials](/docs/platform/access/generate-app-credentials) for Quake AI - Enough quota for three instances, one block volume, and **one floating IP** on the web tier (full-stack template defaults) - 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 full-stack application template with OpenTofu](/build/deployments/deploy-full-stack-app-template) if you have not applied that template before. ## Step 1: Map the source provider Document tenant isolation (schema-per-tenant vs shared schema), session store location, object bucket prefixes for uploads, and the production API hostname. Use your provider concept-translation page to map edge routing, security groups, and managed Kubernetes objects to the corresponding Quake AI patterns. ## Step 2: Stand up the target stack For a VM-based SaaS target: 1. Download **full-stack-app.zip** from the [Full-Stack Application](/build/iac-templates/full-stack-app) template page and unzip it into a working directory. 2. Set `db_password` and flavor variables in `terraform.tfvars`. 3. Run `tofu apply` and record the web tier floating IP from outputs. The template allocates **one floating IP** on the Nginx web tier. App and database tiers stay on private addresses. For Kubernetes-hosted SaaS, provision the target with the [Kubernetes cluster template](/build/iac-templates/k8s-cluster) and follow [Deploy the Kubernetes cluster template with OpenTofu](/build/deployments/deploy-k8s-cluster-template) instead of the full-stack path. ## Step 3: Move compute workloads - **Kubernetes source:** follow [Migrate from EKS](/docs/kubernetes/migration/migrate-from-eks) to export manifests, mirror images, and reschedule workloads on Magnum. - **VM or Heroku-style source:** follow [Migrate from EC2](/docs/compute/migration/migrate-from-ec2) to rebuild application servers on Quake AI compute. Link to those pages for step-by-step mechanics; this guide only sequences them for a SaaS cutover. ## Step 4: Move tenant data and uploads Export tenant database state (dump/restore or logical replication) into the target MariaDB or Postgres instance. Validate row counts per tenant or schema before cutover. Sync tenant file uploads and static exports with [Migrate from S3](/docs/object/migration/migrate-from-s3). Update application environment variables to point at the new bucket endpoint. ## Step 5: Recreate network topology Translate VPCs, subnets, and security groups with [Migrate from AWS VPC](/docs/network/migration/migrate-from-aws-vpc) (or the matching network migration page for your provider). Confirm security groups allow app-to-database traffic on private subnets only. ## Step 6: Cut over traffic 1. Export secrets and OAuth client settings from the source platform. Load them into OpenTofu variables, Kubernetes Secrets, or a vault you operate on Quake AI. Rotate credentials that cannot move verbatim. 2. Stage the target behind its Nginx web tier or an edge reverse proxy and verify application health endpoints. 3. Lower DNS TTL in advance, then point the production API hostname at the Quake AI floating IP when health checks pass. **Session continuity:** active browser sessions may not survive the DNS switch. Shorten session TTL before cutover or accept a one-time re-login window. **Rollback:** point DNS back to the source load balancer if error rates or tenant login failures exceed your threshold. Keep the source stack warm until the target holds steady. ## Step 7: Verify the migrated application - Run synthetic login and API smoke tests for representative tenants. - Confirm upload URLs and signed links resolve against the new Object Storage bucket. - Watch application health checks and error logs for one full traffic cycle. ## Step 8: Clean up migration scaffolding Remove temporary sync instances, drop staging databases that duplicate production, and decommission source resources only after verification holds for the window your team requires. ## What you migrated You moved a B2B SaaS application to Quake AI using the [full-stack app template](/build/iac-templates/full-stack-app) (or [Kubernetes cluster template](/build/iac-templates/k8s-cluster)) as the target, composed primitive migration pages for compute and object data, and cut over with an explicit DNS rollback path. Return to the [SaaS and B2B applications](/build/solutions/saas-b2b) solutions leaf for the workload-shaped migration overview.