Migração de .NET Framework para .NET moderno.

A migração de .NET Framework é o caso mais traiçoeiro entre os sistemas legados, justamente porque não parece legado. A linguagem continua sendo C# (ou VB.NET), o Visual Studio abre o projeto, a equipe ainda sabe mexer. Mas o sistema está preso a uma plataforma que parou de evoluir, e cada ano que passa a distância até o .NET atual aumenta. É um capítulo específico da migração de sistemas legados, com ferramentas próprias e armadilhas próprias.

Por que sair do .NET Framework

O .NET Framework 4.8.x é a última versão do Framework. A Microsoft continua publicando correções de segurança para ele, junto com o Windows, então ninguém vai acordar com o sistema fora do ar. O que acabou foi a evolução: todo recurso novo de linguagem, de desempenho e de plataforma acontece no .NET moderno, a linha que começou no .NET Core e seguiu como .NET 5, 6, 7, 8, 9 e .NET 10, versão LTS lançada em novembro de 2025.

Na prática, ficar no Framework significa:

• Preso ao Windows e ao IIS. Não roda em Linux nem em containers Linux, o que encarece servidor e nuvem e dificulta qualquer automação moderna de implantação.
• Sem novidades. As versões novas do C#, as melhorias de desempenho do runtime e as bibliotecas atuais miram o .NET moderno. Aos poucos, pacotes NuGet deixam de publicar versões compatíveis com o Framework.
• Componentes parados. Controles de terceiros, geradores de relatório e SDKs de integração costumam ter versões novas só para o .NET atual; a versão antiga que o sistema usa fica sem correção.
• Contratação mais difícil. Quem está entrando no mercado aprende ASP.NET Core, não WebForms nem WCF.

Nada disso exige pânico. Exige plano, porque a conta de esperar cresce em silêncio.

O que migra com facilidade

Boa parte de uma aplicação .NET Framework passa para o .NET moderno com ajuste, não com reescrita. É aqui que um sistema bem dividido em camadas colhe o que plantou.

• Bibliotecas de classes e regra de negócio. Cálculos, validações, entidades e serviços que não dependem de System.Web costumam compilar no .NET 10 com pouca mudança. Um passo intermediário útil é deixá-las compatíveis com as duas plataformas ao mesmo tempo, para que o sistema antigo e o novo usem o mesmo código durante a transição.
• ASP.NET MVC e Web API. Controllers, rotas e views Razor têm equivalente direto no ASP.NET Core. Muda a infraestrutura em volta: Global.asax vira o Program.cs, o web.config vira appsettings.json, filtros e módulos HTTP viram middleware, e a injeção de dependência passa a ser nativa.
• Acesso a dados. O Entity Framework 6 tem suporte ao .NET moderno, o que permite migrar a aplicação primeiro e o acesso a dados depois. A troca para o EF Core pode vir numa etapa seguinte, com calma. ADO.NET e Dapper atravessam praticamente sem mudança.
• WinForms e WPF. Existem no .NET moderno, só no Windows. A migração mantém a interface e ganha um runtime suportado; o trabalho costuma estar nos controles de terceiros, que precisam de versão compatível.

O que exige reconstrução

Algumas tecnologias do .NET Framework simplesmente não existem no .NET moderno. Não há conversão possível: há uma decisão de para onde levar cada uma.

O WebForms merece atenção especial. Em muitos sistemas, a regra de negócio mora no code-behind: o cálculo do pedido está dentro do btnSalvar_Click, a consulta ao banco está no Page_Load. Antes de pensar na tela nova, essa regra precisa ser tirada dali, entendida e documentada. Quem pula essa etapa reconstrói a tela e descobre, em produção, a regra que ficou para trás.

Ferramentas oficiais: apoio, não solução

A Microsoft oferece o .NET Upgrade Assistant, que converte o formato dos projetos, atualiza referências de pacotes, ajusta namespaces e aponta APIs incompatíveis. Em bibliotecas de classes e em projetos MVC simples, ele economiza dias de trabalho braçal, e nós usamos.

Mas é preciso saber o que ele não faz. Não reconstrói WebForms, não transforma um serviço WCF em API, não separa regra de tela e não escolhe arquitetura. O resultado de "rodar a ferramenta e corrigir até compilar" é um sistema que compila no .NET 10 com os mesmos problemas de antes. É o mesmo raciocínio que vale para qualquer conversor automático de código legado: útil como ferramenta pontual, perigoso como estratégia.

O método: entender, documentar, só então codificar

A NasteSoft e seus parceiros já migraram bancos de dados e aplicações em Delphi, VB6 e .NET, e o que aprendemos é que a parte cara de uma migração nunca é a sintaxe. É o que ninguém lembra que o sistema faz.

1. Entender. Lemos o código, o banco, as telas em uso e os logs, e conversamos com quem opera. Mapeamos dependências: quais projetos usam System.Web, onde há WCF, quais componentes de terceiros não têm versão atual. IA ajuda a ler mais rápido; quem valida é gente que conhece o processo.
2. Documentar. Regras de negócio, fluxos, cálculos, integrações e dados ficam registrados. Esse documento fica com você e vale mesmo que a tecnologia de destino mude daqui a cinco anos.
3. Codificar. Só aí escrevemos o sistema novo, já na arquitetura certa: regra separada da interface, APIs bem definidas, testes automatizados nos fluxos críticos.

Migração incremental, com o sistema antigo no ar

Em aplicações web, o padrão de estrangulamento tem ferramentas prontas no próprio ecossistema .NET. Um proxy reverso, como o YARP (projeto de código aberto da Microsoft), fica na frente do sistema: as rotas já migradas vão para a nova aplicação ASP.NET Core e todo o resto continua sendo atendido pela aplicação antiga. O usuário não percebe a fronteira.

Os System.Web adapters, também da Microsoft, resolvem o ponto que costuma travar essa convivência: permitem que as duas aplicações compartilhem sessão e autenticação durante a transição, e que parte do código que dependia de System.Web rode no ASP.NET Core sem ser reescrita de uma vez.

Com isso, cada etapa é pequena e reversível. Uma área migra, roda em paralelo, tem o resultado comparado com o antigo e só então assume. Se algo der errado, a rota volta. Não existe a madrugada da grande virada.

Para onde: .NET 10, Linux e o que vem depois

Para um projeto que começa hoje, o alvo é o .NET 10. O .NET 8 também é LTS, mas seu suporte termina em novembro de 2026; mirar nele agora significa outra atualização logo em seguida. Já no .NET moderno, subir de uma versão LTS para a próxima é trabalho de dias ou semanas, não um projeto.

Sair do Framework também abre portas que estavam fechadas: rodar em Linux e em containers, publicar com pipelines automáticos, expor o sistema por APIs para aplicativos e parceiros. Muitos clientes descobrem que a migração é o que finalmente permite levar o sistema para um aplicativo Android e iOS ou integrar com o que a operação precisa.

E o banco de dados?

Em muitos projetos .NET Framework o banco é um SQL Server antigo, às vezes já fora de suporte, com regras importantes escondidas em stored procedures e triggers. A aplicação pode migrar mantendo o banco, e frequentemente é o melhor primeiro passo. Quando o banco também precisa mudar de versão ou de produto, tratamos como frente própria, com ensaios e conferência automática. Veja como funciona a nossa migração de banco de dados.

O que fica com você

• Sistema no .NET 10, entregue por partes e validado em produção a cada etapa.
• Regras de negócio documentadas, inclusive as que estavam no code-behind e nas procedures.
• APIs no lugar de WCF e Remoting, prontas para integrar com o que vier.
• Testes automatizados nos fluxos críticos.
• Implantação automatizada, em Windows ou Linux, no servidor ou na nuvem.

Perguntas frequentes