Removing the Monkey Work of Migration with Agentic Platform Engineering

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

Removing the Monkey Work of Migration with Agentic Platform Engineering — a walkthrough of Git-Ape (git agentic platform engineering tool) migrating a real AWS Terraform repo to Azure, focusing on intent extraction rather than line-by-line conversion.

The input: contoso-migration

The source is a real Terraform project (contoso-migration) that deploys a Next.js app on AWS — EC2 for compute, ALB for load balancing, S3 for artifacts, and IAM keys for identity. Cost: ~$34/month. The goal isn’t to reproduce the same infrastructure on Azure; it’s to figure out what the deployment is actually trying to do and rebuild that on Azure-native services.

Step 1: Validation and auth

Git-Ape starts by validating all required CLI tools — az, aws, gh, jq, git — and confirming active auth sessions before touching anything. No partial runs.

Step 2: Intent extraction

The agent reads the entire source repo through the GitHub API and extracts the deployment intent: runtime (Node.js), compute type, ingress pattern, artifact handling, identity model, networking, and monitoring. This is the key step — it’s building a semantic model of what the deployment does, not what Terraform keywords it uses.

Step 3: Service mapping

AWS services get mapped to Azure equivalents:

EC2 → App Service (Linux, Node 20 LTS)
ALB → App Service built-in load balancing
IAM roles/keys → Managed Identity
Terraform → Bicep + GitHub Actions

Step 4: Critique agent

Before generating output, a critique agent runs and catches two blocking issues:

Build-on-startup anti-pattern — the original Terraform was running npm install && npm run build on EC2 at startup. Fix: build in CI, deploy a ready artifact.
Unnecessary Blob Storage — S3 was used for artifact staging that could be eliminated with proper CI/CD. The critique agent dropped it entirely.

Step 5: Generated output

The result is ~80 lines of Bicep instead of the original 200+ lines of Terraform. The agent created a new GitHub repo with infra/main.bicep and .github/workflows/deploy.yml and removed all AWS-specific files.

Security posture comparison

The migration also produced a meaningful security upgrade:

AWS original	Azure output
HTTP only	HTTPS only, TLS 1.2
SSH open to 0.0.0.0/0	No SSH exposure
IAM access keys	OIDC + Managed Identity
No monitoring	Application Insights

Cost: ~$13/month vs the original $34/month.

What makes this different from a syntax converter

The critique agent step is what separates this from a mechanical translation. It caught patterns that would have worked on AWS but would be wrong on Azure — and fixed them instead of replicating them. The output isn’t “AWS in Azure syntax”; it’s an Azure-native deployment that achieves the same goal more cleanly.

See the full walkthrough for the complete agent trace and generated files.

Agentic Platform Engineering Is Getting Real — Git-APE Shows How

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

Platform engineering has been one of those terms that sounds great in conference talks but usually means “we built an internal portal and a Terraform wrapper.” The real promise — self-service infrastructure that’s actually safe, governed, and fast — has always been a few steps away.

The Azure team just published Part 2 of their agentic platform engineering series, and this one is all about the hands-on implementation. They call it Git-APE (yes, the acronym is intentional), and it’s an open-source project that uses GitHub Copilot agents plus Azure MCP servers to turn natural-language requests into validated, deployed infrastructure.

What Git-APE actually does

The core idea: instead of developers learning Terraform modules, navigating portal UIs, or filing tickets to a platform team, they talk to a Copilot agent. The agent interprets the intent, generates Infrastructure-as-Code, validates it against policies, and deploys — all within VS Code.

Here’s the setup:

git clone https://github.com/Azure/git-ape
cd git-ape

Open the workspace in VS Code, and the agent configuration files are auto-discovered by GitHub Copilot. You interact with the agent directly:

@git-ape deploy a function app with storage in West Europe

The agent uses Azure MCP Server under the hood to interact with Azure services. The MCP configuration in VS Code settings enables specific capabilities:

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

Why this matters

For those of us building on Azure, this shifts the platform engineering conversation from “how do we build a portal” to “how do we describe our guardrails as APIs.” When your platform’s interface is an AI agent, the quality of your constraints and policies becomes the product.

The Part 1 blog laid out the theory: well-described APIs, control schemas, and explicit guardrails make platforms agent-ready. Part 2 proves it works by shipping actual tooling. The agent doesn’t just blindly generate resources — it validates against best practices, respects naming conventions, and applies your organization’s policies.

Clean-up is just as easy:

@git-ape destroy my-resource-group

My take

I’ll be honest — this one is more about the pattern than the specific tool. Git-APE itself is a demo/reference architecture. But the underlying idea — agents as the interface to your platform, MCP as the protocol, GitHub Copilot as the host — is where enterprise developer experience is heading.

If you’re a platform team looking at how to make your internal tooling agent-friendly, there’s no better starting point. And if you’re a .NET developer wondering how this connects to your world: the Azure MCP Server and GitHub Copilot agents work with any Azure workload. Your ASP.NET Core API, your .NET Aspire stack, your containerized microservices — all of it can be the target of an agentic deployment flow.

Wrapping up

Git-APE is an early but concrete look at agentic platform engineering in practice. Clone the repo, try the demo, and start thinking about how your platform’s APIs and policies would need to look for an agent to safely use them.

Read the full post for the walkthrough and video demos.

Platform Engineering | The .NET Blog