.NET 8 e .NET 9 saem de suporte em 10/11: o que checar no código e por que o alvo agora é o .NET 10

.NET 8 e .NET 9 saem de suporte em 10/11: o que checar no código e por que o alvo agora é o .NET 10

Duas versões do .NET perdem suporte na mesma data: 10 de novembro de 2026. O .NET 8, que era a LTS de referência da maioria dos projetos corporativos, e o .NET 9, cuja janela de STS foi esticada para 24 meses — justamente para coincidir com o fim do 8. A partir de terça, nenhuma das duas recebe patch de segurança da Microsoft.

Para quem escreve código, o efeito não é imediato nem barulhento. O build continua passando, o deploy continua subindo, os testes continuam verdes. O problema aparece depois: uma falha no runtime, no ASP.NET Core ou no System.Text.Json fica sem correção oficial, e a decisão de aplicar um workaround passa a ser do seu time, não do fornecedor. Em ambientes com auditoria — e boa parte dos projetos brasileiros de médio porte tem —, "runtime sem patch" vira linha de relatório.

A complicação é de calendário: no mesmo 10 de novembro abre o .NET Conf 2026, com o .NET 11 e o C# 15. Então a pergunta que circula nas equipes é a errada. Não é "vamos direto para o 11?". É "para qual versão migramos agora e com qual cadência seguimos depois".

O que muda exatamente na data

.NET 8 (LTS) : ciclo normal de três anos encerrado em 10/11/2026.

.NET 9 (STS) : suporte estendido para 24 meses, encerrando no mesmo dia.

.NET 10 (LTS) : é a versão suportada até 14 de novembro de 2028, segundo a política oficial de suporte.

Plataformas gerenciadas seguem o mesmo relógio : o AWS Lambda deprecia os runtimes dotnet8 e dotnet9 nessa data, e o Azure Functions encerra o suporte a .NET 8, .NET 9 e PowerShell 7.4 também em 10/11.

O último item costuma ser o que dói de verdade. Um serviço em .NET 8 publicado em Lambda continua funcionando depois de 10/11, mas deixa de receber atualização de runtime na plataforma, e criar função nova com esse runtime fica bloqueado. O mesmo vale para Function App no plano de consumo.

Primeiro passo: descobrir o que realmente roda

Antes de tocar em qualquer .csproj , descubra o inventário real. E não confie no nome do repositório nem na memória de quem entrou no time depois.

O grep cobre a fonte. O runtime instalado cobre a máquina. Falta o elo mais escorregadio: o que está de fato rodando em produção. Tags de imagem como aspnet:8.0 apontam para um digest que muda com o tempo, e um serviço pode ter sido reconstruído com outro patch sem que ninguém note. Em Kubernetes, a tag do manifesto não diz qual runtime está no processo.

Um endpoint temporário de diagnóstico resolve a dúvida em segundos, inclusive em pods antigos:

Proteja a rota por política interna ou remova depois do levantamento — ela também informa versão de runtime para quem estiver sondando. Rode isso em todos os ambientes, não só em homologação.

Migrar para o .NET 10: o que realmente exige mudança

Para quem vem do .NET 8, a subida para o .NET 10 é das mais tranquilas da história recente do .NET. As mudanças de comportamento que mais assustam — novas configurações padrão de serialização, tratamento de DateOnly , limites de JsonSerializerOptions — já foram absorvidas nas versões 9 e 10 e estão documentadas no guia de compatibilidade do .NET 10.

Na prática, a alteração central é uma linha:

E o alinhamento do SDK, para que a máquina de build não resolva uma versão diferente da que o time combinou:

latestFeature mantém o major e o minor travados, aceitando apenas feature bands mais novas do 10.0.x. Evite latestMajor em repositório de produto: ele permite que uma máquina com .NET 11 compile o projeto sem que ninguém tenha decidido isso.

Nos containers, o ajuste é trocar as duas imagens base:

Aqui está o ponto em que times costumam escorregar: atualizar o Dockerfile no repositório não garante que o pipeline deixou de usar cache de camada antigo, nem que todos os serviços têm Dockerfile versionado. Se a imagem é construída por um template compartilhado, o ajuste precisa acontecer no template — e o inventário do passo anterior é o que mostra quais serviços escapam dele.

Vale lembrar que a migração não é só runtime. Pacotes NuGet com dependência de net8.0 no lib/ continuam resolvendo, mas analyzers, source generators e pacotes de instrumentação (OpenTelemetry, Serilog, drivers de banco) precisam de versões que declarem compatibilidade com net10.0 . Rode dotnet list package --outdated e trate os que estão parados há mais de um ano como risco, não como detalhe.

Em projetos que acompanhamos, a maior parte do esforço de uma migração como essa não está no código de aplicação: está em achar os pontos de contato com a plataforma — build, imagens, variáveis de runtime, extensões e políticas de CI. Na Maquinaweb, esse levantamento é feito antes da primeira alteração de TargetFramework , justamente porque a lista de serviços que ninguém lembra que existe costuma ser maior do que o backlog do trimestre.

Por que não pular direto para o .NET 11

O .NET 11 chega com o C# 15 e novidades relevantes: union types, Runtime Async fora de preview segundo o material de prévia do .NET Conf, suporte nativo a MCP no ASP.NET Core e um EF Core 11 com FullJoin e busca vetorial híbrida. É um release que interessa — e que também anuncia breaking changes no EF Core, que é onde migração dói de verdade em sistema com histórico.

Mas o .NET 11 é STS. Quem está correndo contra um runtime sem patch precisa de previsibilidade, não de estreia. A recomendação é pragmática:

Tudo que está e permanece em produção vai para .NET 10 LTS agora.

Serviços novos e times com cadência de atualização já estabelecida podem avaliar o .NET 11 em ambiente isolado, com data marcada para decidir.

Quem escolher STS precisa assumir o compromisso de migrar a cada dois anos. Sem essa disciplina, o problema volta em 2028 — com o mesmo aperto de hoje.

Riscos e armadilhas que passam batido

Trimming e AOT : se você usa Native AOT ou PublishTrimmed , valide de novo com o novo SDK. Mudanças de analyzer e de reflexão aparecem em runtime, não no build.

EF Core : se for pular de EF Core 8 para 11, o intervalo é grande. Atualize o EF Core em etapas e leia o guia de breaking changes antes de subir a versão do runtime.

Drivers e binários nativos : System.Data.SqlClient legado, bibliotecas de PDF, OCR e integrações com hardware são o elo que costuma quebrar em Linux sem aviso.

Runtimes gerenciados : alterar o framework do projeto não altera o runtime da função no Lambda ou no Function App. São duas configurações distintas.

Data de congelamento : se o time entra em freeze de fim de ano, migrar agora ou assumir formalmente o risco por escrito. As duas opções são válidas; a única inválida é não decidir.

Recomendação prática

Comece pelos serviços expostos: APIs públicas, autenticação, upload de arquivo e qualquer coisa que fale com terceiros. São eles que concentram impacto se um dia surgir falha no runtime. Depois, faça o inventário completo, alinhe o SDK via global.json , ajuste imagens e templates de pipeline, e rode a suíte de integração em .NET 10 antes de promover.

Se o seu time precisa de apoio para levantar o parque de aplicações, definir a ordem da migração ou desenhar a cadência de atualização daqui para frente, vale conversar com o time da Maquinaweb: trabalhamos com Python, Node.js, C#/.NET, Angular, TypeScript e bancos relacionais em projetos sob medida, e essa conversa de arquitetura e migração de stack costuma render mais do que um cronograma exportado de planilha.

Fontes