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.

GitHub Copilot's Modernization Assessment Is the Best Migration Tool You're Not Using Yet

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

Migrating a legacy .NET Framework app to modern .NET is one of those tasks everyone knows they should do but nobody wants to start. It’s never just “change the target framework.” It’s APIs that disappeared, packages that don’t exist anymore, hosting models that work completely differently, and a million small decisions about what to containerize, what to rewrite, and what to leave alone.

Jeffrey Fritz just published a deep dive into GitHub Copilot’s modernization assessment, and honestly? This is the best migration tooling I’ve seen for .NET. Not because of the code generation — that’s table stakes now. Because of the assessment document it produces.

It’s not just a code suggestion engine

The VS Code extension follows an Assess → Plan → Execute model. The assessment phase analyzes your entire codebase and produces a structured document that captures everything: what needs to change, what Azure resources to provision, what deployment model to use. Everything downstream — infrastructure-as-code, containerization, deployment manifests — flows from what the assessment finds.

The assessment is stored under .github/modernize/assessment/ in your project. Each run produces an independent report, so you build up a history and can track how your migration posture evolves as you fix issues.

Two ways to start

Recommended Assessment — the fast path. Pick from curated domains (Java/.NET Upgrade, Cloud Readiness, Security) and get meaningful results without touching configuration. Great for a first look at where your app stands.

Custom Assessment — the targeted path. Configure exactly what to analyze: target compute (App Service, AKS, Container Apps), target OS, containerization analysis. Pick multiple Azure targets to compare migration approaches side-by-side.

That comparison view is genuinely useful. An app with 3 mandatory issues for App Service might have 7 for AKS. Seeing both helps drive the hosting decision before you commit to a migration path.

The issue breakdown is actionable

Each issue comes with a criticality level:

Mandatory — must fix or migration fails
Potential — might impact migration, needs human judgment
Optional — recommended improvements, won’t block migration

And each issue links to affected files and line numbers, provides a detailed description of what’s wrong and why it matters for your target platform, gives concrete remediation steps (not just “fix this”), and includes links to official documentation.

You can hand individual issues to developers and they have everything they need to act. That’s the difference between a tool that tells you “there’s a problem” and one that tells you how to solve it.

The upgrade paths covered

For .NET specifically:

.NET Framework → .NET 10
ASP.NET → ASP.NET Core

Each upgrade path has detection rules that know which APIs were removed, which patterns have no direct equivalent, and what security issues need attention.

For teams managing multiple apps, there’s also a CLI that supports multi-repo batch assessments — clone all repos, assess them all, get per-app reports plus an aggregated portfolio view.

My take

If you’re sitting on legacy .NET Framework apps (and let’s be real, most enterprise teams are), this is the tool to start with. The assessment document alone is worth the time — it turns a vague “we should modernize” into a concrete, prioritized list of work items with clear paths forward.

The collaborative workflow is smart too: export assessments, share with your team, import them without re-running. Architecture reviews where the decision-makers aren’t the ones running the tools? Covered.

Wrapping up

GitHub Copilot’s modernization assessment transforms .NET migration from a scary, undefined project into a structured, trackable process. Start with a recommended assessment to see where you stand, then use custom assessments to compare Azure targets and build your migration plan.

Read the full walkthrough and grab the VS Code extension to try it on your own codebase.

Migration | The .NET Blog