Como funciona a modernização .NET com o Copilot Upgrade Agent

A Microsoft publicou um curso gratuito chamado .NET Modernization for Beginners, junto com uma seção de documentação completa para o Copilot modernization agent em torno do qual ele foi construído. Os dois são material genuinamente bom, e modernização recebe muito menos cobertura do que começar algo novo.

Por que modernização é um assunto de verdade

A maior parte do conteúdo sobre .NET parte de uma pasta vazia. Escolhe a versão mais recente, escolhe seus patterns, vai. Essa é a parte divertida, e é uma fração do trabalho real na indústria.

Uma quantidade grande de .NET em produção roda em .NET Framework, escrito anos atrás por pessoas tomando decisões razoáveis para o tooling da época. Essas aplicações ainda precisam de manutenção, e eventualmente precisam ser movidas, por causa de support lifecycles, security patching, performance, cloud hosting, ou simplesmente para continuar conseguindo contratar gente que quer trabalhar nelas.

Fazer upgrade de uma aplicação real é mais difícil do que começar uma nova, porque a versão do framework nunca é a parte difícil. A parte difícil é a dúzia de coisas que silenciosamente dependiam do comportamento antigo.

O workflow: assess, plan, execute

Toda a abordagem é construída em três estágios, nessa ordem, e a ordem é a ideia útil.

Assessment examina estrutura do projeto, dependencies e code patterns, depois reporta breaking changes, problemas de compatibilidade de API, patterns deprecated e o escopo do trabalho.

Planning transforma esse assessment mais suas decisões confirmadas numa especificação: estratégia de upgrade, abordagem de refactoring, dependency paths, mitigações de risco.

Execution divide o plano em tasks concretas e sequenciais, cada uma com critérios de validação, então toda mudança tem uma definição de "isso funcionou".

O ponto de separar isso é que um assessment report é uma ferramenta de decisão, não um output para passar os olhos rapidamente. Ler e decidir o que é realmente arriscado é a habilidade. As edições mecânicas são a metade fácil.

O que o curso cobre

Cinco capítulos seguindo esse formato:

• 00 introdução e o workflow geral
• 01 assessment, rodando análise de compatibilidade contra um app legacy
• 02 planning, transformando descobertas numa estratégia priorizada
• 03 execution, a migração em si
• 04 deploy da aplicação modernizada no Azure

Funciona numa aplicação de exemplo chamada BookCatalog: um app ASP.NET MVC 5 legacy em .NET Framework 4.8, levado até .NET 10. Usar um codebase real com decisões acumuladas importa, porque um exemplo de brinquedo limpo não produziria os problemas de compatibilidade que fazem o estágio de assessment valer a pena aprender, para começo de conversa.

Os pré-requisitos para seguir como está escrito são Windows 11, Visual Studio 2026, uma assinatura do GitHub Copilot, e os SDKs de .NET Framework 4.8 e .NET 10.

O que o agent trata

O modernization agent roda no Visual Studio, VS Code, no GitHub Copilot CLI, e no GitHub.com. Você aponta ele para uma solution e descreve o que quer:

Upgrade my solution to .NET 10
Convert to SDK-style
Upgrade from Newtonsoft.Json
Migrate my Web Forms app to Blazor

Os upgrade paths suportados cobrem mais do que só pular para a versão mais nova:

Além dos upgrades de versão, existem cenários direcionados para migrações específicas: Newtonsoft.Json para System.Text.Json, System.Data.SqlClient para Microsoft.Data.SqlClient, Azure Functions do modelo in-process para o modelo isolated worker, Web Forms para Blazor, e adicionar suporte a Aspire.

Os tipos de projeto cobertos incluem ASP.NET Core com MVC, Razor Pages e Web API, Web Forms, Blazor, Azure Functions, WPF, Windows Forms, WinUI, MAUI e Xamarin, class libraries, console apps, e test projects em MSTest, NUnit ou xUnit.

O detalhe de design que vale a pena notar

O agent escreve seu trabalho em disco como Markdown, em .github/upgrades/{scenarioId}:

assessment.md            analysis of the solution
upgrade-options.md       confirmed upgrade decisions
plan.md                  ordered task plan
tasks.md                 live progress dashboard
scenario-instructions.md persistent memory, preferences and decisions

Esses arquivos são editáveis antes de você deixar ele continuar. É isso que torna isso uma ferramenta em vez de um botão mágico: se o assessment leu algo errado, você corrige o Markdown e o plano segue a partir da sua correção.

Como todo o estado vive naquela pasta, o processo sobrevive a fechar a IDE, e pode até ser continuado num editor diferente daquele em que começou. Ele commita conforme avança, então reverter um passo ruim é uma operação de git comum em vez de um undo que você espera que funcione.

Estratégias e controle de fluxo

Durante o assessment o agent recomenda uma de três estratégias, e qual delas se encaixa depende do formato da solution:

• Bottom-up atualiza os leaf projects primeiro e vai subindo, para solutions grandes com dependency graphs profundos
• Top-down atualiza o projeto da aplicação primeiro e depois corrige as dependencies, para feedback rápido no app principal
• All-at-once faz tudo numa passada só, para solutions pequenas

Também existem dois flow modes. Automatic passa por todos os estágios e para só em bloqueadores genuínos. Guided pausa em cada limite de estágio para você revisar o assessment, o plano e as tasks antes de prosseguir. Você alterna entre eles no meio da execução dizendo "pause" ou "continue".

Por que vale a pena saber isso

Upgrades de versão são a parte visível da modernização e a menor parte. O que esse material realmente ensina é o processo em volta: que um assessment produz um documento com o qual você deve discutir, que a estratégia depende do dependency graph em vez de preferência, e que o trabalho deve ser commitado incrementalmente para que qualquer passo possa ser desfeito.

Esse conhecimento se aplica quer você use o Copilot agent para fazer o trabalho ou não, e é o tipo de coisa muito melhor de ter lido antes de virar urgente do que durante a semana em que ela vira.