# Migrating from GCP to Quake AI Source: https://docs.quake.ai/docs/platform/migration/from-gcp Markdown: https://docs.quake.ai/docs/platform/migration/from-gcp.md --- # Migrating from GCP to Quake AI This guide walks you through moving workloads from Google Cloud Platform to Quake AI, service by service. Object storage has a dedicated migration how-to guide. Practical notes below cover compute, networking, and IaC. Managed services (Cloud SQL, Cloud Functions, BigQuery) have no direct equivalent and require self-managed alternatives. If you have not reviewed the concept differences, start with [Coming from GCP](/docs/platform/migration/coming-from-gcp) for the full mapping table. ## Before you migrate - Review the [concept translation guide](/docs/platform/migration/coming-from-gcp) for concept-by-concept mapping - Inventory your GCP resources: Compute Engine VMs, Cloud Storage buckets, VPCs, firewall rules, GKE clusters, and any managed services - Identify Cloud SQL, Cloud Functions, Pub/Sub, and BigQuery dependencies that need self-managed alternatives ## Migration phases ### 1. Evaluate and plan Inventory your GCP resources: Compute Engine VMs, Cloud Storage buckets, VPCs, firewall rules, Deployment Manager or Terraform configs. Identify managed services with no direct Quake AI equivalent (Cloud SQL, Cloud Functions, BigQuery) and plan self-managed replacements. ### 2. Account setup Create your Quake AI project, generate application credentials, and install the OpenStack CLI. - [Quickstart](/docs/quickstart) - [Generate application credentials](/docs/platform/access/generate-app-credentials) - [Access & Credentials](/docs/platform/access/) for the OpenStack CLI ### 3. Object storage (Cloud Storage → Swift) Object storage has the most direct migration path from GCP. Quake AI's Swift endpoint is S3-compatible, and rclone handles the transfer from GCS natively. **What to watch for:** GCS storage classes (Nearline, Coldline, Archive) have minimum storage duration charges. If you delete objects before the minimum duration, GCS charges early deletion fees. Factor this into your migration timeline. GCS lifecycle rules and IAM policies do not transfer. For the full cutover procedure, see [Migrate from Google Cloud Storage](/docs/object/migration/migrate-from-gcs). ### 4. Infrastructure as code (gcloud and Deployment manager → OpenTofu) GCP uses `gcloud` for imperative operations and the `google` Terraform provider for declarative infrastructure. Rewrite resources using the `openstack` provider. No automatic conversion tool exists. **Key resource mappings:** | GCP (Terraform) | Quake AI (OpenTofu) | |---|---| | `google_compute_instance` | `openstack_compute_instance_v2` | | `google_storage_bucket` | `openstack_objectstorage_container_v1` | | `google_compute_firewall` | `openstack_networking_secgroup_v2` + rules | | `google_compute_network` / `google_compute_subnetwork` | `openstack_networking_network_v2` / `openstack_networking_subnet_v2` | | `google_compute_address` | `openstack_networking_floatingip_v2` | | `google_compute_forwarding_rule` | Edge reverse proxy, WAF, or API gateway on Nova with a Neutron floating IP | Get started with [Infrastructure as Code with OpenTofu](/docs/automation/how-to/getting-started-iac). ### 5. Compute (Compute engine → Nova) GCP provides `gcloud compute images export`, which exports a Compute Engine image to a Cloud Storage bucket in VMDK, VHDX, VPC, QCOW2, or VDI format. Cross-platform image compatibility (drivers, cloud-init configuration, kernel choices) is often imperfect, so the practical migration approach is to provision new instances and migrate application data: **Containerized applications:** Migrate container images and deploy on Nova instances. For GKE workloads, self-managed Kubernetes on Nova (via RKE2 or k3s) is the recommended path; see [Migrate from GKE to Kubernetes on Quake AI](/docs/kubernetes/migration/migrate-from-gke) for the full guide. **Non-containerized applications:** Provision a new Nova instance with the same base image, install your application stack, and rsync data from the GCE instance. Use cloud-init or OpenTofu to make provisioning repeatable. **GKE to self-managed K8s:** Export your manifests, Helm charts, and configs. Provision self-managed K8s on Nova instances and apply them. Replace Workload Identity, Config Connector CRDs, and GKE Ingress with open-source equivalents. See the [full GKE migration guide](/docs/kubernetes/migration/migrate-from-gke) for details. See [Create an instance](/docs/compute/how-to/create-instance) for the full workflow. For the full guide, see [Migrate from GCP Compute Engine to Quake AI Compute](/docs/compute/migration/migrate-from-gce). ### 6. Networking (VPC → Neutron) Re-create your GCP VPC as a **network**, **subnet**, and **router** in Neutron. **Firewall rules → Security groups:** GCP firewall rules support allow and deny with priority ordering; Neutron security groups are allow-only and additive. Re-map each allow rule; rethink any deny rules or priority-ordered logic for the additive model. **Static external IP → Floating IP:** Allocate from the external pool and associate with your instance's port. Key how-to guides: - [Create a network](/docs/network/how-to/create-network) - [Create a security group](/docs/network/how-to/create-security-group) - [Allocate floating IPs](/docs/network/how-to/allocate-floating-ips) For topology diagrams, three-tier security rule translation, and public-address migration, see [Migrate from GCP VPC to Quake AI](/docs/network/migration/migrate-from-gcp-vpc). Translate HTTP routing and backend services into an [edge reverse proxy](/build/iac-templates/edge-reverse-proxy) or [API gateway](/build/iac-templates/api-gateway). ### 7. Validation and cutover Before decommissioning GCP resources: - [ ] Verify that applications respond on Quake AI instances with the expected behavior - [ ] Confirm object storage data integrity between Cloud Storage and Swift - [ ] Update DNS records to point to Quake AI floating IPs; use low TTLs during the transition - [ ] Validate security group rules cover the same traffic patterns as your GCP firewall rules - [ ] Confirm monitoring and alerting are in place (self-managed Prometheus, Grafana, or equivalent) ## Service mapping reference The table below shows how GCP services map to Quake AI equivalents, with confidence ratings and documented divergences. The `` component reads from the platform knowledge graph. ## Self-managed services and deployment patterns | GCP service | Status on Quake AI | Alternative | |---|---|---| | Cloud Functions / Cloud Run | Not available | Containers on VMs or Kubernetes | | Cloud SQL | Not available | Self-managed PostgreSQL or MySQL on a VM | | BigQuery | Not available | Self-managed ClickHouse, PostgreSQL, or similar | | Pub/Sub | Not available | Self-managed RabbitMQ, Redis, or NATS | | Memorystore | Not available | Self-managed Redis on a VM | | Cloud DNS | Not available | External DNS provider (Cloudflare or similar) | For the full comparison, see [Coming from GCP: What GCP has that Quake AI does not](/docs/platform/migration/coming-from-gcp#what-gcp-has-that-rumble-does-not). ## Next steps - [Coming from GCP](/docs/platform/migration/coming-from-gcp): concept translation reference - [Migrate from Google Cloud Storage](/docs/object/migration/migrate-from-gcs) - [Infrastructure as Code with OpenTofu](/docs/automation/how-to/getting-started-iac) - [All migration guides](/docs/platform/migration)