--- title: "Perché dovresti abbandonare PHP 5 e passare subito a PHP 8: i rischi nascosti del codice obsoleto" description: "Usare ancora PHP 5 espone la tua azienda a gravi rischi di sicurezza e performance limitate. Scopri i benefici immediati della migrazione a PHP 8." canonical: "https://www.mauriziofonte.it/blog/post/rischi-codice-obsoleto-php8-vantaggi-sicurezza-performance.html" author: "Maurizio Fonte" date: "2025-05-23T07:18:12+02:00" modified: "2026-04-14T17:48:55+02:00" section: "Refactoring" tags: ["Refactoring", "Consulenza IT"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [Refactoring](https://www.mauriziofonte.it/blog/cat/refactoring.html) [Consulenza IT](https://www.mauriziofonte.it/blog/cat/consulenza_it.html) # [Perché dovresti abbandonare PHP 5 e passare subito a PHP 8: i rischi nascosti del codice obsoleto](https://www.mauriziofonte.it/blog/post/rischi-codice-obsoleto-php8-vantaggi-sicurezza-performance.html) Venerdì 23 Mag 2025, alle 07:18 ![Perché dovresti abbandonare PHP 5 e passare subito a PHP 8: i rischi nascosti del codice obsoleto](https://www.mauriziofonte.it/image/001260200-rischi-codice-obsoleto-php8-vantaggi-sicurezza-performance.jpg) Nei miei vent'anni di consulenza su applicativi PHP per PMI, ho gestito decine di migrazioni da PHP 5 a versioni moderne. L'intervento più critico ha riguardato un gestionale per un'azienda del settore manifatturiero: l'applicativo girava su PHP 5.6 con estensioni `mysql_*` (rimosse in PHP 7.0), nessun type hint, error handling basato su `@` e `die()`, e dipendenze Composer bloccate a versioni del 2016. Il server Debian su cui girava non riceveva più aggiornamenti di sicurezza dal 2020. La migrazione a PHP 8.3 ha richiesto otto settimane - riscrittura delle query con PDO, introduzione di tipizzazione strict, aggiornamento di tutte le dipendenze - ma i risultati sono stati immediati: tempo di risposta delle pagine ridotto del 40%, eliminazione di tre vulnerabilità SQL injection che esistevano da anni nel codice originale, e accesso all'ecosistema moderno di librerie e framework. ## Perché un applicativo su PHP 5 è un rischio concreto per la tua azienda? PHP 5.6, l'ultima release della serie 5.x, ha raggiunto l'End of Life il 31 dicembre 2018. Da quella data, nessuna vulnerabilità di sicurezza scoperta nel runtime PHP 5 viene corretta. Ma il problema non si ferma qui: l'intera serie PHP 7.x è anch'essa fuori supporto (PHP 7.4, l'ultima della serie, è EOL dal 28 novembre 2022), PHP 8.0 è EOL dal 26 novembre 2023, e PHP 8.1 ha perso il supporto di sicurezza il 31 dicembre 2025. Secondo la pagina ufficiale delle [versioni supportate di PHP](https://www.php.net/supported-versions.php), solo PHP 8.2 (security-only fino al 31 dicembre 2026), 8.3, 8.4 e 8.5 ricevono attualmente manutenzione. Questo significa che un applicativo su PHP 5.6 accumula oltre sette anni di vulnerabilità non corrette nel runtime. Ma il rischio non è solo teorico: [W3Techs](https://w3techs.com/technologies/details/pl-php) rileva che una percentuale non trascurabile di siti web gira ancora su PHP 5 e 7, e questi siti sono bersagli privilegiati perché le vulnerabilità sono note, documentate e facilmente sfruttabili. Le conseguenze concrete per una PMI: - Ogni CVE scoperta in PHP 5.x o 7.x resta aperta permanentemente - non esiste patch ufficiale - Le librerie Composer moderne richiedono PHP 8.1+ come versione minima, isolando l'applicativo dall'ecosistema - I framework Laravel (dalla versione 11) e Symfony (dalla versione 7) richiedono PHP 8.2+ - Il mancato aggiornamento del software che tratta dati personali può configurare una violazione del principio di sicurezza del GDPR (articolo 32) e dei requisiti NIS2 ## Le differenze tecniche tra PHP 5 e PHP 8 La distanza tra PHP 5.6 e PHP 8.x non è un semplice aggiornamento incrementale - è un cambio generazionale del linguaggio. I breaking change principali attraversano tre major version. Da PHP 5.6 a 7.0, le modifiche più impattanti sono state la rimozione completa delle funzioni `mysql_*` (sostituite da PDO e MySQLi), la rimozione dei tag ASP (`<%`), la nuova gestione delle variabili uniformi, e la promozione di molti errori fatali a eccezioni catchable. Un applicativo che usa `mysql_connect()` e `mysql_query()` richiede una riscrittura completa del layer di accesso al database. Da PHP 7.x a 8.0, i cambiamenti principali sono la promozione di warning a TypeError e ValueError (il codice che "funzionava con warning" ora genera eccezioni), l'introduzione di union types, named arguments, match expression, e la rimozione di funzioni legacy come `each()` e `create_function()`. PHP 8.1-8.5 aggiungono funzionalità che modernizzano radicalmente il linguaggio: enum, readonly properties e classi, fibre per la programmazione asincrona, e il JIT compiler che migliora significativamente le performance su workload computazionali. Ecco un confronto concreto dello stesso codice in PHP 5.6 e PHP 8.4: ```php prepare( 'SELECT id, status, total, created_at FROM orders WHERE id = :id' ); $stmt->execute(['id' => $orderId]); $row = $stmt->fetch(\PDO::FETCH_ASSOC); return match (true) { /* match expression (PHP 8.0+) */ $row === false => null, default => new OrderSummary( id: $row['id'], /* named arguments (PHP 8.0+) */ status: OrderStatus::from($row['status']), total: (float) $row['total'], createdAt: new \DateTimeImmutable($row['created_at']), ), }; } ``` In PHP 5.6, lo stesso codice richiederebbe classi con getter e setter manuali, nessun type hint sui parametri scalari, nessuna dichiarazione di tipo di ritorno, `mysql_query()` senza prepared statement, e switch/case al posto di match. Il codice PHP 8 è più sicuro (type safety), più leggibile (meno boilerplate), e più performante (ottimizzazioni del runtime). ## Il percorso di migrazione: strumenti e strategia Una migrazione da PHP 5.6 a PHP 8.x non si fa in un giorno, ma con gli strumenti giusti il processo è sistematico e gestibile. Il primo passo è l'analisi di compatibilità. [PHPCompatibility](https://github.com/PHPCompatibility/PHPCompatibility), un ruleset per PHP_CodeSniffer, scansiona il codice sorgente e identifica ogni incompatibilità con la versione target: funzioni rimosse, parametri cambiati, sintassi non più supportata. Il report risultante è la mappa precisa del lavoro necessario. Il secondo passo è la correzione automatizzata. [Rector](https://getrector.com/) analizza il codice e applica trasformazioni automatiche: converte `mysql_*` in PDO, aggiunge type hint, modernizza la sintassi. Con il set `LevelSetList::UP_TO_PHP_84`, Rector gestisce automaticamente la maggior parte delle trasformazioni meccaniche, lasciando il lavoro manuale concentrato sulla logica di business e sulle scelte architetturali. Il terzo passo è la validazione con analisi statica. [PHPStan](https://phpstan.org/) al livello massimo verifica la correttezza dei tipi, identifica codice morto e segnala potenziali errori runtime - una rete di sicurezza che intercetta i problemi introdotti dalla migrazione prima che raggiungano la produzione. Il workflow consigliato: PHPCompatibility scan → PHPStan al livello corrente → Rector `--dry-run` → revisione del diff → applicazione → PHPStan al livello target → test suite. Ho descritto strategie complementari per il [refactoring del codice PHP legacy](https://www.mauriziofonte.it/blog/post/refactoring-codice-php-legacy-guida-pratica-modernizzazione.html) e per l'[aggiornamento dei framework Symfony e Laravel](https://www.mauriziofonte.it/blog/post/aggiornamento-applicazioni-php-legacy-symfony-3-4-7-laravel-5-8-11-12-sicurezza-performance-pmi.html). ## Performance: i numeri della migrazione Le migliorie di performance non sono un argomento di marketing - sono misurabili. I [benchmark di Kinsta](https://kinsta.com/blog/php-benchmarks/) su workload reali (WordPress, Laravel, Symfony) mostrano che il passaggio da PHP 7.4 a 8.x produce circa il 5% di incremento nel throughput con una riduzione del 27% nell'uso di memoria per worker. Su workload computazionali intensivi, il JIT compiler di PHP 8.x produce miglioramenti fino all'82% su Laravel e al 95% su Symfony. Per un applicativo che serve centinaia di richieste al minuto, la riduzione del 27% di memoria per worker significa poter servire più richieste concorrenti con lo stesso hardware - o ridurre le risorse server mantenendo le stesse performance. Combinato con il [refactoring delle query database](https://www.mauriziofonte.it/blog/post/audit-sicurezza-php-legacy-guida-pratica-vulnerabilita.html) e l'ottimizzazione dell'infrastruttura, la migrazione a PHP 8 può trasformare radicalmente il profilo di costo e performance di un applicativo legacy. Ogni mese in cui un applicativo resta su PHP 5 o PHP 7 è un mese in cui accumula debito tecnico, rischio di sicurezza e distanza dall'ecosistema moderno. Gli strumenti per la migrazione esistono, sono maturi e automatizzano la parte meccanica del lavoro. Per conoscere il mio approccio alla modernizzazione di applicativi PHP, visita [la mia pagina professionale](https://www.mauriziofonte.it/pages/about). Se il tuo applicativo critico gira su una versione PHP fuori supporto e vuoi pianificare una migrazione sicura, [contattami per una consulenza dedicata](https://www.mauriziofonte.it/pages/contattami) - partiamo dall'analisi di compatibilità del tuo codebase. 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) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [« Articolo precedenteHardening dei server: come proteggere la tua azienda da attacchi informatici devastanti22 Mag 2025](https://www.mauriziofonte.it/blog/post/hardening-server-protezione-attacchi-informatici.html)[Articolo successivo »GDPR e NIS2: perché ignorare la compliance normativa può distruggere il tuo business23 Mag 2025](https://www.mauriziofonte.it/blog/post/gdpr-nis2-rischi-non-compliance-normativa.html) ### Articoli correlati a Perché dovresti abbandonare PHP 5 e passare subito a PHP 8: i rischi nascosti del codice obsoleto - [Migrare un gestionale PHP 5.6 a PHP 8.4 senza riscriverlo: il caso reale di un e-commerce B2B con 12 anni di codice procedurale](https://www.mauriziofonte.it/blog/post/migrare-php-56-php-8-guida-completa-applicazioni-legacy-produzione.html) Un e commerce B2B con 47.000 righe di PHP 5.6 procedurale, 340 chiamate mysql connect , un hosting che aveva annunciato la rimozione di PHP 5.6 · 11 Marzo 2026 ![Migrare un gestionale PHP 5.6 a PHP 8.4 senza riscriverlo: il caso reale di un e-commerce B2B con 12 anni di codice procedurale](https://www.mauriziofonte.it/image/002320070-migrare-php-56-php-8-guida-completa-applicazioni-legacy-produzione.jpg) - [Refactoring del codice PHP legacy: guida pratica per modernizzare un'applicazione senza riscriverla](https://www.mauriziofonte.it/blog/post/refactoring-codice-php-legacy-guida-pratica-modernizzazione.html) Un gestionale PHP 5.6 con 23.000 righe, zero test e debito tecnico che rendeva ogni modifica un rischio: il cliente pagava il triplo per ogni · 5 Settembre 2025 ![Refactoring del codice PHP legacy: guida pratica per modernizzare un'applicazione senza riscriverla](https://www.mauriziofonte.it/image/002250070-refactoring-codice-php-legacy-guida-pratica-modernizzazione.jpg) - [Dal vecchio mysql_ a mysqli e PDO: come si fa davvero il porting nel 2026](https://www.mauriziofonte.it/blog/post/porting-funzioni-mysql-verso-mysqli-php.html) Le funzioni mysql di PHP sono deprecate dalla 5.5 e rimosse dalla 7.0. Un'applicazione che le contiene ancora gira per forza su una versione · 20 Mag 2026 ![Dal vecchio mysql_ a mysqli e PDO: come si fa davvero il porting nel 2026](https://www.mauriziofonte.it/image/000290070-porting-funzioni-mysql-verso-mysqli-php.jpg) - [Refactoring del codice legacy: perché la tua azienda ne ha bisogno per sopravvivere](https://www.mauriziofonte.it/blog/post/refactoring-codice-legacy-importanza-strategica.html) Ignorare il refactoring del codice legacy limita crescita e sicurezza aziendale. Scopri perché questa attività è fondamentale per migliorare · 26 Mag 2025 ![Refactoring del codice legacy: perché la tua azienda ne ha bisogno per sopravvivere](https://www.mauriziofonte.it/image/001280070-refactoring-codice-legacy-importanza-strategica.jpg) - [Aggiornare applicazioni PHP legacy: confrontare la transizione da Symfony 3.4 a Symfony 7 e da Laravel 5.8 a Laravel 11/12 per la sicurezza e le performance dei software PMI](https://www.mauriziofonte.it/blog/post/aggiornamento-applicazioni-php-legacy-symfony-3-4-7-laravel-5-8-11-12-sicurezza-performance-pmi.html) Molte PMI si affidano ad applicativi PHP basati su Symfony 3.4 o Laravel 5.8, framework privi di supporto attivo per la sicurezza. Questo articolo · 24 Gennaio 2025 ![Aggiornare applicazioni PHP legacy: confrontare la transizione da Symfony 3.4 a Symfony 7 e da Laravel 5.8 a Laravel 11/12 per la sicurezza e le performance dei software PMI](https://www.mauriziofonte.it/image/001170070-aggiornamento-applicazioni-php-legacy-symfony-3-4-7-laravel-5-8-11-12-sicurezza-performance-pmi.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, "Perché dovresti abbandonare PHP 5 e passare subito a PHP 8: i rischi nascosti del codice obsoleto", mauriziofonte.it, 2025. https://www.mauriziofonte.it/blog/post/rischi-codice-obsoleto-php8-vantaggi-sicurezza-performance.html Pubblicato: 2025-05-23 · Aggiornato: 2026-04-14. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.