Git-Ape: Microsoft's Agentic Migration Framework That Converts AWS to Azure

By Law Wen Feng, Principal Solution Architect — Malaysia

If you have ever migrated a workload from AWS to Azure, you know the pain. You stare at a Terraform repo full of EC2 instances, IAM roles, S3 buckets, and load balancers, and you begin the painstaking process of manually translating each resource into its Azure equivalent. The networking is different. The identity model is different. The deployment patterns are different. And buried inside your user_data scripts are tribal knowledge assumptions that no documentation ever captured.

Microsoft recently released an open-source framework that attacks this exact problem — not with a simple find-and-replace, but with AI agents that understand what your infrastructure is actually trying to do and propose Azure-native replacements. The framework is called Git-Ape, and it represents a new category of tooling: agentic platform engineering.

I have been following Git-Ape since it appeared on GitHub under the Azure organisation. After spending time with the source code, the documentation, and Microsoft's published migration walkthrough, I want to share what this tool is, how it works, and whether it is something your team should consider for your next cloud migration project.

What Is Git-Ape?

Git-Ape is a platform engineering framework built on top of GitHub Copilot. It is a multi-agent system — meaning it uses multiple specialised AI agents working together — that plans, validates, and deploys Azure workloads with security gates, cost analysis, and CI/CD pipeline integration baked in.

The project is open source under the MIT license and lives at github.com/Azure/git-ape. It ships as a VS Code agent plugin and a GitHub Copilot CLI plugin.

The name is a deliberate play on "monkey work" — the tedious, repetitive tasks that engineers waste hours on during migration and deployment. Git-Ape aims to eliminate that monkey work.

Here is the critical thing to understand: Git-Ape is not a simple syntax converter. It does not translate Terraform HCL into Bicep line by line. Instead, it performs what Microsoft calls "intent extraction and architecture remapping." The agents read your existing deployment code, understand what it is trying to accomplish, and then propose an Azure-native equivalent that follows Azure best practices.

How Git-Ape Automates AWS-to-Azure Migration

The migration workflow follows a structured pipeline managed by a central orchestrator agent called @git-ape. Here is the step-by-step process.

Step 1: Prerequisite Validation

Before anything happens, Git-Ape checks that your tooling is in place. It validates Azure CLI (az), GitHub CLI (gh), jq, and git — along with your active authentication sessions (az login, gh auth login). For AWS-to-Azure migrations, it additionally confirms your AWS credentials are valid (read-only access is enough for repo analysis). You can trigger the tooling check manually with the /prereq-check command.

# Verify all tools are installed and authenticated
/prereq-check

This catches the most common failure mode: discovering midway through a migration that your Azure subscription token expired three days ago.

Step 2: Intent Extraction from the Source Repository

This is where the AI agents earn their keep. Git-Ape reads your source AWS repository — every Terraform file, every script, every README — via the GitHub API. It then extracts deployment intent:

• What runtime is being used (e.g., Next.js on Node.js 20)
• What compute resources are provisioned (e.g., EC2 t3.micro)
• What networking exists (VPCs, subnets, load balancers, security groups)
• What storage and identity patterns are in play
• What monitoring is configured (or, more commonly, what is missing)

In Microsoft's published walkthrough, Git-Ape analysed a Contoso Outdoors web application running on AWS with EC2, an Application Load Balancer, S3 for artifact storage, IAM for identity, and PM2 for process management. It extracted every detail including the fact that the app built itself on startup from a tarball downloaded from S3 — a pattern that was not documented anywhere.

Step 3: Azure Architecture Remapping

Based on the extracted intent, Git-Ape proposes an Azure-native mapping. The agents choose the most appropriate Azure services, not just the closest 1:1 equivalent. In the Contoso example:

The key insight here is that Git-Ape does not just copy your architecture across clouds. It recommends the Azure-native pattern. The S3 bucket disappeared because the agents recognised that deploying via CI makes artifact storage in a separate bucket redundant.

Step 4: Design Critique

Before generating any code, Git-Ape runs its output through an independent design review agent — a "rubber duck critique" step. In the published example, this caught two blocking issues:

1. Build-on-startup anti-pattern: The original AWS setup ran npm ci && npm run build on every instance boot. The critique agent flagged this as a production anti-pattern causing slow cold starts, nondeterministic deployments, and broken scale-out. The fix: build in CI, deploy a ready-to-run artifact via zip deploy.

1. Unnecessary storage mirroring: The initial plan included Azure Blob Storage to mirror S3. The critique pointed out this added cost and complexity with zero benefit when deploying via CI. The fix: drop Blob Storage entirely.

This critique step is what separates Git-Ape from a glorified code generator. It applies architectural reasoning before writing a single line of infrastructure code.

Step 5: Infrastructure Code Generation

Git-Ape generates deployment-ready artifacts. In the migration walkthrough, it produced:

• Bicep template (infra/main.bicep): An approximately 80-line template defining the App Service Plan, Web App, Application Insights, and Log Analytics workspace. Notably, it chose Bicep over Terraform — Azure's native IaC format — which resulted in significantly cleaner output.

• GitHub Actions workflow (.github/workflows/deploy.yml): A complete CI/CD pipeline with checkout, Node.js setup, npm build, Azure login via OIDC, resource group creation, Bicep deployment, zip deploy, and health checks.

• Documentation: Updated README.md and a DEPLOYMENT_GUIDE.md tailored to Azure.

The generated Azure deployment reduced the estimated monthly cost from approximately $34 (AWS) to $13 (Azure) while adding security features like HTTPS-only, TLS 1.2 enforcement, FTP disabled, and Managed Identity.

Step 6: Optional Quality Gates and Deployment

Git-Ape's full pipeline includes additional stages that were not exercised in the migration walkthrough but are available:

• Security gate: Automated security analysis of generated templates with blocking/pass verdicts
• Preflight validation: ARM what-if analysis before any deployment
• Cost estimation: Real-time Azure Pricing API queries for per-resource cost breakdowns
• Deployment execution: az deployment create with progress monitoring
• Integration testing: Post-deployment health checks
• Drift detection: Ongoing reconciliation between live Azure state and stored deployment artifacts

Supported Services and Output Formats

Git-Ape supports any Azure resource deployable via Azure Resource Manager. The agents back this up with a dedicated reference-lookup skill that fetches official Azure REST API and ARM template documentation — exact property schemas, required fields, and latest stable API versions — before generating or modifying templates, so they are not limited to a hardcoded list of resource types.

The framework's Template Generator natively produces ARM templates in JSON, and in the AWS migration walkthrough the output landed on Bicep (Azure's domain-specific language for ARM) — not by default, but after human-in-the-loop steering. Git-Ape initially started generating Terraform with the AzureRM provider; the reviewer changed the instruction to "write the most efficient code — doesn't have to be Terraform," and the result was a single ~80-line Bicep template instead of 200+ lines of Terraform.

For CI/CD, it generates GitHub Actions workflows. The deployment model uses OIDC federation for authentication — no stored secrets, with full audit trails.

The framework ships with 8 specialised agents and 15 skills (as of writing):

Agents include the Requirements Gatherer, Template Generator, Resource Deployer, Principal Architect (WAF review), Policy Advisor, and IaC Exporter, all orchestrated by the central @git-ape agent.

Skills cover areas like ARM API reference lookup, Cloud Adoption Framework naming, resource availability checks, security analysis, Azure Policy compliance (CIS, NIST), cost estimation, drift detection, and integration testing.

Current Limitations

Git-Ape is marked as EXPERIMENTAL and is not production-ready. Microsoft is explicit about this. Here is what you need to know:

Cloud coverage is Azure-only. Git-Ape generates Azure deployments. If you need multi-cloud output or are targeting GCP, this is not the tool. The AWS analysis capability reads AWS repos as input, but the output is always Azure-native.

GitHub-centric. The CI/CD pipeline integration is built around GitHub Actions. If your team uses Azure DevOps, GitLab CI, or another platform, you will need to adapt the generated workflows.

ARM and Bicep, not Terraform. Git-Ape's Template Generator defaults to ARM JSON templates, and in the migration walkthrough it settled on Bicep — either way, Terraform is not a first-class output format. Teams standardised on Terraform will find the generated output requires translation. In the Contoso example, that trade paid off: roughly 80 lines of Bicep replaced 200+ lines of Terraform — but adoption reality in the field is more nuanced, and many enterprises have Terraform skills and pipelines that Bicep cannot simply replace.

Requires GitHub Copilot. The entire framework runs on GitHub Copilot's agent infrastructure. You need a Copilot subscription, and the agents run within Copilot's context limits. This is not a standalone CLI tool you can run independently.

Not production-grade. The warning banner is there for a reason. The agents can generate incorrect resource configurations, misidentify service mappings, or produce templates that fail validation. Every output requires human review.

Limited to deployment code analysis. Git-Ape reads your IaC repositories, not your running infrastructure directly (though the IaC Exporter skill can import live resources). If your actual deployment diverges from what your Terraform code describes, Git-Ape will migrate the code, not reality.

Practical Adoption Guidance for Teams in Southeast Asia

For Azure-first enterprise teams in Malaysia and across the region, here is my practical take on when and how to use Git-Ape.

Use it for discovery, not just migration. Even if you are not migrating from AWS, Git-Ape's intent extraction and architecture critique capabilities are valuable. Point it at your existing Azure deployments to get an independent architectural review. The security gate and WAF assessment skills work on any Azure workload.

Start with a sandbox. Do not run Git-Ape against your production subscription. Use a dedicated development subscription and treat the first run as a learning exercise. The framework's safety model is designed around this — it requires explicit confirmation before any deployment.

Pair it with Azure Migrate. Git-Ape handles the infrastructure-as-code conversion. Azure Migrate handles discovery, assessment, and server migration. They are complementary tools, not competing ones. Use Azure Migrate to understand your estate, then use Git-Ape to generate the deployment patterns for target workloads.

Contribute back. The project is MIT-licensed and actively accepting feedback. If you find gaps in service mapping for Azure resources commonly used in the region — Azure Government, sovereign cloud configurations, regional availability zone patterns — the GitHub Issues page is the place to flag them.

Watch the Copilot licensing cost. Git-Ape requires GitHub Copilot, which means per-developer licensing. For teams evaluating this tool, factor the Copilot subscription cost into your migration budget alongside the Azure consumption costs.

Getting Started

If you want to experiment with Git-Ape today:

1. Install the VS Code extension from the VS Code Marketplace
2. Sign in with az login and configure the Azure MCP server
3. Open a repository containing Azure or AWS deployment code
4. In Copilot Chat, try: @git-ape deploy a Python function app or @git-ape analyse this AWS repo for Azure migration
5. Review the output critically — treat it as a draft, not a final answer

The framework is evolving rapidly. Microsoft has published a detailed walkthrough of the AWS-to-Azure migration workflow on the Azure DevBlogs that is worth reading alongside this article.

Key Takeaways

1. Git-Ape is not a syntax translator. It performs intent extraction from existing infrastructure code and proposes Azure-native replacements that follow best practices — a fundamentally different approach from simple code conversion.

1. The design critique step is the most valuable feature. Before generating any code, an independent agent reviews the proposed architecture and catches anti-patterns. In Microsoft's published example, it identified two blocking design issues that would have degraded production reliability.

1. It is experimental — use it for learning and discovery. Git-Ape is explicitly not production-ready. Treat generated output as a well-informed starting draft that requires human review, security validation, and adaptation to your organisation's standards.

1. The agent model reduces maintenance burden. Instead of maintaining 50+ Bicep or Terraform modules, you update the agent's context. It reads live Azure API specifications at generation time, so it stays current without manual module updates.

1. Factor in the GitHub Copilot dependency. Git-Ape runs on Copilot's infrastructure. Evaluate the per-developer licensing cost alongside the migration efficiency gains before committing to adoption.

Have questions about Git-Ape or cloud migration in general? Reach out on wenfeng.my or connect with me on LinkedIn.