# Migration

Source: https://docs.quake.ai/docs/platform/migration
Markdown: https://docs.quake.ai/docs/platform/migration.md
> Evaluate Quake AI against your current provider and move workloads, with service mappings from AWS, Azure, GCP, DigitalOcean, and Hetzner.

---

# Migration

Evaluate Quake AI against your current provider, then move workloads. Quake AI runs on [OpenStack](/docs/platform/migration/openstack), so every service below maps to a standard OpenStack project (Nova for compute, Neutron for networking, Cinder for block storage, Swift for object storage). Each provider entry below links to a concept-translation page that maps the services. The companion migration workflow (`Migrate from {provider}`) sits at the bottom of the concept page and in the sidebar.

## Common migration workflow

A typical provider migration follows six phases:

1. **Evaluate and plan.** Read the concept-translation page for your provider. Identify which resources need to migrate: compute, object storage, block storage, networking, IaC templates, container workloads.
2. **Set up your Quake AI account.** Create a project, generate application credentials, and install the OpenStack CLI. See the [Quickstart](/docs/quickstart).
3. **Migrate object storage.** Object storage is typically the lowest-risk, highest-volume migration. Quake AI's S3-compatible API works with standard tools (rclone, aws-cli, s3cmd) once you swap the endpoint and credentials.
4. **Rewrite Infrastructure as Code.** Translate provider-specific Terraform resources to the [`openstack` provider](https://registry.terraform.io/providers/terraform-provider-openstack/openstack/latest/docs). Terraform stacks port directly; ARM, Bicep, and CloudFormation get rewritten.
5. **Provision compute and networking.** Create instances, networks, subnets, routers, security groups, and floating IPs on Quake AI. The practical approach is to provision new instances and migrate application data, since cross-platform image compatibility (drivers, cloud-init configuration, kernel choices) is often imperfect even when image export is available.
6. **Validate and cut over.** Verify applications respond correctly, point DNS at the new floating IPs, and confirm monitoring is in place before decommissioning source infrastructure.

## By provider

<UseCaseGrid>
<UseCaseCard
  title="AWS"
  description="The largest concept-translation page on the platform. EC2 to Compute, S3 to Swift or the S3-compatible API, IAM to Keystone application credentials, VPC to Neutron. Includes a quick-reference mapping table, the IAM-to-application-credential model shift, and an OpenTofu example for the openstack provider."
  href="/docs/platform/migration/coming-from-aws"
  services={["Compute", "Storage", "Network", "Kubernetes", "Automation"]}
/>
<UseCaseCard
  title="Azure"
  description="Virtual Machines to Compute, Blob Storage to Swift, NSGs to security groups. Covers the NSG-to-security-group model shift (allow-only, no priority ordering, per-port binding), the Entra ID to application credentials change, and the AKS to Magnum trade-offs."
  href="/docs/platform/migration/coming-from-azure"
  services={["Compute", "Storage", "Network", "Kubernetes"]}
/>
<UseCaseCard
  title="DigitalOcean"
  description="Droplets to instances, Spaces to Swift, VPC to Neutron. The move is lateral: same mental model, OpenStack APIs, and a fixed-monthly pricing model with no transfer caps."
  href="/docs/platform/migration/coming-from-digitalocean"
  services={["Compute", "Storage", "Network", "Kubernetes", "Automation"]}
/>
<UseCaseCard
  title="GCP"
  description="Compute Engine to Compute, Cloud Storage to Swift, VPC firewall rules to Neutron security groups. The managed-services gap is the largest decision point."
  href="/docs/platform/migration/coming-from-gcp"
  services={["Compute", "Storage", "Network", "Kubernetes"]}
/>
<UseCaseCard
  title="Hetzner Cloud"
  description="Cloud Servers to Compute, Object Storage to Swift, abstract private networks to explicit Neutron networks, subnets, and routers. The networking model is the largest conceptual shift."
  href="/docs/platform/migration/coming-from-hetzner"
  services={["Compute", "Storage", "Network", "Kubernetes", "Automation"]}
/>
<UseCaseCard
  title="Linode (Akamai)"
  description="Linodes to Instances, Block Storage to Cinder, Object Storage to Swift, VPC and Cloud Firewall to explicit Neutron networks and security groups, NodeBalancers to self-managed edge proxies, and LKE to self-managed Kubernetes on Nova."
  href="/docs/platform/migration/coming-from-linode"
  services={["Compute", "Storage", "Network", "Kubernetes", "Automation"]}
/>
<UseCaseCard
  title="Vultr"
  description="Cloud Compute instances to Nova, Block Storage to Cinder, Object Storage to Swift, VPC 2.0 to explicit Neutron networks and subnets, Firewall Groups to security groups, Load Balancers to self-managed edge proxies, and VKE to self-managed Kubernetes on Nova."
  href="/docs/platform/migration/coming-from-vultr"
  services={["Compute", "Storage", "Network", "Kubernetes", "Automation"]}
/>
</UseCaseGrid>

The sidebar groups the concept-translation page and its companion `Migrate from {provider}` workflow together under each provider, so they read in order.

## Service mapping

Each table below lists the services or resource concepts on the source provider and links to the Quake AI documentation for the equivalent. The right-hand column carries the key divergence the migrating developer needs to plan for.

<MigrationTable provider="aws" />

<MigrationTable provider="azure" />

<MigrationTable provider="gcp" />

<MigrationTable provider="do" />

<MigrationTable provider="hetzner" />

<MigrationTable provider="linode" />

<MigrationTable provider="vultr" />

## Background

| Page | What it covers |
| --- | --- |
| [How Quake AI uses OpenStack](/docs/platform/migration/openstack) | Service-to-project map between Quake AI products and upstream OpenStack projects |
| [OpenStack for AWS developers](/docs/platform/migration/openstack-for-aws-developers) | How an OpenStack-backed platform reads to AWS-trained engineers |

The [platform overview](/docs/platform#pricing) documents pricing model differences (fixed monthly, no egress charges, no per-API-call billing).