Migrare un gestionale PHP 5.6 a PHP 8.4 senza riscriverlo: il caso di un e-commerce torinese con 12 anni di codice procedurale
Un e-commerce torinese 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. Continua a leggere
Ultima modifica:
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. 
Un gestionale PHP 7.0 ereditato da un freelance sparito: 43.000 righe di codice, nessuna documentazione, e il titolare che deve decidere se investire nella modernizzazione o riscrivere da zero. In 30 giorni ho prodotto un audit completo con PHPStan, Psalm, analisi delle dipendenze e una roadmap di intervento con costi e priorità. 
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 nuova funzionalità rispetto a un'applicazione moderna. In tre mesi di refactoring incrementale con Strangler Fig Pattern, PHPStan e Rector l'ho reso manutenibile senza riscrivere una riga da zero. 
Il gestionale logistico più critico di un'azienda piemontese di distribuzione alimentare non aveva test, non aveva pipeline, e i deploy si facevano via FileZilla il venerdì sera. In tre settimane ho portato il team da zero automazione a una pipeline GitHub Actions con PHPStan livello 5, Pest su 340 test, deploy atomico via webhook e rollback in 90 secondi. 
Quando lo sviluppatore originale è scomparso e il server VPS unmanaged è bloccato, il provider non risolve il problema al posto tuo: ti consegna gli strumenti - rescue mode, console KVM, log di sistema - ma sta a te (o a chi ti aiuta) usarli nel modo giusto. Il caso reale di un Hetzner AX41 lockato del cliente romano del 2025 e i comandi esatti che ho usato per recuperarlo in tre ore di lavoro. 
L'emergenza è passata, il sito gira di nuovo, gli accessi sono recuperati. Adesso cominciano i 90 giorni decisivi: o il debito tecnico viene misurato, prioritizzato e ripagato in modo strutturato, o tornerai a spegnere esattamente lo stesso incendio fra sei mesi. Il piano che applico nei tre mesi successivi a un subentro su server Hetzner o OVH, con metriche concrete, cadenza mensile e budget realistico per una PMI italiana che non ha un team DevOps dedicato. 
Quando lo sviluppatore sparisce e il business dipende da un'applicazione PHP su Hetzner, OVH o Aruba, le prime 72 ore decidono se il subentro va liscio o diventa un disastro. Il protocollo che applico: inventario accessi strutturato, recupero credenziali con i provider, codebase forensics su Git, stop-the-bleeding chirurgico e mappa del debito tecnico ereditato. Cinque fasi sequenziali con comandi concreti per riprendere il controllo di un progetto orfano. 
La differenza fra senior e junior non è il numero di anni: è un set di abitudini operative misurabili. Definition of done estesa, lettura prima di scrittura nel rapporto 10:1, refactoring incrementale del 10% per PR, KISS sopra cleverness, ADR scritti come codice di prima classe, regole non negoziabili su Git e migrazioni. Sei abitudini che difendo in ogni code review PMI e che abbattono il debito tecnico in modo misurabile nei tre-quattro mesi successivi. 
Molte PMI si affidano ad applicativi Symfony appesantiti da configurazioni legacy dei servizi. Scopri come autowiring e attributi PHP in Symfony 6/7 riducono il debito tecnico, migliorano la manutenibilità e preparano il codebase per gli aggiornamenti futuri.