Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso

Le scadenze di fine vita di PHP non sono un dettaglio tecnico da relegare al sysadmin: sono una leva di rischio che si arma da sola per chi resta indietro, e nel 2026 il calendario è particolarmente stretto. La cosa pericolosa è che una versione di PHP fuori supporto non lo annuncia: l'applicazione continua a funzionare identica, e proprio questa apparente normalità convince a rimandare. Ma sotto, una versione end of life non riceve più patch di sicurezza, il che significa che ogni vulnerabilità scoperta dopo quella data resta aperta, sul tuo sistema, per sempre. Scrivo PHP dal 2003 e ho visto questo errore costare caro a più di un'azienda: il "se funziona non si tocca" applicato al runtime è una bomba a orologeria il cui timer non lo vedi. Vediamo lo stato reale delle versioni PHP nel 2026, con le date verificate, e soprattutto il piano di migrazione da avviare adesso per chi è su 8.2 o 8.3, perché aspettare l'ultimo trimestre è, come dimostrerò, la scelta più costosa di tutte.

Cosa significa EOL, e perché "security-only" è già un avviso

Una versione di PHP attraversa tre fasi. Nella fase di supporto attivo riceve correzioni di bug e di sicurezza. Poi entra in solo sicurezza (security-only), in cui riceve unicamente le patch per le vulnerabilità, non più le correzioni di bug ordinari. Infine arriva il fine vita, oltre il quale non riceve più nulla. La distinzione che molti non colgono è che la fase security-only non è "tutto a posto, ho ancora tempo": è il semaforo giallo. Significa che quella versione è già a metà della sua parabola, che il conto alla rovescia verso il blackout di sicurezza è iniziato, e che è il momento di pianificare, non di rilassarsi.

Restare su una versione in security-only è gestibile per un periodo, ma trattarla come una destinazione stabile è un errore: il giorno del fine vita arriva, ed è molto più vicino di quanto sembri quando lo guardi da lontano. Il momento giusto per muoversi non è quando la versione muore, è quando entra in solo sicurezza, perché è lì che hai ancora il margine per farlo con calma.

Una versione di PHP non ti avvisa quando va in fine vita: smette semplicemente di proteggerti, e tu non te ne accorgi finché non arriva la falla che nessuno chiuderà più. La data di EOL è l'unico allarme che hai, ed è scritto sul calendario mesi prima: ignorarlo non è coraggio, è non aver guardato il calendario.

Le scadenze PHP che contano nel 2026

Ecco lo stato reale, con le date verificate sulle versioni supportate ufficiali di PHP:

La lettura strategica di questa tabella è netta. Chi è su 8.1 o versioni precedenti è già scoperto e dovrebbe trattare la migrazione come urgente, non come pianificazione. Chi è su 8.2 ha una scadenza precisa, la fine del 2026, e va mosso ora. Chi è su 8.3 ha più respiro ma è comunque in solo sicurezza, e dovrebbe puntare al ramo attivo. L'errore più comune che incontro è proprio credere che 8.3 sia ancora in supporto attivo: non lo è, è in security-only, e questo cambia la pianificazione.

Se gestisci applicazioni PHP e vuoi un quadro chiaro di a quale scadenza sei esposto e con quale urgenza, nel mio profilo professionale trovi l'esperienza concreta sulla migrazione di codebase PHP attraverso vent'anni di versioni del linguaggio, dalla 4 alle attuali.

Il piano di migrazione per chi è su 8.2 o 8.3

Il piano concreto segue una sequenza precisa, ed è la stessa che applico in ogni intervento. Primo, mappare lo stato: quale versione gira davvero, quali dipendenze ci sono e fino a quale PHP supportano, perché un solo pacchetto fermo a un vincolo vecchio può bloccare tutto. Secondo, scegliere il target giusto: per chi parte da 8.2 o 8.3, la destinazione che consiglio è la 8.4, il ramo in supporto attivo con la finestra più lunga, non la 8.3 che è già in coda di vita. Terzo, gestire le deprecazioni e i breaking change del salto, che tra versioni vicine sono contenuti ma vanno comunque intercettati. Quarto, testare in una pipeline che fa girare il codice sulla versione target in parallelo alla produzione. Quinto, distribuire gradualmente, non con un cambio secco su tutto il parco.

Per i dettagli tecnici dei breaking change e delle deprecazioni di un salto PHP, ho descritto il lavoro reale parlando del workflow di migrazione da PHP 7.4 a 8.3 assistito dall'AI, e per chi parte da molto lontano della guida completa dalla 5.6 alla 8. Tra una minor recente e l'altra il salto è molto più piccolo, ma il metodo resta identico: misurare, intercettare, testare, distribuire.

Le deprecazioni da gestire, prima che diventino errori

Il cuore tecnico di una migrazione tra versioni PHP sono le deprecazioni. Una minor introduce un avviso di deprecazione su una funzione o un comportamento; la major successiva lo rimuove, trasformando l'avviso in un errore. Il modo corretto di affrontarle è non aspettare che diventino errori: si fa girare l'applicazione con la segnalazione di tutti gli avvisi attiva, con error_reporting(E_ALL), e si correggono le deprecazioni mentre sono ancora avvisi innocui, non quando bloccano l'esecuzione. A questo si affianca l'analisi statica con strumenti come PHPStan o Psalm, che intercettano i problemi di tipo e i comportamenti cambiati senza nemmeno eseguire il codice.

Tenere il codice pulito dalle deprecazioni in modo continuo, invece che in blocco al momento della migrazione, è la pratica che rende ogni aggiornamento un evento piccolo invece che un trauma. È lo stesso principio dell'aggiornamento continuo delle dipendenze, che ho descritto parlando di aggiornamento automatico delle dipendenze PHP con Dependabot e Renovate: il debito che si paga un po' alla volta non diventa mai la montagna che blocca tutto.

Non è solo PHP: la concentrazione di scadenze del 2026

C'è un motivo in più per non guardare solo a PHP in isolamento: il 2026 concentra un numero insolito di scadenze su tutto lo stack tipico di una PMI, e affrontarle separatamente, una emergenza alla volta, è il modo più dispendioso di gestirle. Sul fronte del database, MySQL 8.0, la versione più diffusa nelle PMI italiane, è arrivata a fine vita ad aprile 2026, e MariaDB 10.6 a luglio. Sul fronte dei framework, Symfony 8.0 ha chiuso il supporto a luglio 2026, e chi non è passato alla 7.4 LTS è già in difficoltà. Sul fronte del sistema operativo, Debian 12 ha terminato il supporto di sicurezza standard a giugno, passando alla fase LTS.

Il punto strategico è che queste scadenze, prese insieme, non sono una serie di piccoli fastidi indipendenti: sono un'unica finestra critica in cui conviene pianificare gli aggiornamenti in modo coordinato, invece di rincorrere ciascuno quando esplode. Migrare il PHP mentre si è comunque costretti a toccare il database, per esempio, permette di fare un solo ciclo di test e un solo intervento di manutenzione invece di due separati. Per questo consiglio sempre di affrontare la questione EOL con uno sguardo d'insieme sullo stack, non versione per versione: il dettaglio completo di questo calendario e di come tradurlo in priorità l'ho messo nell'audit strategico dello stack tecnologico in vista del 2027. Chi pianifica guardando l'intero quadro spende una volta sola; chi reagisce a ogni singola scadenza spende ogni volta, e sempre di fretta.

Vale anche la pena ricordare che alzare la versione di PHP è spesso il prerequisito per altri aggiornamenti che vorresti fare comunque: i framework moderni richiedono versioni recenti di PHP, e restare indietro sul runtime ti blocca anche sul resto dello stack. È un effetto a catena che gioca a favore di chi si muove per tempo: un solo investimento sul PHP sblocca una serie di altri miglioramenti, mentre il ritardo li tiene tutti fermi insieme.

Perché aspettare l'ultimo trimestre è la scelta più costosa

C'è una ragione economica precisa per non rimandare, ed è la concentrazione delle scadenze. Quando la fine del 2026 si avvicina, tutte le aziende rimaste su 8.2 si muovono insieme, e la domanda di competenze per migrare si concentra nello stesso periodo, mentre l'offerta resta la stessa: il risultato è che migrare all'ultimo costa di più e si trova con più difficoltà chi ti aiuta. A questo si aggiunge che una migrazione fatta sotto la pressione della scadenza si fa di corsa, con meno test e più rischio, esattamente quando ne avresti voluto fare di più.

La matematica è semplice: la stessa migrazione fatta a freddo, con mesi di margine, costa una frazione di quella fatta in emergenza. Avviarla adesso, quando hai ancora il tempo di farla bene e di provarla con calma, è la decisione razionale; rimandarla all'ultimo trimestre è scegliere consapevolmente di pagarla di più e con più rischio. Non decidere è anch'essa una decisione, ed è quasi sempre la peggiore.

Su quale versione PHP conviene puntare nel 2026?

La risposta, per la maggior parte dei casi, è PHP 8.4. È il ramo in supporto attivo, con la finestra di sicurezza più lunga tra le versioni mature, e atterrarci ti dà il massimo respiro prima della prossima migrazione. Non consiglio di puntare a 8.3 come destinazione di un progetto di migrazione, perché è già in solo sicurezza e ti ritroveresti a doverti muovere di nuovo presto; e non spingo verso 8.5 a meno che tu non voglia le ultime feature e sia disposto a stare sul ramo più recente. Per un'azienda che vuole stabilità e il minor numero di migrazioni nel tempo, 8.4 è il punto di equilibrio: abbastanza recente da durare, abbastanza maturo da essere affidabile.

Il rischio reale non è tecnico, è di esposizione

Voglio chiudere sul punto che dovrebbe spostare la decisione da "quando ne avrò voglia" a "adesso". Il rischio di restare su una versione PHP fuori supporto non è che il codice smetta di funzionare, è che resti esposto a vulnerabilità note e non più corrette. Quando una falla di sicurezza viene scoperta nel runtime, su una versione supportata arriva la patch; su una versione end of life non arriva niente, e il tuo sistema resta vulnerabile a un attacco che chiunque può replicare leggendo l'avviso pubblico. Per un'azienda che tratta dati personali, questo è anche un problema di compliance: subire una violazione su un software con vulnerabilità note e non corrette è difficilissimo da difendere, davanti a un cliente come davanti al Garante. La fine vita di PHP non è una questione di moda tecnologica né di gusto personale, è una precisa questione di responsabilità verso i dati che custodisci.

Tirando le somme, le scadenze EOL di PHP nel 2026 disegnano un calendario che ogni responsabile dovrebbe avere sul muro: 8.2 fuori dalla sicurezza a fine anno, 8.3 già in solo sicurezza nonostante molti la credano ancora attiva, 8.4 come destinazione consigliata e 8.5 per chi vuole la finestra più lunga. Il piano per chi è indietro non è complicato (mappare, scegliere il target giusto, gestire le deprecazioni, testare, distribuire), ma ha una variabile critica che non è tecnica, è il tempo: avviato adesso è un progetto gestibile e poco costoso, rimandato all'ultimo trimestre diventa un'emergenza cara e rischiosa, e ignorato del tutto è un'esposizione di sicurezza che si arma da sola. La differenza tra le tre non è la competenza, è il momento in cui si decide. Se gestisci un'applicazione PHP su 8.2 o 8.3 e vuoi un piano di migrazione concreto, con le scadenze a cui sei esposto e un percorso testato verso una versione supportata, contattami per una consulenza diretta: nella mia esperienza, la migrazione che spaventa quando la guardi all'ultimo momento è quasi sempre un lavoro sereno e prevedibile quando la si comincia con i mesi di margine che oggi, alla data in cui scrivo, hai ancora ma che si assottigliano ogni settimana.