# Migrating from Azure to Quake AI Source: https://docs.quake.ai/docs/platform/migration/from-azure Markdown: https://docs.quake.ai/docs/platform/migration/from-azure.md --- # Migrating from Azure to Quake AI This guide walks you through moving workloads from Microsoft Azure to Quake AI, service by service. Object storage has a dedicated how-to guide. Practical notes below cover compute, networking, and IaC. Managed services (Azure SQL, Azure Functions, App Service) have no direct equivalent and require self-managed alternatives. If you have not reviewed the concept differences, start with [Coming from Azure](/docs/platform/migration/coming-from-azure) for the full mapping table. ## Before you migrate - Review the [concept translation guide](/docs/platform/migration/coming-from-azure) for concept-by-concept mapping - Inventory your Azure resources: Virtual Machines, Storage Accounts, VNets, NSGs, AKS clusters, and any managed services - Identify Azure SQL, Azure Functions, App Service, and Service Bus dependencies that need self-managed alternatives ## Migration phases ### 1. Evaluate and plan Inventory your Azure resources: VMs, Blob containers, VNets, NSGs, ARM templates. Identify managed services with no direct Quake AI equivalent (Azure SQL, Azure Functions, App Service) 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 (Blob storage → Swift) Object storage has a well-supported migration path from Azure: Quake AI's Swift endpoint is S3-compatible, and rclone handles the transfer from Azure Blob Storage natively. **What to watch for:** Objects in Azure's Archive tier need rehydration before you can copy them, which can take up to 15 hours and incurs a per-GB rehydration fee. Plan for this in your migration timeline. Azure lifecycle policies, RBAC, and ABAC do not transfer. For the full cutover procedure, see [Migrate from Azure Blob Storage](/docs/object/migration/migrate-from-azure). ### 4. Infrastructure as code (ARM and Bicep → OpenTofu) Azure uses ARM templates (JSON) or Bicep for declarative infrastructure. Rewrite resources using the `openstack` provider. ARM and Bicep do not have an automatic conversion path to OpenTofu. **Key resource mappings:** | Azure (Terraform) | Quake AI (OpenTofu) | |---|---| | `azurerm_virtual_machine` / `azurerm_linux_virtual_machine` | `openstack_compute_instance_v2` | | `azurerm_storage_account` + `azurerm_storage_container` | `openstack_objectstorage_container_v1` | | `azurerm_network_security_group` | `openstack_networking_secgroup_v2` | | `azurerm_virtual_network` / `azurerm_subnet` | `openstack_networking_network_v2` / `openstack_networking_subnet_v2` | | `azurerm_public_ip` | `openstack_networking_floatingip_v2` | | `azurerm_lb` | 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 (Virtual Machines → Nova) Azure provides VHD download from managed disks (via `az disk grant-access` and SAS URLs), but cross-platform image compatibility (drivers, cloud-init configuration, kernel choices) is often imperfect. The practical migration approach is to provision new instances and migrate application data: **Containerized applications:** Migrate container images and deploy on Nova instances. For AKS workloads, self-managed Kubernetes on Nova (via RKE2 or k3s) is the recommended path; see [Migrate from AKS to Kubernetes on Quake AI](/docs/kubernetes/migration/migrate-from-aks) 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 Azure VM. Use cloud-init or OpenTofu to make provisioning repeatable. **AKS to self-managed K8s:** Export your Kubernetes manifests, Helm charts, and configs. Provision self-managed K8s on Nova instances and apply them. Replace AKS-specific integrations (Entra ID for pod identity, Azure CNI, Azure Disk CSI, Azure Key Vault CSI) with open-source equivalents. See the [full AKS migration guide](/docs/kubernetes/migration/migrate-from-aks) for details. See [Create an instance](/docs/compute/how-to/create-instance) for the full workflow. For the full guide, see [Migrate from Azure VMs to Quake AI Compute](/docs/compute/migration/migrate-from-azure-vms). ### 6. Networking (VNet → Neutron) Re-create your VNet as a **network**, **subnet**, and **router** in Neutron. Basic outbound access does not require a VNet gateway or NAT gateway resource. **NSG → Security groups:** Azure NSGs support allow and deny rules with priority ordering; Neutron security groups are allow-only and additive, bound per port. Re-map each allow rule; if you relied on deny rules or priority ordering, rethink the logic for the additive model. **Public IP → Floating IP:** Same concept. 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, the dual NSG merge procedure, and public-address migration, see [Migrate from Azure VNet to Quake AI](/docs/network/migration/migrate-from-azure-vnet). Translate Application Gateway routes and backends 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 Azure resources: - [ ] Verify that applications respond on Quake AI instances with the expected behavior - [ ] Confirm object storage data integrity between Blob 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 Azure NSG rules - [ ] Confirm monitoring and alerting are in place (self-managed Prometheus, Grafana, or equivalent) ## Service mapping reference The table below shows how Azure 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 | Azure service | Status on Quake AI | Alternative | |---|---|---| | Azure Functions | Not available | Containers on VMs or Kubernetes | | Azure SQL / Cosmos DB | Not available | Self-managed databases on VMs | | Azure Service Bus | Not available | Self-managed RabbitMQ, Redis, or NATS | | Azure App Service | Not available | Deploy on VMs with Docker or Kubernetes | | Azure Cache for Redis | Not available | Self-managed Redis on a VM | | Azure DNS | Not available | External DNS provider (Cloudflare or similar) | For the full comparison, see [Coming from Azure: What Azure has that Quake AI does not](/docs/platform/migration/coming-from-azure#what-azure-has-that-rumble-does-not). ## Next steps - [Coming from Azure](/docs/platform/migration/coming-from-azure): concept translation reference - [Migrate from Azure Blob Storage](/docs/object/migration/migrate-from-azure) - [Infrastructure as Code with OpenTofu](/docs/automation/how-to/getting-started-iac) - [All migration guides](/docs/platform/migration)