Next.js 15 perde il supporto ufficiale il 21 ottobre 2026. Il piano concreto per audit, migrazione e protezione della tua app.
Next.js 15 perde ogni supporto ufficiale il 21 ottobre 2026, secondo il calendario di fine vita pubblicato da HeroDevs. Concretamente: nessun correttivo di sicurezza dopo questa data, nemmeno in caso di vulnerabilità critica. Se la tua applicazione gira ancora su di essa, questo articolo ti fornisce un piano per audit, migrazione e come evitare i classici trabocchetti prima della scadenza.
Perché questa data conta davvero
Una versione in fine vita non smette di funzionare da un giorno all'altro. Continua a girare, silenziosamente, fino al giorno in cui esce una CVE e nessuno la corregge per te.
Qui sta il vero rischio: non un'interruzione immediata, ma una finestra di esposizione che si apre senza preavviso. I team di sicurezza dei tuoi clienti o dei tuoi partner B2B pongono sempre più frequentemente la questione del supporto delle dipendenze nei loro audit fornitori. Un framework non mantenuto può far fallire un audit SOC2 o ISO 27001, indipendentemente dalla qualità del tuo codice.
Next.js 15 è attualmente in Maintenance LTS, il che significa: patch di sicurezza critici soltanto, nessuna nuova funzionalità. Dopo il 21 ottobre 2026, anche quello si ferma. Hai, alla data di redazione di questo articolo, poco meno di tre mesi per decidere.
Tre mesi sembra tanto. Non lo è per un team di meno di 5 sviluppatori che deve anche consegnare le sue feature del trimestre.
Audit prima della migrazione: cosa verificare per primo
Migrare senza un audit preliminare è il modo migliore per scoprire un breaking change in produzione un venerdì sera. Prima di toccare package.json, passa in rassegna questi punti.
L'utilizzo residuo del Pages Router. Molte applicazioni Next.js hanno migrato verso l'App Router in facciata ma mantengono route API o pagine legacy sul vecchio sistema. Sono le prime a rompersi durante un aumento di versione maggiore.
Le dipendenze terze legate al rendering. Le librerie che patchano il comportamento di rendering di Next.js (alcuni SDK di A/B testing, alcuni strumenti di personalizzazione) sono spesso gli ultimi a pubblicare una versione compatibile. Verifica il loro changelog prima di impegnarti su un calendario.
Le Server Actions e la cache dei dati. Il comportamento della cache introdotto con l'App Router è evoluto più volte da Next.js 13. Se il tuo team ha implementato workaround manuali per gestire la revalidation, questi sono punti di attrito quasi garantiti durante una migrazione maggiore.
La versione di Node.js e React sottostante. Next.js 15 si basa su React 19; un aumento di versione maggiore del framework è quasi sempre accompagnato da un innalzamento della versione Node minima supportata. Verifica il tuo runtime di produzione, inclusi gli ambienti di preview.
Fai questo inventario in una semplice tabella, riga per riga, con una colonna "rischio" e una colonna "effort stimato". Ti prende mezza giornata. Ti evita due settimane di brutte sorprese.
I passaggi concreti di una migrazione senza rotture
Una volta fatto l'audit, la migrazione stessa segue un percorso piuttosto segnato, a condizione di non saltare passaggi.
Passaggio 1: isola un ambiente di test rappresentativo
Non migrare mai direttamente su un ramo che punta alla prod. Crea un ambiente speculare con un set di dati realistico, non un database vuoto. I bug di cache e revalidation spesso appaiono solo con traffico e dati reali.
Passaggio 2: aumenta la versione per gradi, non in un salto
Se sei ancora su Next.js 13 o 14, non puntare direttamente a Next.js 16 in un singolo commit. Passa per Next.js 15 prima, stabilizza, poi prosegui. Ogni salto di versione maggiore isolato è più semplice da debuggare che un salto cumulativo di tre versioni.
Passaggio 3: usa i codemods ufficiali quando esistono
Vercel storicamente pubblica codemods per automatizzare parte delle migrazioni tra versioni maggiori (rinominazione di import, adattamento della config). Non copre mai il 100% del lavoro, ma evita errori di battitura su centinaia di file.
Passaggio 4: testa la build di produzione, non solo lo sviluppo
La modalità sviluppo nasconde certi problemi di generazione statica o Edge Runtime. Un next build completo, seguito da un deployment su un ambiente di preview isolato, deve far parte della checklist prima di qualsiasi merge.
Passaggio 5: pianifica un rollback prima del deployment, non dopo
Mantieni la versione vecchia deployable in un clic per almeno due settimane dopo il cambio. La maggior parte delle regressioni di cache o SEO (tag, sitemap, redirect) appare solo dopo diversi giorni di traffico reale.
Un team di prodotto con un'applicazione di 200 pagine e Server Actions complessi conterà diverse settimane di lavoro distribuite su due o tre sprint. Un sito vetrina di 15 pagine senza logica di business pesante può, invece, passare in un singolo sprint. Il divario di carico di lavoro tra questi due casi è enorme, diffida dalle stime generiche trovate online, raramente tengono conto della vera dimensione del progetto.
Restare su next.js 15 o migrare adesso: il confronto
| Criterio | Restare su Next.js 15 dopo il 21/10/2026 | Migrare verso Next.js 16 prima della scadenza |
|---|---|---|
| Patch di sicurezza | Nessuno dopo la data di fine vita | Supporto attivo, patch regolari |
| Compatibilità audit fornitori | Rischio di non conformità (SOC2, ISO 27001) | Conforme ai requisiti di manutenzione |
| Costo immediato | Nullo nel breve termine | Tempo dev da mobilizzare (settimane a mesi) |
| Rischio a medio termine | Debito tecnico che si accumula, migrazione più difficile domani | Base di codice aggiornata, migrazioni future più semplici |
| Accesso alle nuove funzionalità | Nessuno | Sì, secondo la roadmap Next.js |
Questa tabella non è neutra: nella stragrande maggioranza dei casi, rinviare la migrazione non fa che spostare il problema e peggiorarlo. L'unica eccezione legittima è un progetto in fine vita lui stesso, che pianifichi di dismettere prima della scadenza, nel qual caso la questione non si pone nemmeno.
Cosa ricordare
Tre punti da tenere a mente. Per primo, la data del 21 ottobre 2026 non è una voce: è il calendario ufficiale di fine vita di Next.js 15. Secondo, l'audit preliminare, Pages Router residuo, dipendenze terze, cache, versione Node, determina l'80% del successo della migrazione, ben prima di scrivere una singola riga di codice. Infine, una migrazione per gradi con ambiente di test rappresentativo rimane il metodo più sicuro, anche se richiede più tempo di un salto diretto.
Se il tuo team è ancora incerto sul calendario o sull'entità del lavoro, avevamo dettagliato un approccio simile per l'aumento di versione nel nostro articolo su TypeScript 7.0 e il compilatore nativo in Go, gli stessi principi di audit e incremento si applicano.
Domande frequenti
Cosa accade concretamente se rimani su next.js 15 dopo il 21 ottobre 2026?
L'applicazione continua a funzionare normalmente. Il rischio è l'assenza di patch in caso di vulnerabilità di sicurezza scoperta dopo questa data, e una potenziale non conformità durante audit fornitori che verificano il supporto attivo delle dipendenze critiche.
Quanto tempo impiega una migrazione da next.js 15 a next.js 16?
Dipende interamente dalla dimensione e dalla complessità dell'applicazione. Un sito vetrina semplice può passare in uno sprint; un'applicazione con Server Actions complesse e un Pages Router residuo può richiedere diversi sprint distribuiti su qualche settimana.
Bisogna migrare direttamente a next.js 16 se sei ancora su next.js 13?
No, meglio passare per Next.js 15 prima, stabilizzare, poi proseguire. Un salto di versione isolato è più facile da debuggare che un cumulo di diversi aumenti maggiori in una volta.
I codemods ufficiali sono sufficienti per migrare senza intervento manuale?
No. I codemods automatizzano parte del lavoro, rinominazione di import, adattamenti della configurazione, ma non coprono mai i casi di business specifici, soprattutto intorno alla cache e alle Server Actions. Un passaggio manuale rimane indispensabile.
Come testare una migrazione next.js senza rischiare la produzione?
Creando un ambiente di preview isolato con un set di dati realistico, lanciando una build di produzione completa (next build), e mantenendo la versione vecchia deployable in rollback per almeno due settimane dopo il cambio.
