O risco de não migrar do Web Forms para .NET 10

TL;DR

> > – Web Forms está em modo de manutenção — só recebe patches de segurança até 2029. > – Cada ano parado é feature nova que vira gambiarra em cima de ViewState e UpdatePanel. > – O custo do legado não é a migração: é o profissional sênior que vai embora e não volta. > – Suporte de hospedagem, containerização e modernização de auth/SSO fica mais caro a cada release. > – Microsoft, comunidade e ecossistema de pacotes já se movem para .NET 10 — o tempo está do lado de quem age agora.

~ 6 min de leitura · 907 palavras

1. Web Forms virou modo manutenção: a contagem regressiva começou

A Microsoft comunicou em 2023 e reiterou em 2025: ASP.NET Web Forms entrou em modo de manutenção. Isso significa, em termos práticos:

• Apenas patches de segurança enquanto o .NET Framework 4.8 existir.
• Sem novas APIs, sem novos controles, sem novas funcionalidades de runtime.
• Sem suporte oficial em .NET 5/6/7/8/9/10+. A migração não é só recomendada: é a única rota de evolução.

> Para um ERP interno de 2014, esse anúncio pode parecer ruído. Mas a planilha de risco vê diferente: o fornecedor do OS não vai te avisar quando uma correção crítica parar de existir.

A pergunta que o time precisa fazer em 2026 não é mais “se” migrar, e sim “quando” e “em quantos cortes“.

2. O custo invisível do “está funcionando, não mexer”

Dizer que Web Forms “está funcionando” é confundir estabilidade com sustentabilidade. Um sistema de 10 anos tem três custos invisíveis que crescem ano a ano:

• Custo de manutenção: cada dev novo contratado precisa aprender Web Forms + a sua implementação específica. Isso é 2-4 semanas de ramp-up que ninguém cobra no orçamento.
• Custo de oportunidade: features novas viram gambiarras em cima de ViewState e `UpdatePanel`. Você paga em três lugares: tempo de dev, performance degradada, débito técnico invisível.
• Custo de recrutamento: o pool de devs que aceitam trabalhar com Web Forms encolhe a cada formatura. O salário para mantê-los sobe.

> O “está funcionando” mede apenas o output. O custo real está no input: quantas horas-homam estão sendo queimadas para entregar o mesmo resultado de 5 anos atrás.

3. ViewState e UpdatePanel: o teto de performance que ninguém negocia

ViewState é o original sin do Web Forms: serializa o estado da página inteira em um campo hidden criptografado em Base64. Em 2026, com Single Page Applications e streaming de UI reativa, manter 50KB de ViewState por request é anacronismo técnico.

UpdatePanel foi a tentativa de simular AJAX sobre postback completo. Funciona, mas tem custo previsível: cada update é um postback, mesmo quando só 5% da tela muda. Em ERP com grids densos e master-detail, isso vira latência percebida de 800ms-2s.

> Pior: a otimização real não existe em Web Forms. Você pode tunar `EnablePartialRendering`, configurar `ViewStateMode`, comprimir response — mas o teto arquitetural é o mesmo. Em .NET 10 + Angular/Blazor/React, o teto é outro.

4. O vazamento de profissionais seniores

Este é o risco que mais derruba projetos na vida real, e que planilhas de risco nunca capturam: o time que sabe onde os corpos estão enterrados vai embora.

Em 2026, devs seniores com 8+ anos de Web Forms estão em dois grupos:

• Saindo do mercado (aposentadoria, transição de carreira).
• Migrando internamente para stacks modernas (eles também não querem mais manter Web Forms).

Quando o último especialista sai, o sistema fica órfão de conhecimento. As decisões de negócio tomadas em 2014, codificadas em `Page_Load` aninhados e `ViewState[“x”]` opaco, viram ruído arqueológico. O novo dev olha, não entende, e adiciona mais uma gambiarra em cima.

> A migração não é um projeto técnico — é um projeto de preservação do conhecimento do negócio. Cada ano adiado, mais contexto se perde junto com o time.

5. O ecossistema que está saindo de debaixo de você

Três vetores externos estão se movendo agora:

• Hosting: provedores de PaaS e Kubernetes-native não dão suporte oficial a Web Forms. IIS clássico funciona, mas está fora do roadmap de muitas equipes de infra.
• Auth/SSO: SAML, OIDC, MFA moderno, autenticação adaptativa — Web Forms não integra limpo. Você acaba implementando middlewares custom que ninguém audita.
• Pacotes e bibliotecas: novos SDKs de pagamento, gateways de IA, integrações fiscais — quase todos miram .NET 6+ ou .NET Standard 2.1+. Em Web Forms, você roda a versão legada ou faz shim manual.

> O custo de manter Web Forms em 2026 não cai: sobe geometricamente a cada ano, porque o ecossistema inteiro está migrando em volta.

6. Como vender a migração para a diretoria (sem falar de tecnologia)

Este post é técnico, mas a decisão é de negócio. Traduza os riscos acima em três números que CFO aceita:

• Custo anual de manutenção observado: horas extras, retrabalho, bugs recorrentes. Some.
• Custo de oportunidade: features adiadas por limitação técnica. Estime receita perdida.
• Custo de risco: o que acontece quando o especialista sai, ou quando uma CVE crítica surge sem patch. Modele o pior caso.

Apresente esses três números, sem jargão técnico. A pergunta do diretor não é “.NET 10 ou Web Forms” — é “qual é o risco de não agir?”. Quando você responde com números, a resposta vem em rubrica de projeto, não em ROI de cinco anos.

> O melhor momento para migrar foi em 2022. O segundo melhor momento é agora. O pior momento é depois que o especialista-chave pede demissão.

Leitura relacionada

• Web Forms 4.8 ou .NET 10: quando a migração deixa de ser opção? — fixa o critério de saída da decisão de migrar, evitando projeto que começa sem justificativa.
• Os maiores desafios da migração para .NET 10 saindo de Web Forms 4.8 — mapeia os obstáculos técnicos que aparecem nas primeiras sprints e como mitigá-los.
• O que melhora ao migrar do Web Forms para .NET 10 e Angular? — mostra o ganho de manutenibilidade e performance que justifica o investimento.