--- title: "Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso" description: "Le date EOL di PHP che contano nel 2026: 8.3 già security-only, 8.2 fuori dalla sicurezza a fine anno. Il piano di migrazione da avviare adesso, con checklist." canonical: "https://www.mauriziofonte.it/blog/post/scadenze-eol-php-2026-piano-migrazione-parte-adesso.html" author: "Maurizio Fonte" date: "2026-09-30T07:49:09+02:00" modified: "2026-09-30T07:49:09+02:00" section: "Refactoring" tags: ["Refactoring", "PHP"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [PHP](https://www.mauriziofonte.it/blog/cat/php.html) # [Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso](https://www.mauriziofonte.it/blog/post/scadenze-eol-php-2026-piano-migrazione-parte-adesso.html) Mercoledì 30 Settembre 2026, alle 07:49 ![Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso](https://www.mauriziofonte.it/image/005410200-scadenze-eol-php-2026-piano-migrazione-parte-adesso.jpg) 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](https://www.php.net/supported-versions.php): | Versione | Stato nel 2026 | Fine sicurezza | Cosa fare | | --- | --- | --- | --- | | 8.1 e precedenti | Fuori supporto | passata | Migrare con urgenza: sei già esposto | | 8.2 | Security-only | 31 dicembre 2026 | Pianificare la migrazione ora, scade a fine anno | | 8.3 | Security-only (errore frequente: NON è più attiva) | 31 dicembre 2027 | Va bene a breve, ma punta più in alto | | 8.4 | Supporto attivo (fino a fine 2026) | 31 dicembre 2028 | La destinazione consigliata | | 8.5 | Current stable | 31 dicembre 2029 | Per chi vuole la finestra più lunga | 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](https://www.mauriziofonte.it/pages/about) 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](https://www.mauriziofonte.it/blog/post/migrazione-php-74-a-83-llm-assisted-workflow.html), e per chi parte da molto lontano della [guida completa dalla 5.6 alla 8](https://www.mauriziofonte.it/blog/post/migrare-php-56-php-8-guida-completa-applicazioni-legacy-produzione.html). 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](https://www.mauriziofonte.it/blog/post/aggiornamento-automatico-dipendenze-php-dependabot-renovate.html): 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](https://www.mauriziofonte.it/blog/post/stack-tecnologico-pronto-2027-audit-strategico-titolari-responsabili-pmi.html). 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](https://www.mauriziofonte.it/pages/contattami): 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. Dall'articolo al lavoro vero Se il codice di cui parla questo articolo è il tuo Sviluppo su misura, modernizzazione di codice legacy, subentro su progetti senza documentazione. [Vedi tre interventi con i numeri](https://www.mauriziofonte.it/programmatore-php.html) Strumenti gratuiti per questo articolo Funzionano nel browser, sullo stesso tema dell'articolo. - [Migrazione database senza downtime](https://www.mauriziofonte.it/strumenti/migrazione-database-senza-downtime) - [Composer audit](https://www.mauriziofonte.it/strumenti/audit-composer) Ultima modifica: Mercoledì 30 Settembre 2026, alle 07:49 [« Articolo precedenteLaravel 13, il primo framework AI-native: cosa cambia davvero per una PMI29 Settembre 2026](https://www.mauriziofonte.it/blog/post/laravel-13-ai-native-features-cosa-cambia-pmi.html)[Articolo successivo »Cyber Resilience Act in pratica per una piccola software house1 Ottobre 2026](https://www.mauriziofonte.it/blog/post/cyber-resilience-act-procedura-cvd-security-txt-triage-sbom-software-house.html) ### Articoli correlati a Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso - [Lo stack tecnologico pronto per il 2027: audit strategico per titolari e responsabili PMI](https://www.mauriziofonte.it/blog/post/stack-tecnologico-pronto-2027-audit-strategico-titolari-responsabili-pmi.html) Lo stack che regge oggi può essere un rischio domani. Audit strategico per titolari e responsabili IT di una PMI in vista del 2027: quali versioni · 17 Settembre 2026 ![Lo stack tecnologico pronto per il 2027: audit strategico per titolari e responsabili PMI](https://www.mauriziofonte.it/image/005320070-stack-tecnologico-pronto-2027-audit-strategico-titolari-responsabili-pmi.jpg) - [Migrare da PHP 7.4 a 8.3: checklist per applicazioni legacy in produzione](https://www.mauriziofonte.it/blog/post/migrare-php-74-php-83-checklist-applicazioni-legacy-produzione.html) Migrare un'applicazione legacy da PHP 7.4 a 8.3 è un progetto di rischio gestito, non un aggiornamento al volo. Checklist concreta: i breaking · 31 Agosto 2026 ![Migrare da PHP 7.4 a 8.3: checklist per applicazioni legacy in produzione](https://www.mauriziofonte.it/image/005190070-migrare-php-74-php-83-checklist-applicazioni-legacy-produzione.jpg) - [Manutenzione preventiva delle applicazioni PHP: la checklist mensile per una PMI](https://www.mauriziofonte.it/blog/post/manutenzione-preventiva-applicazioni-php-checklist-mensile-pmi.html) Le applicazioni in produzione si degradano in silenzio finché non si rompono. Una checklist mensile di manutenzione preventiva per una PMI: audit · 16 Settembre 2026 ![Manutenzione preventiva delle applicazioni PHP: la checklist mensile per una PMI](https://www.mauriziofonte.it/image/005310070-manutenzione-preventiva-applicazioni-php-checklist-mensile-pmi.jpg) - [Cosa arriva in PHP 8.6 e se conviene aggiornare subito](https://www.mauriziofonte.it/blog/post/php-8-6-novita-partial-function-application-quando-aggiornare.html) Il 19 novembre esce PHP 8.6, e per la prima volta da anni la feature di punta non è zucchero sintattico: la partial function application chiude · 12 Novembre 2026 ![Cosa arriva in PHP 8.6 e se conviene aggiornare subito](https://www.mauriziofonte.it/image/005840070-php-8-6-novita-partial-function-application-quando-aggiornare.jpg) - [Debian 13.5 e i point release: come gestisco gli aggiornamenti di un parco VPS in produzione](https://www.mauriziofonte.it/blog/post/debian-13-5-point-release-aggiornamenti-parco-vps-produzione.html) Debian 13.5 16 maggio 2026 porta fix di sicurezza e stabilità, incluso quello dell'escape nspawn in systemd 257. Come gestisco gli aggiornamenti · 29 Luglio 2026 ![Debian 13.5 e i point release: come gestisco gli aggiornamenti di un parco VPS in produzione](https://www.mauriziofonte.it/image/004960070-debian-13-5-point-release-aggiornamenti-parco-vps-produzione.jpg) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/scadenze-eol-php-2026-piano-migrazione-parte-adesso.html Pubblicato: 2026-09-30 · Aggiornato: 2026-09-30. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.