Le scadenze EOL di PHP che contano nel 2026: il piano di migrazione che parte adesso
Le scadenze EOL di PHP non sono un dettaglio da sysadmin: sono una leva di rischio per chi resta indietro. Lo stato reale nel 2026, con le date dal dossier: 8.3 già in security-only, 8.4 in supporto attivo fino a fine anno, 8.2 fuori dalla sicurezza a fine 2026. Il piano di migrazione da avviare adesso per chi è su 8.2 o 8.3: checklist, deprecazioni da gestire, test, e perché aspettare l'ultimo trimestre è la scelta più costosa. Continua a leggere
Ultima modifica:
I controller gonfi sono il debito tecnico più comune in Laravel, ma la cura non è astrarre tutto. Come applicare i principi SOLID in modo pragmatico: spostare la logica di business in un service layer, dove la separazione paga davvero e dove invece aggiunge solo indirezione. Refactoring concreto da un controller reale, con i tradeoff dichiarati: la testabilità che guadagni contro la complessità che introduci. 
Saltare da Laravel 9 a 12 non è un singolo upgrade ma una sequenza, e il lavoro vero spesso non è nel framework ma nel salto della versione PHP minima richiesta. Guida pratica per la produzione: i breaking changes che contano versione per versione, cosa testare prima del deploy, e perché zero breaking changes dichiarati non significa zero differenze comportamentali. Strategia incrementale da un'applicazione reale. 
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 changes che mordono davvero, le deprecazioni da intercettare prima del deploy, la strategia incrementale per non fermare la produzione e la suite di test che fa da rete. Con le date EOL aggiornate, perché restare su 7.4 nel 2026 non è più un'opzione di sicurezza. 
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 di PHP fuori supporto da circa dieci anni: non un problema di stile, ma una falla di sicurezza che cammina. Questo articolo rifà la guida al porting con l'occhio del 2026: cosa fa un convertitore automatico e dove ti lascia scoperto, mysqli o PDO, e perché la posta in gioco non è la deprecazione ma l'SQL injection che il vecchio codice si porta dietro. 
La prima settimana su un progetto legacy è sempre disorientante. Ho sviluppato un processo sistematico di audit tecnico in 5 fasi: analisi statica con PHPStan, complessità ciclomatica con PHP Metrics, mappa delle dipendenze esterne, test di copertura esistente e interviste al team. Output: un report con priorità chiare. 
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 entro 60 giorni, e un titolare che non poteva permettersi downtime. In quattro settimane l'ho migrato a PHP 8.4 senza riscrivere l'applicazione: ecco il metodo, gli strumenti, le breaking changes reali e le decisioni che hanno fatto la differenza. 
Ho migrato tre applicazioni da Symfony 5 a Symfony 7 in produzione. Il percorso non è una singola migrazione: si passa per Symfony 6 gestendo ogni set di deprecation progressivamente. Vi racconto i breaking change che mi hanno sorpreso di più, le scorciatoie che non funzionano e il processo sistematico che uso. 
Migrare 200.000 righe di PHP da 7.4 a 8.3 manualmente è un progetto da 2-3 mesi. Con un workflow LLM-assisted scende a 2-3 settimane senza sacrificare qualità. Nella mia pipeline combino Rector per le trasformazioni meccaniche, Claude per i breaking change complessi, test caratterizzanti generati dal LLM, regression testing incrementale. Ti mostro il workflow reale con tempi giornalieri e le trappole tipiche. 
Un CTO mi ha chiesto di convincere il suo CEO a investire in refactoring. Ho costruito un modello di costo basato su dati reali: tempo medio per aggiungere una feature, numero di bug per rilascio, costo orario del team. Il debito tecnico costava all'azienda 180.000€/anno in produttività persa. Il CEO ha approvato.