Migrare a PHP 8.4: guida per aziende con codice legacy

Se la tua applicazione gira ancora su PHP 7.4 o PHP 8.0, stai usando un motore che non riceve più nemmeno le patch di sicurezza. Non è una questione teorica: è la porta d'ingresso più usata dagli attacchi automatizzati e, sempre più spesso, un motivo di esclusione nei questionari di conformità dei clienti corporate. In questa guida vediamo perché conviene migrare a PHP 8.4, cosa si rompe davvero, come farlo senza fermare l'attività e quanto costa realisticamente.

Lo stato del supporto: dove sei oggi

La regola pratica per un'azienda: stare sempre entro le due versioni più recenti. Chi si aggiorna a piccoli passi ogni anno spende poco ogni volta. Chi salta cinque versioni si ritrova a gestire un progetto di migrazione vero, con analisi, test e rischi. Il costo totale non è lineare: cresce con il ritardo accumulato.

Perché migrare: i tre argomenti che convincono la direzione

1. Sicurezza

Una versione fuori supporto significa che ogni nuova vulnerabilità dell'interprete resta aperta per sempre. Gli attacchi contro applicazioni PHP obsolete sono in larga parte automatizzati: non serve essere un bersaglio interessante, basta essere raggiungibili. Se gestisci dati di clienti, l'articolo su le best practice di sicurezza PHP spiega perché la versione dell'interprete è il primo anello della catena, non l'ultimo.

2. Performance e costi di hosting

Il salto da PHP 7.4 a PHP 8.x porta miglioramenti concreti di throughput grazie al JIT e a numerose ottimizzazioni interne. Su applicazioni con molto lavoro applicativo — gestionali, e-commerce con cataloghi ampi, generazione di report — si osservano riduzioni sensibili dei tempi di risposta a parità di hardware. Tradotto: meno risorse server per servire lo stesso traffico, e un TTFB migliore che si riflette sui Core Web Vitals.

3. Manutenibilità e costo del cambiamento

Le versioni moderne offrono tipi più espressivi, enum, readonly, costruttori promossi e match: strumenti che riducono il codice difensivo e fanno emergere gli errori in fase di sviluppo invece che in produzione. Un codice più tipizzato è più economico da modificare, e questo si vede sulla bolletta della manutenzione ordinaria.

Cosa si rompe davvero: i breaking change che contano

Il 90% dei problemi di una migrazione da PHP 7.4 rientra in un elenco corto e prevedibile:

• Passaggio di null a parametri non nullable delle funzioni interne: era un avviso, oggi è deprecato o fatale. È di gran lunga la causa più frequente di errori dopo l'aggiornamento, tipicamente in htmlspecialchars, trim, str_replace su valori provenienti dal database
• Proprietà dinamiche deprecate: assegnare una proprietà mai dichiarata su una classe genera deprecazioni e in futuro sarà un errore. Colpisce soprattutto vecchi ORM artigianali e classi "contenitore"
• Confronti tra stringhe e numeri più rigorosi: 0 == "testo" non è più vero. Cambia il comportamento di validazioni scritte in modo permissivo
• Errori invece di warning su molte operazioni scorrette (accesso a offset di tipi non validi, argomenti errati)
• Estensioni rimosse o separate: mysql_* non esiste da tempo, altre estensioni sono uscite dal core e vanno installate a parte
• Firme di metodi che devono rispettare la compatibilità con le interfacce interne, spesso un problema in classi che implementano ArrayAccess o Iterator
• Librerie di terze parti obsolete: quasi sempre il vero collo di bottiglia non è il tuo codice, ma una dipendenza abbandonata anni fa

Il metodo: sei fasi, zero sorprese

Fase 1 - Inventario

Prima di toccare qualsiasi cosa: quante righe di codice, quali framework e in quale versione, quali librerie esterne, quali estensioni PHP attive, quali integrazioni esterne, quali cron. In questa fase emergono gli scheletri nell'armadio: script dimenticati, aree del gestionale usate una volta l'anno, dipendenze non più mantenute.

Fase 2 - Analisi statica

Strumenti come PHPCompatibility, PHPStan e Rector producono l'elenco puntuale delle incompatibilità prima ancora di eseguire il codice. È la fase che trasforma la migrazione da scommessa a preventivo: si sa quanti punti vanno toccati e di che natura sono.

Fase 3 - Rete di sicurezza sui test

Se non esistono test automatici, non serve scrivere una suite completa: bastano test di integrazione sui flussi che generano fatturato (login, ordine, pagamento, emissione documenti). Sono economici da scrivere e coprono il rischio dove fa più male. Il ragionamento completo è in test automatici in PHP: da dove iniziare.

Fase 4 - Aggiornamento delle dipendenze

Si aggiornano prima le librerie, poi l'interprete. Farlo nell'ordine inverso significa inseguire due classi di errori contemporaneamente senza sapere quale causa quale.

Fase 5 - Staging identico alla produzione

Un ambiente di prova con la stessa versione PHP di destinazione, le stesse estensioni e una copia recente dei dati reali (anonimizzati dove serve). La maggior parte dei bug di migrazione dipende dai dati, non dal codice: campi nulli, encoding storici, record creati da versioni dell'applicazione ormai dismesse.

Fase 6 - Rilascio con via di ritorno

Rilascio in una finestra a basso traffico, log delle deprecazioni attivo, monitoraggio degli errori per le prime 72 ore e possibilità di tornare indietro rapidamente. Se l'hosting permette di cambiare versione PHP per singolo sito, il rollback si misura in minuti.

Quanto costa e quanto dura

Gli ordini di grandezza che vedo più spesso su progetti reali:

• Sito vetrina o WordPress con pochi plugin custom: da mezza giornata a due giornate
• Applicazione PHP su framework moderno e aggiornato: 2-5 giornate, la parte più lunga è la verifica
• Gestionale su misura da 7.4, con codice stratificato e senza test: 10-25 giornate, distribuite su 4-8 settimane per non fermare l'operatività
• Applicazione con framework fuori supporto (es. vecchie versioni di CodeIgniter o framework proprietari): qui la domanda cambia, e diventa quella affrontata in rifare o rifattorizzare un software legacy

Un riferimento utile per confronto: la migrazione costa quasi sempre meno di un singolo incidente di sicurezza, e molto meno di una riscrittura. Il conto vero, con i costi indiretti, è quello descritto in quanto costano davvero i bug in produzione.

Il caso WordPress

Su WordPress il core è compatibile con le versioni recenti di PHP da tempo: il rischio si concentra nei plugin abbandonati e nei temi commerciali datati. Procedura consigliata: attiva un plugin di controllo compatibilità, aggiorna tutto in staging, cambia versione PHP, verifica le pagine chiave e i form. Se un plugin non è aggiornato da due anni, la migrazione è l'occasione giusta per sostituirlo, non per costruirci sopra un'altra deroga.

Errori da evitare

• Cambiare la versione PHP direttamente dal pannello dell'hosting in produzione "per vedere che succede": succede che il sito va offline nel momento peggiore
• Migrare e ristrutturare insieme: due cambiamenti sovrapposti rendono impossibile capire cosa ha rotto cosa. Prima si migra a parità di funzioni, poi si migliora
• Ignorare i cron e gli script fuori dal web: import notturni, invii massivi e generazione di report girano con la stessa versione PHP e falliscono in silenzio
• Non spegnere la visualizzazione degli errori in produzione dopo il rilascio: le deprecazioni finiscono a video e diventano un problema di sicurezza e di immagine
• Dimenticare il file di configurazione del server: limiti di memoria, tempo di esecuzione e dimensione degli upload vanno riportati nella nuova versione

Domande frequenti

Posso restare su PHP 7.4 pagando un supporto esteso?

Esistono servizi commerciali di patch di sicurezza per versioni fuori supporto. Sono una soluzione tampone accettabile solo se hai già una data di migrazione fissata: come strategia permanente costano più della migrazione stessa e non risolvono l'obsolescenza delle librerie.

Il sito resterà offline durante la migrazione?

No, se si lavora in staging. Il passaggio in produzione richiede in genere pochi minuti di finestra tecnica, spesso a traffico zero.

Come faccio a sapere se sono a rischio, oggi?

La versione PHP è visibile nel pannello dell'hosting, o via una pagina di diagnostica temporanea. Se il numero inizia per 7, la risposta è sì e la priorità è alta.

MameTech: migrazioni PHP senza fermare l'azienda

Migro applicazioni PHP e gestionali su misura verso le versioni supportate del linguaggio, con analisi statica preventiva, test sui flussi critici e rilascio reversibile. Lavoro da remoto con PMI e web agency in tutta Italia, anche in modalità white-label per chi ha già un fornitore di riferimento. Contattami per una valutazione gratuita della tua situazione: in mezza giornata so dirti cosa serve e quanto costa.