Il 10 novembre 2026 termina il supporto Microsoft per .NET 8 e .NET 9. Le applicazioni non smetteranno di funzionare l'11 novembre, ma quelle che rimangono su queste versioni non riceveranno più gli aggiornamenti di sicurezza ordinari previsti dal ciclo di supporto. Per sistemi aziendali in produzione, questo significa dover pianificare una migrazione, non semplicemente cambiare una versione nel file di progetto.
1. Cosa succede dopo il 10 novembre 2026?
Per .NET 8 e .NET 9 la fine del ciclo di supporto riguarda runtime, SDK e componenti dell'ecosistema soggetti alla relativa policy Microsoft, compresi ASP.NET Core ed Entity Framework Core. Il software già distribuito continua a essere eseguibile, ma non si può contare sulla disponibilità di nuove patch di sicurezza per le versioni non più supportate.
- .NET 8: versione LTS; fine supporto il 10 novembre 2026.
- .NET 9: versione STS; fine supporto il 10 novembre 2026.
- .NET 10: versione LTS; supporto fino al 14 novembre 2028.
La data non implica automaticamente un'interruzione del servizio, ma lasciare un'applicazione esposta su un runtime fuori supporto aumenta il rischio nel tempo. È importante distinguere questa situazione da un'emergenza operativa immediata: il rischio va valutato in funzione dell'esposizione, dei dati e delle compensazioni disponibili.
2. Quali applicazioni devono essere censite?
Non considerare solo il sito principale. In molte soluzioni aziendali il runtime è usato anche da Web API ASP.NET Core, worker service, Windows service, job schedulati, applicazioni desktop, microservizi e processi batch. Controlla inoltre le immagini Docker, i runtime installati sui server, i job CI/CD e gli strumenti usati per le migrazioni di database.
Per un primo inventario puoi eseguire questi comandi sulle macchine o negli ambienti interessati:
dotnet --list-sdks
dotnet --list-runtimes
dotnet --infoNel repository cerca anche TargetFramework, TargetFrameworks, global.json, Directory.Packages.props, Dockerfile e configurazioni delle pipeline. Un progetto compilato con SDK 10 può ancora avere come target net8.0: SDK installato e runtime richiesto dall'applicazione sono concetti diversi.
3. Migrare da .NET 8 a .NET 10 richiede un passaggio intermedio su .NET 9?
No, non è necessario rilasciare prima una versione su .NET 9. Si può pianificare direttamente il passaggio a net10.0. Occorre però leggere anche le note di compatibilità delle versioni intermedie: saltare un rilascio applicativo non significa saltare i cambiamenti introdotti dal framework.
Per applicazioni ASP.NET Core, Microsoft pubblica guide di migrazione e liste di breaking changes. Nei progetti con numerose dipendenze conviene analizzare il percorso completo, non assumere che una compilazione riuscita garantisca la compatibilità funzionale.
4. Procedura pratica: migrare un'applicazione ASP.NET Core
Passo 1 — Crea una baseline verificabile
Prima di aggiornare, registra versione del framework, dipendenze, risultato dei test, stato delle pipeline, tempi di risposta ed errori applicativi più frequenti. Lavora su un branch dedicato e definisci come tornare alla release precedente se il rollout non va come previsto.
Passo 2 — Installa SDK 10 e aggiorna i target
Installa una versione supportata dell'SDK .NET 10 nell'ambiente di sviluppo e nella pipeline. Aggiorna i .csproj interessati:
<PropertyGroup>
<TargetFramework>net10.0</TargetFramework>
</PropertyGroup>Se la soluzione usa global.json, allinea la versione dell'SDK a una release 10.0 installata negli ambienti coinvolti. Verifica inoltre che IDE, build agent e task della pipeline supportino effettivamente .NET 10.
Passo 3 — Aggiorna NuGet e dipendenze collegate
Allinea i pacchetti Microsoft che devono seguire il major version del framework, in particolare le dipendenze ASP.NET Core ed EF Core eventualmente presenti. Per pacchetti di terze parti, controlla supporto dichiarato, changelog e versioni compatibili; non aggiornare indiscriminatamente tutto senza una valutazione.
dotnet restore
dotnet list package --outdated
dotnet build --configuration ReleaseNei progetti che usano EF Core, valida mapping, provider del database, query SQL generate, migrazioni, transazioni e concorrenza. Aggiornare il package del provider non significa necessariamente dover introdurre modifiche allo schema del database.
Passo 4 — Leggi e verifica le breaking changes
Controlla le note ufficiali di .NET 9 e .NET 10, oltre a quelle specifiche di ASP.NET Core ed EF Core. Presta particolare attenzione ai cambiamenti di comportamento: alcuni non producono errori di compilazione e si manifestano solo durante una richiesta HTTP, una serializzazione o un flusso di autenticazione.
Fra gli esempi documentati per ASP.NET Core 10 ci sono modifiche al comportamento dei redirect del login per endpoint API riconosciuti e nuove deprecazioni. Sono esempi da verificare se pertinenti al progetto, non problemi che si verificano necessariamente su ogni applicazione.
Passo 5 — Aggiorna hosting, container e deployment
Se il servizio è framework-dependent, accertati che il runtime .NET 10 sia presente sul server o nell'immagine di esecuzione. Per IIS verifica il supporto del relativo ASP.NET Core Hosting Bundle. Per Docker aggiorna sia l'immagine SDK usata nella build sia l'immagine runtime o aspnet utilizzata in produzione. Rivedi anche i controlli di health, la configurazione reverse proxy e gli eventuali vincoli di piattaforma.
Passo 6 — Testa i contratti, non solo la compilazione
- Test automatici unitari, integrazione ed end-to-end sui flussi più importanti.
- Autenticazione, autorizzazione e cookie/JWT, incluse le risposte 401 e 403.
- API pubbliche: shape JSON, status code, validazione, paginazione, gestione errori.
- Operazioni sul database: query critiche, transazioni, migrazioni e performance.
- Worker, code, job pianificati, chiamate SMTP/HTTP e gestione dei retry.
- Logging, metriche, health check e osservabilità dopo il deploy.
Effettua prima un rilascio in staging con configurazione il più possibile simile alla produzione. Dove è disponibile, utilizza rollout graduali e prepara una procedura di rollback realmente eseguibile.
5. Quanto è complessa la migrazione?
Dipende meno dal numero di righe di codice e più dalle dipendenze e dai vincoli di esercizio. Una API con pochi package, test adeguati e deploy automatizzato può richiedere un intervento contenuto. Una soluzione composta da più applicazioni, librerie legacy, provider specifici, servizi schedulati e integrazioni esterne richiede un'analisi preliminare.
In particolare, la migrazione .NET 8 → .NET 10 è diversa dalla modernizzazione di un'applicazione .NET Framework 4.x (vedi la modernizzazione di applicazioni .NET Framework): sono percorsi distinti e non vanno confusi.
6. E se non riesco a migrare entro il 10 novembre?
La prima cosa da evitare è una migrazione frettolosa direttamente in produzione. Documenta quali servizi sono interessati, la loro esposizione a Internet, il valore dei dati trattati e la presenza di vulnerabilità note; concorda quindi una finestra di intervento realistica.
Se il passaggio non è immediato, possono essere utili misure temporanee quali restrizioni di rete, aggiornamenti dei componenti ancora supportati, controlli di accesso più rigorosi, monitoraggio e riduzione della superficie esposta. Queste misure non ripristinano il supporto Microsoft per .NET 8 o .NET 9 e non sostituiscono il piano di migrazione.
7. Checklist prima della pubblicazione in produzione
- Inventario dei progetti
net8.0enet9.0e dei runtime effettivamente distribuiti. - SDK e build agent compatibili con .NET 10; verifica di
global.json. - Dipendenze NuGet, provider EF Core e pacchetti terzi verificati.
- Breaking changes lette e valutate rispetto al codice reale.
- Runtime su IIS, Linux, Windows o Docker aggiornato dove necessario.
- Test funzionali, regressione, sicurezza e prestazioni eseguiti.
- Piano di rollback, backup e osservabilità post-rilascio disponibili.
Domande frequenti
Le applicazioni .NET 8 smetteranno di funzionare l'11 novembre 2026?
No. La scadenza riguarda il supporto e gli aggiornamenti di sicurezza ordinari, non una disattivazione automatica delle applicazioni esistenti.
È obbligatorio migrare a .NET 10?
Non esiste un blocco tecnico che obblighi il passaggio in quella data; tuttavia, per mantenere una piattaforma Microsoft supportata, .NET 10 LTS è il target naturale per le applicazioni oggi su .NET 8 o .NET 9.
Basta cambiare TargetFramework in net10.0?
No. È solo uno dei passi. Occorre verificare SDK, package, compatibility notes, hosting e flussi applicativi prima del rilascio.
Devo riscrivere l'applicazione?
Normalmente no: per molti progetti moderni ASP.NET Core l'aggiornamento è incrementale. La necessità di refactoring dipende dal codice e dalle dipendenze, non dalla sola data di fine supporto.
E se la mia applicazione usa .NET Framework 4.8?
Questa scadenza riguarda .NET 8 e .NET 9, non .NET Framework. Per .NET Framework 4.8 Microsoft indica che il supporto continua finché è installato su una versione di Windows supportata (verifica i dettagli nella policy ufficiale). Se la tua applicazione è su .NET Framework, il percorso è diverso: è una modernizzazione progressiva verso .NET moderno, non un semplice aggiornamento di versione.
Conviene aspettare .NET 11?
Per un sistema che deve restare supportato a lungo, il target naturale è .NET 10 LTS. .NET 11 è previsto come release STS, con un periodo di supporto più breve di una LTS, e non elimina la necessità di lasciare .NET 8 e .NET 9 entro la scadenza. Portare l'applicazione su .NET 10 ora non impedisce di valutare .NET 11 in futuro.
Cambia qualcosa se uso Azure App Service o un altro servizio gestito?
Il ciclo di supporto è quello Microsoft, ma i servizi gestiti possono pubblicare comunicazioni e date di ritiro proprie per le versioni di runtime. Controlla gli avvisi del tuo provider e le versioni di runtime disponibili sulla piattaforma prima di pianificare il rilascio.
Fonti ufficiali Microsoft
In sintesi
Fine supporto non significa fine funzionamento. Significa gestire un rischio.
Inventaria le applicazioni, verifica le compatibilità e programma il passaggio a .NET 10 LTS con test e rollback. La migrazione è un intervento di manutenzione evolutiva, non soltanto un cambio di TargetFramework.
Guide correlate
Devi migrare un'applicazione ASP.NET Core a .NET 10?
Posso supportare aziende e software house nell'analisi di dipendenze e breaking changes, nell'aggiornamento di Web API e servizi .NET, nei test di regressione e nella preparazione di un rilascio controllato.