Fine supporto di .NET 8 e .NET 9 il 10 novembre 2026: cosa fare e quanto costa passare a .NET 10

Il responsabile IT di un'azienda di serramenti nel Veneto riceve martedì mattina la mail automatica dell'antivirus: "Rilevato runtime non più supportato su 4 server". Sono i server che fanno girare il gestionale di produzione, scritto tre anni fa su .NET 8 da una software house che oggi segue altri clienti. Il gestionale funziona benissimo. Nessuno ha toccato niente. Eppure da quel giorno ogni falla scoperta nel runtime resta aperta, perché Microsoft ha smesso di correggerla.

Il 10 novembre 2026 .NET 8 e .NET 9 escono insieme dal supporto. Se hai un'applicazione su una delle due versioni, hai una scadenza e non hai un'emergenza: questa guida ti dice che cosa succede davvero quel giorno, quali sistemi controllare per primi, quanto costa il passaggio a .NET 10 e come organizzarlo in settimane invece che in mesi. Dopo il 10 novembre 2026 le applicazioni su .NET 8 e .NET 9 continuano a funzionare, ma non ricevono più correzioni di sicurezza né assistenza ufficiale, e la strada più sensata è la migrazione a .NET 10, supportato fino a novembre 2028.

Se la tua applicazione è ancora più vecchia, parti da la migrazione da .NET Framework a .NET 10, perché lì il conto è diverso.

Quando finisce il supporto di .NET 8 e .NET 9 e che cosa significa?

Il supporto di .NET 8 e di .NET 9 termina il 10 novembre 2026: da quella data Microsoft non pubblica più correzioni di sicurezza, aggiornamenti del runtime né assistenza tecnica per entrambe le versioni. Le applicazioni già installate continuano a girare senza alcun blocco o avviso a video.

Le due scadenze coincidono per una ragione di calendario. .NET 8 è una versione a lungo termine (LTS) uscita il 14 novembre 2023 con 36 mesi di assistenza. .NET 9, uscito il 12 novembre 2024, è una versione a termine standard: dopo l'estensione decisa da Microsoft, ha 24 mesi invece dei 18 originali. Il 10 novembre è anche il secondo martedì del mese, il giorno degli aggiornamenti di sicurezza Microsoft, e le due versioni possono ricevere un ultimo rilascio quel giorno se esiste un problema critico noto.

Che cosa significa "fuori supporto"

Significa tre cose concrete. Le vulnerabilità scoperte dopo la data restano senza correzione, quindi ogni nuova falla nel runtime o in ASP.NET Core diventa permanente sul tuo server. Non puoi aprire una richiesta di assistenza a Microsoft su quel runtime. E gli strumenti attorno (Visual Studio, immagini dei container, servizi di hosting) cominciano a trattare quelle versioni come obsolete: Visual Studio 2022 segnalerà come non supportati i componenti di .NET 8 e .NET 9 in un aggiornamento futuro.

Che cosa non succede

Il programma non si ferma e i dati non spariscono. Nessuna licenza scade. Non serve intervenire alle sei del mattino del giorno 10. Succede qualcosa di più lento e più costoso: ogni mese che passa l'esposizione cresce, perché gli attaccanti conoscono le date di fine supporto e le falle nuove si accumulano su una base che nessuno corregge.

Il tuo calendario in una riga

Chi ha un'applicazione su .NET 8 o .NET 9 deve avere un piano scritto entro fine novembre e la migrazione chiusa entro il primo trimestre 2027. Tra poco vediamo come stimarla.

La data da mettere in agenda

Segna tre date nel calendario dell'infrastruttura: il 10 novembre 2026 per .NET 8 e .NET 9, novembre 2028 per .NET 10 e un promemoria sei mesi prima della scadenza successiva. Chi gestisce le versioni con un calendario condiviso smette di vivere ogni scadenza come un'emergenza. Il calendario costa dieci minuti, e quei dieci minuti decidono se la prossima migrazione sarà un progetto di una settimana o un'urgenza di un mese.

A questo calendario si agganciano le altre dipendenze che scadono: sistema operativo dei server, versione del database, certificati. Spesso il momento migliore per cambiare runtime coincide con un'altra manutenzione già prevista, e conviene unire gli interventi in un'unica finestra concordata con gli utenti.

Perché non basta "tanto funziona": il rischio reale di un runtime senza correzioni

Un runtime fuori supporto accumula vulnerabilità non corrette: l'applicazione funziona come prima, ma ogni falla scoperta dopo il 10 novembre 2026 resta aperta, e il rischio ricade su chi ospita il servizio. Per un'azienda italiana significa anche responsabilità, non solo tecnica.

Il ragionamento di chi rimanda è sempre lo stesso: l'applicazione gira da tre anni senza problemi, non è esposta su internet, i dati non sono sensibili. Tutte e tre le frasi hanno una scadenza di validità. Il gestionale oggi sta dietro una rete interna, domani qualcuno apre un portale clienti per gli ordini e la rete interna smette di essere l'unica porta. I dati dei dipendenti, le anagrafiche dei clienti e i listini rientrano nel GDPR anche se nessuno li considera "sensibili".

Che cosa chiedono le assicurazioni e i clienti

Le polizze informatiche e i questionari di sicurezza dei clienti più strutturati chiedono già oggi se i sistemi usano software con supporto attivo. Una risposta "no, runtime fuori supporto" apre una discussione commerciale che prima non c'era. Alla direttiva NIS2 devono rispondere sempre più imprese manifatturiere, e la gestione degli aggiornamenti dei sistemi rientra fra le misure richieste ai fornitori delle aziende soggette.

Il costo di una falla

Un'intrusione in un gestionale produttivo costa fermo macchina, ripristino da copie di sicurezza e giorni di lavoro dell'ufficio tecnico. Per una PMI da venti persone, tre giorni di fermo parziale valgono facilmente 15.000-25.000 euro fra produzione persa e interventi esterni, contro i 3.000-9.000 euro di una migrazione ordinata di una solution media. Il confronto cambia, ma di rado a favore dell'attesa.

Perché aspettare costa di più

Aspettare non azzera il lavoro, lo sposta. Ogni anno di ritardo aggiunge pacchetti da aggiornare, modifiche di comportamento da assorbire e un divario di versioni più ampio. Salire da .NET 8 a .NET 10 si fa in giorni. Salire da .NET 8 a una futura versione fra tre anni, passando per correzioni di dipendenze nel frattempo scadute, si fa in settimane.

Come scoprire in mezz'ora quali tuoi sistemi girano su .NET 8 o .NET 9

Per trovare le applicazioni su .NET 8 e .NET 9 bisogna cercare la riga TargetFramework nei file di progetto (net8.0 o net9.0), verificare i runtime installati sui server con il comando dotnet --list-runtimes e controllare le immagini dei container. L'inventario richiede mezz'ora per ogni repository e un'ora per ogni gruppo di server.

Il primo errore è fidarsi della memoria. In quasi ogni azienda esistono applicazioni dimenticate: lo strumento di esportazione scritto da un consulente, il servizio che sincronizza il magazzino alle due di notte, il sito dei preventivi. Il registro dei sistemi spesso li ignora, e sono proprio quelli che nessuno aggiorna.

Nei repository: la riga che conta

Ogni progetto dichiara la versione di destinazione. Una ricerca testuale su tutto il codice fornisce l'elenco completo in pochi secondi:

# Da PowerShell, nella cartella che contiene tutti i repository
Get-ChildItem -Recurse -Include *.csproj,Directory.Build.props |
  Select-String -Pattern "net8\.0|net9\.0" |
  Select-Object Path, Line

Sui server: i runtime installati

Su ogni macchina che esegue applicazioni .NET il comando seguente elenca quali versioni sono installate. Un runtime presente non significa che qualcuno lo usi, ma un runtime assente garantisce che nessuno lo usa:

dotnet --list-runtimes
# Microsoft.AspNetCore.App 8.0.x [C:\Program Files\dotnet\shared\...]
# Microsoft.NETCore.App 9.0.x [C:\Program Files\dotnet\shared\...]

Nei container e nell'hosting

Nei file di definizione dei container la riga FROM mcr.microsoft.com/dotnet/aspnet:8.0 rivela la versione. Per i servizi gestiti (hosting web, funzioni serverless) guarda l'impostazione di versione dello stack nel pannello del fornitore. Segna tutto in un foglio con quattro colonne: applicazione, versione, chi la mantiene, quanto è critica. Con quel foglio sei già a metà del piano.

Come si passa da .NET 8 o .NET 9 a .NET 10 passo dopo passo

Il passaggio da .NET 8 o .NET 9 a .NET 10 si fa cambiando la riga TargetFramework in net10.0, aggiornando i pacchetti NuGet, ricompilando, eseguendo i test e aggiornando runtime e pipeline di pubblicazione sui server. Per una solution media con test automatici occupa da due a cinque giorni di lavoro.

Il percorso è lineare perché .NET 8, 9 e 10 appartengono alla stessa famiglia e mantengono una compatibilità alta fra versioni consecutive. Il lavoro vero sta nelle dipendenze e nell'ambiente, più che nel codice.

I sei passi in ordine

Primo: installa l'SDK di .NET 10 sulla macchina di sviluppo e fissa la versione con un file global.json, così tutta la squadra compila con lo stesso strumento. Secondo: cambia il framework di destinazione in ogni progetto. Terzo: aggiorna i pacchetti NuGet alle versioni compatibili. Quarto: compila e correggi gli avvisi, perché le API obsolete di ieri sono gli errori di domani. Quinto: esegui l'intera batteria di test. Sesto: aggiorna runtime e pipeline sull'ambiente di collaudo e solo dopo in produzione.

<!-- Nel file .csproj di ogni progetto -->
<PropertyGroup>
  <TargetFramework>net10.0</TargetFramework>
</PropertyGroup>

// global.json nella radice della solution
{
  "sdk": { "version": "10.0.100", "rollForward": "latestFeature" }
}

Un trucco che fa risparmiare un giorno

Se la solution ha molti progetti, centralizza la versione in un unico file Directory.Build.props con la proprietà del framework. Si cambia una riga, non venti. Chi ha già fatto questo lavoro con la migrazione di un'applicazione con iniezione delle dipendenze ben fatta sa che i progetti piccoli, separati e con i test al fianco si migrano in un pomeriggio.

Lo strumento di Microsoft

L'assistente di aggiornamento ufficiale (.NET Upgrade Assistant) analizza la solution e propone le modifiche. È utile per avere una lista di partenza, e non sostituisce il collaudo. Dopo l'automazione resta sempre una sessione di prova sull'applicazione in esecuzione con dati reali.

Che cosa può rompersi nel passaggio a .NET 10 e come ci si prepara

Nel passaggio a .NET 10 si rompono quasi sempre le stesse cose: pacchetti NuGet non ancora compatibili, API segnalate come obsolete, comportamenti modificati nella serializzazione e nell'accesso ai dati, e configurazioni di hosting rimaste a una versione vecchia. Sono tutte scoperte in ambiente di collaudo, se esiste.

La pagina ufficiale dei breaking change di .NET 10 elenca ogni modifica di comportamento, divisa per componente. Non va letta tutta: va filtrata per i componenti che usi. Se la tua applicazione usa ASP.NET Core, Entity Framework Core e System.Text.Json, leggi quelle tre sezioni e ignora il resto.

I pacchetti di terze parti

È il punto che più spesso ruba tempo. Una libreria di report, un componente per i PDF, un client per un servizio esterno: se l'autore ha smesso di aggiornarla, la compilazione passa e a metà percorso si scopre un comportamento diverso. Il comando dotnet list package --outdated mostra quali pacchetti hanno versioni più recenti, e dotnet list package --deprecated quali sono stati ritirati dai loro autori.

Il database

Entity Framework Core 10 cambia il modo di tradurre alcune query. Un'istruzione che ieri produceva una forma di SQL oggi può produrne un'altra, magari più veloce, magari no. Prima del rilascio confronta i tempi delle cinque query più pesanti, con lo stesso metodo descritto in Entity Framework Core e le query lente.

Che cosa dicono i test

Una solution con una buona copertura di test di integrazione si migra con serenità, perché il test dice in cinque minuti se un comportamento è cambiato. Senza test, il collaudo diventa una persona seduta davanti all'applicazione per due giorni. Se non ne hai, la migrazione è l'occasione per scriverne almeno uno per ogni flusso critico: ordine, fattura, esportazione.

Quanto costa migrare un'applicazione da .NET 8 o .NET 9 a .NET 10

Migrare da .NET 8 o .NET 9 a .NET 10 costa da 1.800 a 3.600 euro per una solution piccola, da 3.600 a 9.000 euro per una media e da 9.000 a 24.000 euro per una grande, con una tariffa di riferimento di 600 euro al giorno. Sono stime a ordine di grandezza: il costo reale dipende dai test e dalle dipendenze.

Il conto si fa sui giorni persona. Una solution piccola ha uno o due progetti, poche dipendenze e un'interfaccia semplice: da tre a sei giorni. Una media ha cinque-dieci progetti, un database, un'interfaccia web e qualche libreria di terze parti: da sei a quindici giorni. Una grande ha servizi multipli, integrazioni esterne e storia lunga: da quindici a quaranta giorni.

Che cosa fa salire il conto

Tre fattori spostano la stima verso l'alto: assenza di test automatici (si aggiungono due-quattro giorni di collaudo manuale), librerie di terze parti abbandonate (da sostituire) e ambienti di pubblicazione fatti a mano, senza pipeline. Un team che pubblica con un clic migra in metà tempo di uno che copia file su un server.

Che cosa lo fa scendere

Un'architettura a strati puliti, progetti piccoli con una responsabilità sola e una pipeline automatica riducono il lavoro. Questo vale come argomento per fare la migrazione anche quando il costo sembra alto: il lavoro speso a rendere la solution migrabile si ripaga alla prossima scadenza, quella di .NET 10 nel 2028.

Il confronto che conta

Una migrazione da 6.000 euro va confrontata con il costo di restare esposti e, fra due anni, con il costo di una migrazione più grande. Chi vuole andare più a fondo sul calcolo del software esistente trova il metodo in quanto costa davvero il software legacy.

Perché scegliere .NET 10 e non fermarsi a .NET 9 o aspettare .NET 11

La scelta giusta per un'azienda è .NET 10, perché è una versione a lungo termine supportata fino a novembre 2028, mentre .NET 9 è già al capolinea e le versioni a termine standard hanno vita più breve. Passare a una versione standard significa ripetere la migrazione fra due anni.

Microsoft rilascia una nuova versione ogni novembre. Quelle pari (6, 8, 10) sono a lungo termine con tre anni di assistenza, quelle dispari sono a termine standard e arrivano a due. Per chi produce software di riferimento per il lavoro quotidiano di un'azienda, il ritmo giusto è una migrazione ogni due-tre anni, da LTS a LTS: 8 a 10, poi 10 a 12.

Che cosa guadagni con .NET 10 oltre al supporto

Il supporto è il motivo per cui migri, e non l'unico. .NET 10 porta miglioramenti di prestazioni del runtime e della compilazione, novità in C# 14 e in ASP.NET Core (validazione per le Minimal API, supporto a OpenAPI 3.1). Chi vuole l'elenco completo lo trova in le novità di .NET 10. Per il tuo bilancio contano di più due cose: meno server per lo stesso carico e meno tempo di avvio.

E se l'applicazione è su .NET 9?

Il caso .NET 9 è più comodo di quanto sembri. La distanza con .NET 10 è di una sola versione, le modifiche di comportamento sono poche e la migrazione spesso si chiude in due giorni. Il rischio è usare la migrazione per fermarsi lì: una volta cambiato il numero, programma già la prossima tappa LTS e scrivila nel calendario dell'infrastruttura.

E se aspetti .NET 11?

.NET 11 sarà una versione a termine standard, quindi con una vita breve. Aspettarla per saltare .NET 10 significa lasciare l'applicazione senza correzioni nel frattempo, e ritrovarsi con una scadenza ancora più vicina. L'attesa si può spiegare in una riunione, e non si difende davanti a un questionario di sicurezza.

Come verificare se i software di terzi che usi sono pronti

Per i programmi che non hai scritto tu, la verifica è una domanda scritta al fornitore: su quale versione di .NET gira il prodotto, quando passerà a .NET 10 e con quale data contrattuale. Microsoft stessa consiglia di chiedere al fornitore una versione costruita su .NET 10.

Il fornitore di un gestionale, di un sistema di prenotazione o di un software per le buste paga di solito sa rispondere in un giorno. Chi non risponde ti sta dando un'informazione ugualmente preziosa. Metti la domanda nel prossimo ciclo di contatti con ogni fornitore e conserva la risposta.

Le quattro domande da fare

Su quale versione di .NET gira oggi il prodotto, comprese le componenti installate sui tuoi server? Entro quale data il fornitore rilascia una versione su .NET 10? L'aggiornamento è compreso nel canone o è un progetto a parte? Che cosa succede ai miei dati e alle mie personalizzazioni durante il passaggio? La terza domanda evita sorprese in fattura, la quarta evita sorprese in produzione.

Quando il fornitore non c'è più

Succede più spesso di quanto si dica: la software house ha chiuso, l'autore è passato ad altro, il codice sorgente è in una chiavetta. In quel caso l'applicazione è un bene aziendale senza manutentore. Le strade sono tre: farla riprendere da un team esterno e migrarla, riscriverla a pezzi con il metodo del Strangler Fig, oppure isolarla in una rete protetta e fissare una data di sostituzione.

Una clausola per i contratti futuri

Nei nuovi contratti di sviluppo inserisci una riga: il fornitore si impegna a mantenere l'applicazione su una versione di .NET supportata per tutta la durata dell'incarico. Costa una frase e ti risparmia il problema di questa settimana.

Pipeline, container e Visual Studio: gli strumenti da aggiornare insieme al codice

Insieme al codice vanno aggiornati tre strumenti: la pipeline di compilazione (SDK .NET 10), le immagini dei container (aspnet:10.0) e Visual Studio, che dopo la scadenza segnala come non supportati i componenti di .NET 8 e .NET 9. Se ne dimentichi uno, la migrazione sembra finita e in produzione gira ancora la versione vecchia.

È l'errore più frequente nelle migrazioni a metà: il codice punta a net10.0, la pipeline compila con l'SDK vecchio e fallisce solo il venerdì sera. Oppure compila, ma il server di produzione ha installato solo il runtime precedente e l'applicazione non parte.

La pipeline di compilazione

Cerca nei file della pipeline (Azure DevOps, GitHub Actions, script) la riga che installa l'SDK e portala alla serie 10. Fissa la versione in un solo punto, preferibilmente nel global.json già visto, così la pipeline e lo sviluppatore compilano con lo stesso strumento.

# Esempio per Azure DevOps: installa l'SDK indicato nel global.json
- task: UseDotNet@2
  inputs:
    useGlobalJson: true

I container e l'hosting

Nel file del container cambia le due immagini, quella di compilazione e quella di esecuzione, dalla serie 8.0 o 9.0 alla serie 10.0. Controlla poi l'impostazione dello stack sul servizio che ospita l'applicazione: molti servizi gestiti hanno un menu a tendina con la versione di .NET, e nessuno lo aggiorna da solo.

Visual Studio e le macchine degli sviluppatori

Visual Studio 2022 supporta .NET 10 dalle versioni recenti. Un aggiornamento futuro segnerà i componenti di .NET 8 e .NET 9 come fuori supporto e permetterà di rimuoverli. Se qualcuno nel team ha bisogno di entrambi per mantenere applicazioni in attesa, lascia i componenti installati finché serve. L'importante è che nessun server di produzione dipenda da quella scelta.

Il controllo finale

A fine migrazione lancia dotnet --list-runtimes sul server di produzione e verifica che la serie 10 sia presente. Poi guarda l'intestazione di risposta dell'applicazione o la pagina di diagnostica: deve dichiarare la versione nuova. Un minuto di verifica evita una settimana di illusione.

Un piano di trenta giorni per chiudere la migrazione senza stravolgere il lavoro

Un piano realistico di trenta giorni ha quattro tappe settimanali: inventario dei sistemi, migrazione dell'applicazione meno critica come prova, migrazione delle altre in ordine di rischio, verifica e documentazione. La prima applicazione serve a trovare i problemi che si ripeteranno nelle altre.

Il piano funziona perché accetta un fatto: nessuna azienda ha una settimana libera per fare solo questo. Procede a piccoli blocchi e lascia che ogni settimana produca una cosa finita.

Settimana uno: inventario e priorità

Compila il foglio visto in precedenza: applicazione, versione, responsabile, criticità. Ordina per esposizione (che cosa è raggiungibile da internet) e per importanza (che cosa ferma l'azienda se si rompe). Le applicazioni raggiungibili da internet passano per prime, anche se sono piccole.

Settimana due: la prova generale

Scegli l'applicazione più semplice, quella che puoi rompere senza conseguenze, e migrala da capo a fondo: codice, pacchetti, pipeline, collaudo, pubblicazione. Segna ogni intoppo. Questo documento di due pagine è il tesoro del progetto, perché descrive i problemi dei tuoi pacchetti e dei tuoi server, non quelli della teoria.

Settimane tre e quattro: il resto, in ordine di rischio

Con la prova alle spalle, le applicazioni successive vanno veloci. Pubblica prima in collaudo, lascia girare qualche giorno con dati reali, poi passa in produzione in una fascia oraria tranquilla. Tieni pronta la versione precedente per un ritorno rapido: finché il vecchio pacchetto di pubblicazione esiste, un errore costa un'ora e non un giorno.

Chi lo fa

Se in azienda c'è uno sviluppatore che conosce il codice, il lavoro è suo, con un'ora di revisione a settimana da parte di qualcuno più esperto. Se il codice lo mantiene un fornitore, il piano diventa una richiesta formale con data. Se non c'è nessuno, serve un professionista esterno per un progetto breve e circoscritto. In nessuno dei tre casi conviene aspettare dicembre.

Come presentare la migrazione alla direzione con un conto di una pagina

Alla direzione la migrazione a .NET 10 si presenta con tre numeri: costo della migrazione, costo annuale dell'esposizione se si rimanda e data oltre la quale un cliente o un'assicurazione può contestare il sistema. Un conto di una pagina batte venti slide di tecnologia.

Chi decide il budget non ha bisogno di sapere che cosa sia un runtime. Ha bisogno di sapere quanto spende, che cosa rischia e che cosa guadagna. Traduci ogni voce in euro e in giorni, e porta un'alternativa: spesso la proposta più efficace è fare la cosa in due tappe.

Le tre righe del conto

Prima riga: la migrazione costa, per esempio, 6.000 euro in dieci giorni persona. Seconda riga: il rischio di restare fermi vale la probabilità di un incidente moltiplicata per il suo costo; con una stima prudente dell'uno per cento su un danno di 20.000 euro il valore atteso annuale è piccolo, e il peso vero sta nella coda: un evento raro che ferma l'azienda per una settimana. Terza riga: il costo di rifare lo stesso lavoro fra due anni, quando le dipendenze saranno ancora più indietro.

Che cosa guadagna l'azienda oltre alla sicurezza

Una solution su .NET 10 si avvia più in fretta, consuma un po' meno risorse e trova più facilmente sviluppatori disposti a lavorarci, perché pochi vogliono mettere mano a un runtime scaduto. La stessa dinamica si osserva sul mercato del lavoro: chi cerca un profilo per un'applicazione ferma a una versione vecchia paga di più e aspetta di più.

L'alternativa in due tappe

Se il budget è stretto, proponi due tappe: nelle prime due settimane migri e metti in sicurezza le applicazioni raggiungibili da internet; nel trimestre successivo tocchi quelle interne e scrivi i test mancanti. La direzione approva con più facilità un impegno diviso in due tappe, perché vede una prima conclusione vicina e una seconda sotto controllo. Per ragionare sul bilancio complessivo di un software aziendale, leggi anche quanto costa un software su misura.

Gli errori più comuni nelle migrazioni a .NET 10 e come evitarli

Gli errori più comuni sono cinque: migrare senza inventario, cambiare il framework senza aggiornare la pipeline, rimandare il collaudo sui dati reali, ignorare gli avvisi del compilatore e non prevedere un ritorno alla versione precedente. Nessuno richiede competenze rare, richiedono solo un elenco da spuntare.

Ogni errore ha una causa banale. L'inventario si salta perché sembra una perdita di tempo, e a metà percorso emerge l'applicazione dimenticata. La pipeline si dimentica perché sta in un altro repository, scritto da un'altra persona. Il collaudo sui dati reali si rimanda perché richiede di copiare un database, e si finisce per scoprire il problema il lunedì mattina, con gli utenti connessi.

Gli avvisi che oggi sembrano rumore

Il compilatore segnala le API obsolete con avvisi gialli. Dopo anni di vita di una solution gli avvisi sono centinaia e nessuno li legge. Durante la migrazione filtra quelli sulle API obsolete e correggili: sono l'elenco esatto di ciò che si rompe alla prossima versione. Un'ora spesa a ripulirli oggi risparmia una giornata fra due anni.

Il ritorno alla versione precedente

Prima di pubblicare in produzione conserva il pacchetto della versione vecchia e le copie del database. Scrivi su un foglio i tre comandi che servono per tornare indietro e prova a eseguirli una volta in collaudo. Un ritorno che non è mai stato provato non è un piano, è una speranza.

La tentazione di fare tutto insieme

Il momento della migrazione è quello in cui molti vogliono sistemare anche l'architettura, cambiare l'accesso ai dati, riscrivere l'interfaccia. È una tentazione da respingere. Cambia una cosa alla volta: prima la versione, poi, in progetti separati e con il suo calendario, il resto. Chi vuole decidere se rifare o sistemare trova i criteri in riscrivere o rifattorizzare il software legacy.

Domande che ricevo più spesso sulla fine del supporto di .NET 8 e .NET 9

Le domande ricorrenti sono cinque: se l'applicazione smette di funzionare, se è obbligatorio migrare, se si può restare su .NET 9, quanto costa e che cosa succede ai software di terzi. Le risposte sono no, in pratica sì, sconsigliato, da poche migliaia di euro e dipende dal fornitore.

L'applicazione non si ferma il 10 novembre, perché il runtime non contiene alcun blocco a tempo. Migrare è obbligatorio nel senso pratico: nessuna legge impone una versione di .NET, ma norme e contratti sulla sicurezza (GDPR, NIS2, clausole assicurative) chiedono software aggiornato, e un runtime fuori supporto è difficile da difendere.

Una scena da evitare

Ho visto aziende che rimandano finché un cliente grosso invia un questionario di sicurezza con la riga "tutti i sistemi usano software con supporto attivo". Da quel momento la migrazione smette di essere un progetto tecnico e diventa una trattativa commerciale con una scadenza, e le scadenze imposte da altri costano il doppio di quelle scelte da te. Il compito di oggi è fare la scelta mentre è ancora tua.

Il passo per lunedì

Apri il repository della tua applicazione principale, cerca net8.0 e net9.0 e scrivi su un foglio quanti progetti trovi. Quel numero, moltiplicato per mezza giornata, è la prima stima onesta della tua migrazione. Il resto del piano discende da lì.

Il responsabile IT dell'azienda di serramenti ha aperto il foglio il martedì stesso. Quattro server, tre applicazioni, una dimenticata da due anni. Il gestionale è passato a .NET 10 in sei giorni di lavoro, con un test di integrazione scritto per ogni flusso importante, e per la prima volta l'azienda sa quanto vale mantenere il suo software al passo con le scadenze.

Se la tua scadenza è la stessa, nel corso Architetto Software di Sviluppatore Migliore impari a decidere quando migrare, come stimare il costo e come tenere un'applicazione sana negli anni, lavorando su casi reali con il mio feedback diretto, in lezioni registrate e sessioni dal vivo compatibili con il lavoro. Porta la tua applicazione: la guardiamo insieme.