Migration | The .NET Blog

Removendo o Trabalho Repetitivo de Migração com Agentic Platform Engineering

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

Esta publicação foi traduzida automaticamente. Para a versão original, clique aqui.

Removing the Monkey Work of Migration with Agentic Platform Engineering — um passo a passo do Git-Ape (ferramenta git de engenharia de plataformas agêntica) migrando um repositório Terraform real da AWS para o Azure, com foco na extração de intenção em vez de conversão linha por linha.

A entrada: contoso-migration

A fonte é um projeto Terraform real (contoso-migration) que implanta um aplicativo Next.js na AWS — EC2 para computação, ALB para balanceamento de carga, S3 para artefatos e chaves IAM para identidade. Custo: ~$34/mês. O objetivo não é reproduzir a mesma infraestrutura no Azure; é descobrir o que o deployment está realmente tentando fazer e reconstruí-lo com serviços nativos do Azure.

Passo 1: Validação e autenticação

O Git-Ape começa validando todas as ferramentas CLI necessárias — az, aws, gh, jq, git — e confirmando as sessões de autenticação ativas antes de tocar em qualquer coisa. Sem execuções parciais.

Passo 2: Extração de intenção

O agente lê todo o repositório fonte pela API do GitHub e extrai a intenção do deployment: runtime (Node.js), tipo de computação, padrão de ingress, tratamento de artefatos, modelo de identidade, rede e monitoramento. Este é o passo-chave — está construindo um modelo semântico do que o deployment faz, não quais palavras-chave do Terraform ele usa.

Passo 3: Mapeamento de serviços

Os serviços AWS são mapeados para equivalentes do Azure:

EC2 → App Service (Linux, Node 20 LTS)
ALB → Balanceamento de carga integrado do App Service
Funções/chaves IAM → Managed Identity
Terraform → Bicep + GitHub Actions

Passo 4: Agente crítico

Antes de gerar a saída, um agente crítico é executado e detecta dois problemas bloqueantes:

Anti-padrão de build no startup — o Terraform original estava executando npm install && npm run build no EC2 na inicialização. Solução: construir no CI, implantar um artefato pronto.
Blob Storage desnecessário — o S3 era usado para staging de artefatos que poderia ser eliminado com CI/CD adequado. O agente crítico o removeu completamente.

Passo 5: Saída gerada

O resultado são ~80 linhas de Bicep em vez das 200+ linhas originais de Terraform. O agente criou um novo repositório GitHub com infra/main.bicep e .github/workflows/deploy.yml e removeu todos os arquivos específicos da AWS.

Comparação de postura de segurança

A migração também produziu uma melhoria significativa de segurança:

AWS original	Saída Azure
Somente HTTP	Somente HTTPS, TLS 1.2
SSH aberto para 0.0.0.0/0	Sem exposição SSH
Chaves de acesso IAM	OIDC + Managed Identity
Sem monitoramento	Application Insights

Custo: ~$13/mês vs os $34/mês originais.

O que o diferencia de um conversor de sintaxe

O passo do agente crítico é o que separa isso de uma tradução mecânica. Ele detectou padrões que teriam funcionado na AWS mas seriam incorretos no Azure — e os corrigiu em vez de replicá-los. A saída não é “AWS em sintaxe Azure”; é um deployment nativo do Azure que atinge o mesmo objetivo de forma mais limpa.

Veja o guia completo para o rastreamento completo do agente e arquivos gerados.

A avaliação de modernização do GitHub Copilot é a melhor ferramenta de migração que você ainda não está usando

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

Este post foi traduzido automaticamente. Para a versão original, clique aqui.

Migrar uma aplicação legada do .NET Framework para .NET moderno é uma daquelas tarefas que todo mundo sabe que deveria fazer, mas ninguém quer começar. Nunca é apenas “mudar o target framework.” São APIs que desapareceram, pacotes que não existem mais, modelos de hosting que funcionam de forma completamente diferente, e um milhão de pequenas decisões sobre o que containerizar, o que reescrever e o que deixar como está.

Jeffrey Fritz acabou de publicar um mergulho profundo na avaliação de modernização do GitHub Copilot, e honestamente? Este é o melhor tooling de migração que eu vi para .NET. Não pela geração de código — isso já é padrão agora. Pelo documento de avaliação que ele produz.

Não é apenas um motor de sugestões de código

A extensão do VS Code segue um modelo de Avaliar → Planejar → Executar. A fase de avaliação analisa todo o seu codebase e produz um documento estruturado que captura tudo: o que precisa mudar, quais recursos Azure provisionar, qual modelo de deploy usar. Tudo que vem depois — infraestrutura como código, containerização, manifestos de deploy — flui do que a avaliação encontra.

A avaliação é armazenada em .github/modernize/assessment/ no seu projeto. Cada execução produz um relatório independente, então você vai construindo um histórico e pode acompanhar como sua postura de migração evolui conforme corrige issues.

Duas formas de começar

Avaliação Recomendada — o caminho rápido. Escolha entre domínios curados (Upgrade Java/.NET, Cloud Readiness, Segurança) e obtenha resultados significativos sem mexer em configuração. Ótimo para um primeiro olhar de onde sua aplicação está.

Avaliação Personalizada — o caminho direcionado. Configure exatamente o que analisar: compute alvo (App Service, AKS, Container Apps), SO alvo, análise de containerização. Escolha múltiplos alvos Azure para comparar abordagens de migração lado a lado.

Essa visão de comparação é genuinamente útil. Uma app com 3 issues obrigatórios para App Service pode ter 7 para AKS. Ver ambos ajuda a tomar a decisão de hosting antes de se comprometer com um caminho de migração.

O detalhamento de issues é acionável

Cada issue vem com um nível de criticidade:

Obrigatório — deve ser corrigido ou a migração falha
Potencial — pode impactar a migração, precisa de julgamento humano
Opcional — melhorias recomendadas, não bloqueiam a migração

E cada issue linka para arquivos afetados e números de linha, fornece uma descrição detalhada do que está errado e por que importa para sua plataforma alvo, dá passos concretos de remediação (não apenas “corrija isso”), e inclui links para documentação oficial.

Você pode atribuir issues individuais a desenvolvedores e eles têm tudo que precisam para agir. Essa é a diferença entre uma ferramenta que diz “tem um problema” e uma que diz como resolver.

Os caminhos de upgrade cobertos

Para .NET especificamente:

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

Cada caminho de upgrade tem regras de detecção que sabem quais APIs foram removidas, quais padrões não têm equivalente direto, e quais issues de segurança precisam de atenção.

Para times que gerenciam múltiplas aplicações, também há um CLI que suporta avaliações batch multi-repo — clone todos os repos, avalie todos, obtenha relatórios por app mais uma visão agregada do portfólio.

Minha opinião

Se você está sentado em cima de aplicações legadas em .NET Framework (e vamos ser honestos, a maioria dos times enterprise está), esta é a ferramenta para começar. Só o documento de avaliação já vale o tempo — transforma um vago “deveríamos modernizar” em uma lista concreta e priorizada de itens de trabalho com caminhos claros adiante.

O fluxo de trabalho colaborativo também é inteligente: exporte avaliações, compartilhe com seu time, importe-as sem re-executar. Revisões de arquitetura onde quem toma decisões não é quem roda as ferramentas? Coberto.

Finalizando

A avaliação de modernização do GitHub Copilot transforma a migração .NET de um projeto assustador e indefinido em um processo estruturado e rastreável. Comece com uma avaliação recomendada para ver onde você está, depois use avaliações personalizadas para comparar alvos Azure e construir seu plano de migração.

Leia o walkthrough completo e baixe a extensão do VS Code para testar no seu próprio codebase.