/azure-to-aws

name: azure-to-aws
description: "Migrate workloads from Microsoft Azure to AWS. Triggers on: migrate from Azure, Azure to AWS, move off Azure, migrate AKS to EKS, migrate App Service or Azure VMs to AWS compute, migrate Azure SQL or Azure Database to RDS, migrate Cosmos DB to DynamoDB, migrate Azure OpenAI to Bedrock, move Azure AI or agentic workloads to AWS, estimate AWS costs for my Azure infrastructure, what-if workshop. Runs a 6-phase process: discover Azure resources from Terraform, app code, and billing exports, then clarify, design, estimate costs (1:1 lift and right-sized), optionally reprice scenarios, generate artifacts, and collect feedback. Clarify gates Design, Estimate, and Generate; Generate is opt-in at the post-Estimate decision gate. Bicep/ARM/live-`az` discovery is not yet implemented; such a workspace halts. Do not use for: GCP migrations (see gcp-to-aws), Heroku migrations (see heroku-to-aws), general AWS architecture advice (see architect-for-startups), AWS-to-Azure reverse migration, or Azure-to-Azure refactoring."

Azure-to-AWS Migration Skill

> **Build status.** This skill's phase skeleton and DSL wiring are complete; the > per-phase CONTENT is landing in sequenced steps. Every unit file carries a > `## Status` block naming what it does today and which step fills it in. Do not > read a skeleton unit's thin body as the finished contract.

Philosophy

• **Re-platform by default**: pick the AWS service that matches the Azure workload type (App Service → Elastic Beanstalk, AKS → EKS, VMs → EC2, Flexible Server → RDS/Aurora, Azure Cache for Redis → ElastiCache). Re-architecting is a user decision, not a default.
• **Do not recommend AWS App Runner** (no longer accepting new customers as of April 2026). App Service maps to **Elastic Beanstalk** by default, with Fargate as the override for direct container control and EKS for teams that already run Kubernetes. ECS Express Mode may be mentioned only as a forward-look on the Fargate override path.
• **Live-first discovery, read-only and consent-gated (planned)**: the design intent is that the user's authenticated `az` CLI is a first-class source — most startups have no `azurerm_*` Terraform, and the tenant is authoritative for what actually runs. **The live-`az` capture fragment is not on this branch yet** (Terraform is the built discovery source today; a live-only workspace halts rather than guessing); it lands as a sequenced follow-up. Resource Discovery for Azure (RDfA) is offered as the **accuracy upgrade** when right-sizing dollars matter, and recommended outright above roughly a handful of subscriptions. Live capture is strictly read-only, never captures app-setting or connection-string VALUES, and never mints a token.
• **Holistic first, per-resource second**: the report leads with cluster-level architecture rationale. A 40-row per-resource mapping table is an appendix, not the headline.
• **Pre-determined where there is no ambiguity**: an architecture-invariant primitive (Blob → S3, VNet → VPC) is a deterministic table lookup and never routed through a rubric that could reason its way somewhere else. A pattern may narrow the rubric's candidate set; **a pattern may never change a `deterministic` mapping's target.**
• **Dev sizing unless specified**: default to development-tier capacity (single AZ, `db.t4g.micro`-class). Upgrade only on user direction or on measured utilization.
• **x86_64 is the default architecture here, not Graviton**: Azure fleets carry Windows and .NET far more often than GCP or Heroku fleets do, and `references/shared/graviton.md`'s escape path (Windows, .NET Framework, GPU/CUDA, RDS SQL Server) fires routinely. Graviton is offered as an optimization, not assumed.
• **Startup-weighted, not enterprise-weighted**: Azure Database for PostgreSQL/MySQL Flexible Server and Cosmos DB Core API get full depth. Azure SQL Database / Managed Instance / SQL-on-VM, Azure Hybrid Use Benefit licensing, elastic-pool consolidation, and Synapse sit behind specialist gates that fire only on detection.
• **No human one-time migration costs**: do not present human labor, professional services, or people-time as dollar estimates or a "one-time migration cost" budget line. Vendor charges grounded in data (Azure invoice line items in the baseline) are allowed.
• **Generate is opt-in**: Design and Estimate always run. Terraform, migration scripts, and docs are produced only after the user chooses Execute at the post-Estimate decision gate (`run_mode: decide_and_execute`).

---

Definitions

• **"Load"** = Read the file using the Read tool and follow its instructions. Do not summarize or skip sections.
• **`$MIGRATION_DIR`** = The run-specific directory under `.migration/` (e.g. `.migration/0315-1030/`). Set during Discover.
• **`$AZURE_SUBSCRIPTION`** = The subscription id passed explicitly on every `az` command. Never rely on the CLI's ambient active-subscription context.
• **Canonical type** = an ARM resource type string (`Microsoft.Web/sites`). All mapping tables key off these, never off Terraform types; `azurerm_*` is translated during discovery.

---

Phase Structure (frontmatter)

Phase and unit files carry a YAML frontmatter block that declares how the phase is composed — its inputs, the fragments it runs, the assembler that combines them, what it produces, its gates, and what it requires/advances-to. The DSL interpreter contract is the vendored `references/vendored/dsl/INTERPRETER.md`: it defines every frontmatter key, the fragment/assembler model, and the interpreter loop. **Load it first** (once, at the start of a migration), then execute a phase file's prose body. Elsewhere in this skill, `INTERPRETER.md` (without a path) refers to this same loaded contract.

The phase set, its order, the gates, and the state transitions are all DERIVED from that frontmatter. They are deliberately not restated anywhere in this file — a hand-maintained phase table is exactly the drift surface the frontmat