![\"git-APE\"](\"https:\/\/devblogs.microsoft.com\/all-things-azure\/wp-content\/uploads\/sites\/83\/2026\/05\/word-image-2259-1.webp\")
<\/p>\n<\/p>\n
Removing The Monkey Work of Migration; in this post we show how Git-Ape analyses an AWS deployment repo and generates an Azure-native replacement, with design critique built in.<\/span><\/p>\n This post walks through a real migration workflow: start with an AWS deployment repo and end with an Azure deployment repo. The goal isn\u2019t a 1:1 syntax conversion. It\u2019s intent extraction and architecture remapping<\/strong>\u2014agents that read what your deployment does, propose an Azure-native equivalent, and generate deployment-ready artefacts. Along the way, a critique step flags design issues early, before you ship them.<\/p>\n <\/p>\n Related reading:<\/strong> Platform engineering for the agentic AI era (Microsoft DevBlogs)<\/a><\/p>\n Related reading:<\/strong> Putting agentic platform engineering to the test (Microsoft DevBlogs)<\/a><\/p>\n Note:<\/strong> This walkthrough stops at repo and artefact generation. Git-Ape can also help with onboarding (OIDC\/RBAC), quality gates (security, what-if, cost), and controlled deployments, but those steps aren\u2019t shown here.<\/p>\n You\u2019ll need access to an Azure subscription, AWS credentials for the source environment (read-only is enough for analysis), and GitHub access to read\/write repos. In the walkthrough, Git-Ape validates your local CLI tooling and active sign-ins up front (see Step 1).<\/p>\n Input (AWS): <\/strong>contoso-migration<\/a> \u2014 Terraform that deploys the Contoso Outdoors web app on AWS with VPC\/networking, EC2 (Ubuntu 22.04), an Application Load Balancer, S3, and IAM; the app runs via PM2 and exposes an ALB URL.<\/p>\n Output (Azure): <\/strong>contoso-azure<\/a> \u2014 an Azure-native equivalent using git-ape + GitHub Actions to deploy to Azure App Service (Linux, Node.js 20 LTS) with Managed Identity, health checks, and monitoring via Application Insights\/Log Analytics.<\/p>\n Below is the sequence Git-Ape followed\u2014from prerequisites through to generated Azure artefacts.<\/p>\n Invoking @git-ape triggered a prerequisite check that validated all required CLI tools and active auth sessions:<\/p>\n Auth sessions confirmed: Azure subscription active, AWS credentials valid, GitHub CLI authenticated.<\/p>\n Git-Ape read the source repo via GitHub API \u2014 every Terraform file, the user_data.sh bootstrap script, and all documentation. From this, it extracted deployment intent:<\/p>\n Based on the extracted intent, Git-Ape proposed an Azure mapping focused on lowest cost:<\/p>\n Before generating any code, Git-Ape consulted its rubber-duck critique agent for an independent design review. This caught two blocking issues that significantly improved the final output:<\/p>\n Blocking fix 1 \u2014 Deployment model: <\/strong>The initial plan replicated the AWS pattern (download tarball from storage, run npm ci && npm run build on startup). The critique flagged this as a production anti-pattern: slow cold starts, nondeterministic deployments, broken scale-out, and build failures becoming runtime outages.<\/p>\n Fix<\/strong>: build in CI (GitHub Actions), deploy a ready-to-run artefact via zip deploy.<\/p>\n Blocking fix 2 \u2014 Storage layer unnecessary: <\/strong>The original plan included Azure Blob Storage to mirror S3 artefact storage. The critique pointed out this added cost and complexity with no benefit when deploying via CI.<\/p>\n Fix<\/strong>: drop Blob Storage entirely.<\/p>\n Other improvements adopted: <\/strong>drop PM2 (App Service manages processes), add Application Insights from day one, enforce HTTPS-only + TLS 1.2 + disable FTP.<\/p>\n Git-Ape initially started generating Terraform with the AzureRM provider. On human in loop review this then changed to: \u201cwrite the most efficient code\u2014doesn\u2019t have to be Terraform.\u201d That switch landed on Bicep<\/strong> (Azure\u2019s native IaC), producing a single ~80-line template instead of 200+ lines of Terraform.<\/p>\n Once the target shape was agreed, Git-Ape generated the Azure repo and pushed it to GitHub:<\/p>\nTL;DR<\/h2>\n
\n
Prerequisites<\/h2>\n
The scenario: migrate an AWS Terraform deployment to Azure<\/h2>\n
What happened (step by step)<\/h2>\n
Step 1: Validate tooling and sign-in state<\/h3>\n
\n\n
\n Tool<\/td>\n Status<\/td>\n Found Version<\/td>\n Minimum<\/td>\n<\/tr>\n \n az<\/td>\n \u2705<\/td>\n 2.84.0<\/td>\n 2.50<\/td>\n<\/tr>\n \n aws<\/td>\n \u2705<\/td>\n 2.34.30<\/td>\n 2.0<\/td>\n<\/tr>\n \n gh<\/td>\n \u2705<\/td>\n 2.45.0<\/td>\n 2.0<\/td>\n<\/tr>\n \n jq<\/td>\n \u2705<\/td>\n 1.7<\/td>\n 1.6<\/td>\n<\/tr>\n \n git<\/td>\n \u2705<\/td>\n 2.43.0<\/td>\n any<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Step 2: Extract intent from the AWS repo<\/h3>\n
\n
Step 3: Map services to an Azure-native design<\/h3>\n
\n\n
\n AWS (source)<\/td>\n Azure (target)<\/td>\n Outcome<\/td>\n<\/tr>\n \n EC2 + user_data.sh + PM2<\/td>\n App Service (B1, Linux, Node 20)<\/td>\n No server patching\/SSH; platform-managed runtime<\/td>\n<\/tr>\n \n Application Load Balancer (HTTP)<\/td>\n App Service built-in LB + HTTPS-only<\/td>\n Simpler ingress + improved security defaults<\/td>\n<\/tr>\n \n IAM roles\/policies<\/td>\n System-assigned Managed Identity<\/td>\n No stored credentials; Azure RBAC<\/td>\n<\/tr>\n \n Terraform apply from laptop<\/td>\n GitHub Actions (OIDC) + Bicep<\/td>\n Repeatable deployments with audit trail<\/td>\n<\/tr>\n \n No monitoring<\/td>\n Application Insights + Log Analytics<\/td>\n First-class telemetry and troubleshooting<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Step 4: Critique the design before you generate code<\/h3>\n
Step 5: Generate IaC<\/h3>\n
Step 6: Create the target repo and generate deployment artefacts<\/h3>\n