.NET 11 chegou. A pergunta certa é: em qual versão está o seu sistema?

Em 10/11/2026, a Microsoft lançou o .NET 11. A versão traz o C# 15, ganhos de desempenho no runtime e novidades no ASP.NET Core.

No mesmo dia, o .NET 8 e o .NET 9 perderam o suporte oficial. Desde então, essas versões não recebem patch de segurança nem correção de bug.

Esse é o cenário de versões lançadas em 2023 e 2024. Muitos sistemas rodam em versões bem mais antigas: .NET Framework 4.0, 4.5 ou VB6.

Este texto não trata das novidades do .NET 11. Ele trata de quem ficou para trás.

LTS e STS: o calendário que pouca gente lê

Desde o .NET 5, a Microsoft lança uma versão nova todo mês de novembro. Os tipos de suporte se alternam:

• LTS (Long Term Support): versões pares, como o .NET 8 e o .NET 10. Três anos de suporte.
• STS (Standard Term Support): versões ímpares, como o .NET 9 e o .NET 11. Dois anos de suporte. Até setembro de 2025, eram 18 meses.

Um detalhe que pouca gente conhece: estar no .NET 8 não bastava. A Microsoft só considera suportado o sistema que está no patch mais recente da versão. Um sistema parado num 8.0.x antigo já estava fora da política, com a versão ainda ativa.

Repare: o .NET 10 (LTS) e o .NET 11 (STS) terminam o suporte no mesmo dia, 14/11/2028.

E o .NET Framework? E o VB6?

O .NET Framework clássico segue outra regra:

Quem está no 4.0, no 4.5 ou no 4.5.1 está sem patch de segurança desde 12/01/2016. Quem está no 4.8.1 tem suporte, mas numa plataforma que não evolui mais. Ela não roda em Linux nem em container leve. E não recebe as novidades de linguagem, desempenho e IA do .NET moderno.

O VB6 é o caso mais curioso. O executável ainda roda, mas a ferramenta para mantê-lo perdeu o suporte em 08/04/2008. Cada correção depende de alguém que ainda saiba mexer nisso e que aceite mexer.

Atualizar só por atualizar? Não.

Trocar de versão só porque saiu uma nova é vaidade técnica. Ninguém deveria gastar dinheiro com isso. A pergunta certa é outra: o que a atualização resolve ou destrava para o negócio?

A resposta tem três camadas.

1. Segurança e conformidade: o mínimo

Versão sem suporte não recebe patch de segurança. Se uma falha aparecer amanhã, ela fica aberta. Para quem atende empresas maiores, isso aparece cedo ou tarde: num questionário de segurança, numa auditoria ou numa exigência ligada à LGPD.

2. Desempenho e custo: o meio

Cada versão do .NET moderno traz ganhos no runtime, na serialização JSON, na compressão e no uso de memória. Na prática, isso pode significar a mesma carga com menos servidor. Sair do .NET Framework também permite rodar em Linux e em containers, que costumam custar menos que Windows Server.

3. Produto e mercado: o que quase ninguém calcula

Essa é a camada que muda o jogo. Uma base moderna permite:

• Colocar IA no produto. A Microsoft mantém bibliotecas oficiais para integrar modelos de IA, o protocolo MCP e agentes no .NET moderno. Num sistema em .NET Framework 4.5 ou VB6, isso vira remendo ou projeto paralelo.
• Ir para web, celular e nuvem. ASP.NET Core, Blazor e .NET MAUI abrem canais que o legado não alcança.
• Vender para clientes maiores. Empresa grande pergunta a stack, o suporte e a política de atualização antes de assinar contrato. "Roda em VB6" encerra a conversa.
• Contratar gente. Quem desenvolve bem quer trabalhar com tecnologia atual. Quanto mais antigo o sistema, menor e mais caro fica o grupo de quem aceita mantê-lo.

Ficar parado não é custo zero. É custo adiado, e com juros.

Quando não vale a pena migrar

Em alguns casos, a melhor decisão é não mexer:

• O sistema está em fim de vida planejado, e a substituição já está contratada.
• A aplicação é isolada. Ela não fica exposta à internet e não guarda dado sensível. E já roda no .NET Framework 4.8.1, num Windows suportado.
• O custo de migrar é maior que o valor que o sistema ainda vai gerar.

Nesses casos, o caminho pode ser manter a versão suportada mais recente do .NET Framework e documentar o risco aceito. O que não dá é ficar parado sem ter tomado essa decisão de forma consciente.

LTS ou STS: para onde ir?

• Se o sistema vem de longe, como .NET Framework, .NET Core ou .NET 5 a 9, o destino natural é o .NET 10 (LTS). Ele tem suporte até 14/11/2028 e serve a quem atualiza a cada dois ou três anos.
• Se a empresa já tem esteira de atualização anual, testes automatizados e deploy contínuo, o .NET 11 (STS) faz sentido. Ele entrega as novidades mais cedo, com o mesmo prazo de suporte do .NET 10.
• Se o sistema está em VB6, não existe upgrade. É reescrita. E uma reescrita bem feita é a chance de redesenhar o produto, não de copiar tela por tela.

A boa notícia: a conversão ficou menos braçal. A Microsoft oferece o GitHub Copilot upgrade. A ferramenta avalia o sistema e monta um plano de atualização. Depois, ela executa parte da conversão do .NET Framework para o .NET 10, e o desenvolvedor revisa cada etapa. Não é mágica, mas reduz o trabalho manual de conversão.

Cinco perguntas para fazer hoje sobre o seu sistema

1. Em qual versão exata ele roda, incluindo o patch?
2. Quando a equipe aplicou a última atualização de segurança?
3. Quais clientes ou contratos exigem stack suportada?
4. Que funcionalidade você não consegue entregar hoje por causa da tecnologia: IA, app, API, integração?
5. Quanto custa, por mês, manter o legado como está: servidor, horas de correção, gente específica?

Se duas ou mais respostas incomodaram, vale uma Sessão de Diagnóstico.

Na CTGF

A CTGF faz esse diagnóstico: mede onde o sistema está, quanto custa ficar e o que a migração destrava em produto e mercado. Se a decisão for migrar, a CTGF conduz o projeto, inclusive nos casos mais difíceis, como VB6 e .NET Framework antigo. A primeira sessão é gratuita.

Para ver como a CTGF conduz esse tipo de projeto, veja a página Projetos especiais.

Na SYNS, a CTGF mantém o legado em operação enquanto constrói a plataforma nova. Leia o case SYNS.