Migrar de Web Forms para .NET 10: dificuldades, riscos e benefícios

TL;DR

A migração de Web Forms para .NET 10 de um ERP que roda em produção não é uma troca de tecnologia: é um projeto de arquitetura, regras de negócio, banco de dados e testes. Eu passei por isso no Posseidom e o que aprendi mudou a forma como eu planejo qualquer modernização.

• Migrar Web Forms para .NET 10 exige reaproveitar regras de negócio, não telas
• Não existe caminho de migração automática: ViewStates, code-behind e postbacks não têm equivalente direto
• A pergunta certa não é “quanto custa migrar”, mas “quanto custa não migrar”

Por que Web Forms chegou ao fim da linha

Eu mantenho sistemas em Web Forms há mais de quinze anos e conheço cada atalho que essa plataforma ofereceu. Ela nasceu para aproximar o desenvolvimento web do Visual Basic: arrastar controle, dar duplo clique, escrever o handler. Isso foi genial em 2002 e é exatamente o que a mata hoje.

O ViewState carrega o estado de toda a página entre postbacks. Em uma tela de pedido com grid grande, já vi o payload passar de 1 MB para cada clique do usuário. O ciclo de vida da página — Init, Load, ViewState, eventos — é uma máquina de estados implícita que nenhum novo desenvolvedor domina em menos de um ano. E o modelo code-behind mistura apresentação, lógica e acesso a dados na mesma classe, o que torna cada tela um ponto cego para teste.

No Posseidom, quando paramos para medir, tínhamos telas de 4.000 linhas de code-behind. Nenhuma delas tinha um único teste automatizado. Não por descuido: a arquitetura simplesmente não permite testar o que ela mesma cria.

.NET Framework e .NET 10 são plataformas diferentes

Aqui está o ponto que mais confunde gestores: migrar de Web Forms para .NET 10 não é atualizar versão. .NET Framework 4.8 é a plataforma final de uma linhagem que a Microsoft congelou — ela recebe manutenção de segurança, mas nada de novidade. O .NET 10 é o .NET “moderno”: multiplataforma, open source, com performance de servidor muito superior e releases anuais.

As diferenças práticas que eu sinto no dia a dia:

• O .NET 10 roda em Linux, o que derruba custo de licença de servidor e abre caminho para contêineres
• A performance de runtime e de coleta de lixo é outra categoria — endpoints que antes exigiam hardware dobrado respondem com folga
• O ecossistema moderno (ASP.NET Core, minimal APIs, DI nativa, logging estruturado) simplesmente não existe para o Framework
• O suporte e o mercado de profissionais acompanham o .NET moderno; o Framework virou tema de legado

O detalhe crítico: Web Forms não existe no .NET moderno e nunca vai existir. Não é uma questão de roadmap — é o modelo de página inteiro que não sobrevive ao novo pipeline de requisição. Por isso a migração de Web Forms para .NET 10 é uma reescrita de apresentação com reaproveitamento de núcleo, e não um upgrade.

O papel do Angular na nova arquitetura

Quando eu comecei a modernizar o Posseidom, a decisão mais importante não foi sobre C#. Foi sobre onde a tela passa a viver.

No modelo Web Forms, o servidor monta o HTML e o navegador é praticamente um terminal burro. No modelo que adotamos, o back-end em .NET 10 expõe APIs REST e o front-end em Angular consome essas APIs. A tela vira uma aplicação de verdade, com componentes, roteamento e estado próprios.

Esse desenho resolve três problemas de uma vez:

• As regras de negócio migram para camadas de serviço no back-end, longe da tela
• A mesma API serve web, mobile e integrações de cliente — no ERP, usamos os endpoints para tudo
• A experiência do usuário muda de patamar: telas de cadastro que exigiam três postbacks passam a reagir sem recarregar página

Eu não defendo Angular por moda. Defendo porque a separação API + SPA é a única que permite migrar o ERP tela por tela sem big bang — e porque o mercado de front-end está todo consolidado nele, com componentes prontos para grid, upload e formulário que no Web Forms exigiriam controle pago.

O que dá para reaproveitar — e onde mora o trabalho real

A boa notícia que eu dou a todo cliente: o ativo mais valioso do seu sistema não são as telas, são as regras de negócio. E a maior parte delas pode migrar.

No Posseidom, cerca de 80% da lógica de cálculo, validação e acesso a dados estava em classes utilitárias e em consultas SQL separadas do code-behind. Essa parte atravessou a migração de Web Forms para .NET 10 com ajustes de namespace, troca de `ConfigurationManager` por `IConfiguration` e modernização de conexão — trabalho mecânico, previsível, testável.

O trabalho real está nos 20% que vivem escondidos:

• Regras de negócio enterradas no code-behind junto com manipulação de controle
• Validações que dependem do ciclo de vida da página
• Lógica espalhada em `Page_Load`, `RowDataBound` e manipuladores de evento
• Session state usado como variável global entre telas

Esses 20% não migram: são redescobertos. Cada uma dessas regras precisa ser extraída, nomeada, testada e movida para uma camada de serviço. É aqui que a migração vira um projeto de arquitetura — e é aqui que quase todo orçamento estoura, porque ninguém sabe que a regra existe até ela quebrar.

Compatibilidade: onde a migração costuma travar

Os problemas de compatibilidade que eu enfrentei se agrupam em três famílias.

A primeira é biblioteca de terceiros. Todo ERP maduro carrega controles pagos de grid, relatório e upload que só existem para o Framework. Alguns têm equivalente moderno, outros precisam ser substituídos por componente aberto ou por solução própria — cada substituição é uma mini-projeto de estimativa própria.

A segunda é o próprio C#. O compilador do .NET 10 é mais rígido com código antigo. `System.Web` inteiro não existe, obviamente, mas também somem `AppDomain`, partes de `ConfigurationManager`, APIs de remoting e padrões de `BinaryFormatter` que ainda estavam vivos no Posseidom sem ninguém saber.

A terceira, e a mais traiçoeira, é o banco de dados. Muitos sistemas legados dependem de comportamento implícito do driver antigo, de pool de conexão configurado no `web.config` ou de autenticação Windows acoplada ao IIS. O caminho mais seguro que encontrei foi manter o banco intocado na primeira fase e trocar a camada de acesso gradualmente — mudar schema e aplicação ao mesmo tempo dobra o risco sem ganhar velocidade.

Quanto custa migrar — e como eu responderia essa pergunta

Eu aprendi a responder a pergunta de custo com outra pergunta: migrar o quê, para qual prazo, com qual equipe?

Uma migração de Web Forms para .NET 10 tem custo em três eixos. O primeiro é gente: a equipe precisa aprender ASP.NET Core, APIs e o front-end escolhido — treinamento real, com projeto-piloto, não um curso de fim de semana. O segundo é tempo paralelo: o sistema legado continua recebendo demanda de negócio enquanto é migrado, e cada melhoria no legado é custo que não se reaproveita. O terceiro é risco de regressão: funcionalidade que migra errada só aparece quando o cliente usa, meses depois.

O que eu recomendo, e o que fiz no Posseidom, é migração gradual: uma tela ou módulo por vez, rodando os dois sistemas em paralelo, com a regra de que nada novo entra no legado. O custo total é parecido com o big bang, mas o risco dilui — e a equipe aprende no módulo 2 o que errou no módulo 1.

Migrar tudo de uma vez só faz sentido quando o fornecedor abandona a plataforma, quando a segurança obriga ou quando o contrato de suporte vence. Fora isso, gradual ganha sempre.

O risco de ficar parado

O risco de continuar no Web Forms não é o sistema parar de funcionar hoje. É o custo composto de ficar.

Segurança é o primeiro eixo: o Framework 4.8 ainda recebe patches, mas o ecossistema em volta — controles pagos, drivers, bibliotecas — não recebe mais, e cada dependência abandonada vira porta de entrada. O segundo eixo é mercado: desenvolvedor que domina a stack moderna não quer sustentar legado, e a equipe que resta envelhece junto com o código. O terceiro é negócio: cada integração nova, mobile, API para cliente ou automação custa três vezes mais no modelo antigo.

Eu vi o momento em que esse custo fica maior que a migração inteira — e a empresa descobre isso tarde, sem orçamento e sem prazo. A decisão de migrar de Web Forms para .NET 10 feita com dois anos de folga é um projeto; feita em pânico é um resgate.

Conclusão

A migração de Web Forms para .NET 10 é menos sobre C# e mais sobre decisões de arquitetura: separar regra de negócio de tela, expor API e escolher um front-end que dure. O que reaproveitar (a lógica), o que reescrever (a apresentação) e em que ritmo (gradual, quase sempre) são as três escolhas que definem o resultado. No Posseidom, a modernização do ERP virou exemplo interno de como transformar legado em vantagem — sem big bang, sem parar a operação e sem perder uma regra de negócio no caminho.

Leitura relacionada

• Desafios da migração de Web Forms 4.8 para .NET 10 — os obstáculos técnicos que ninguém lista no orçamento antes de começar
• Riscos de não migrar do .NET Framework — o custo de ficar parado contado em segurança, mercado e negócio
• Vantagens do .NET 10 com Angular — o que efetivamente melhora em desempenho, manutenção e experiência após a troca de arquitetura