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 as the target shape (or the Kubernetes cluster template 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 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 and Migrate from EKS for your source shape
• How to move tenant uploads with 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)

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 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, Coming from Azure, Coming from GCP, or Coming from DigitalOcean

Skim Deploy the full-stack application template with OpenTofu 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 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 and follow Deploy the Kubernetes cluster template with OpenTofu instead of the full-stack path.

Step 3: Move compute workloads#

• Kubernetes source: follow Migrate from EKS to export manifests, mirror images, and reschedule workloads on Magnum.
• VM or Heroku-style source: follow 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. 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 (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 (or Kubernetes cluster template) 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 solutions leaf for the workload-shaped migration overview.