Software PHP Legacy: rifare da zero o rifattorizzare?

Prima o poi arriva quella riunione: il gestionale che l'azienda usa da dodici anni fa quello che deve fare, ma ogni modifica costa una fortuna, nessuno vuole più metterci le mani e il fornitore originale non esiste più. La domanda che segue è sempre la stessa: rifare da zero o sistemare l'esistente? È una decisione che vale decine di migliaia di euro e che in buona parte dei casi viene presa sull'onda dell'emozione. Ecco i criteri per prenderla con la testa.

Perché la riscrittura è più rischiosa di quanto sembri

La riscrittura totale è la scelta che seduce di più: pagina bianca, tecnologie moderne, niente compromessi. È anche quella che fallisce più spesso, per tre ragioni ricorrenti:

• Il vecchio software sa cose che nessuno ricorda. Dentro quelle righe illeggibili ci sono dodici anni di eccezioni, casi particolari e correzioni nate da problemi reali. Nessuno le ha documentate e nessuno se le ricorda tutte — finché non spariscono
• Durante la riscrittura il vecchio sistema continua a evolvere. L'azienda non si ferma: arrivano nuove esigenze e vanno implementate due volte, o il nuovo nasce già indietro
• Il valore arriva tutto alla fine. Per mesi si spende senza che nessuno in azienda veda nulla. Quando il progetto sfora, la direzione si trova a scegliere tra fermarlo perdendo l'investito o continuare a finanziare qualcosa che non ha ancora prodotto un solo beneficio

Quando invece la riscrittura è la scelta giusta

• La tecnologia di base è irrecuperabile: un framework proprietario abbandonato, o codice che non gira su nessuna versione supportata di PHP e non è aggiornabile a costi ragionevoli
• Il modello dei dati è sbagliato alla radice: se la struttura del database non regge i processi attuali dell'azienda, ogni funzione nuova è una forzatura sopra la precedente
• I requisiti sono cambiati completamente: il software risolve un problema che l'azienda non ha più
• Il sistema è piccolo: sotto una certa dimensione riscrivere costa meno che capire. La soglia pratica si aggira intorno alle poche migliaia di righe
• Esiste un rischio di sicurezza non sanabile e i dati trattati sono sensibili

Quando conviene rifattorizzare

• Il software funziona e l'azienda lo usa tutti i giorni: c'è valore in produzione da preservare
• I problemi sono concentrati in alcune aree, mentre il resto è stabile e non dà fastidio a nessuno
• La base tecnologica è ancora supportata, o portabile con una migrazione di versione
• Il modello dei dati regge, anche se il codice attorno è disordinato
• Il budget non permette un progetto lungo senza risultati intermedi — che è la condizione della maggior parte delle PMI

Il metodo che funziona quasi sempre: sostituzione progressiva

Esiste una terza via, ed è quella che consiglio nella grande maggioranza dei casi reali. Il nuovo sistema cresce attorno al vecchio e ne assorbe una funzione per volta, finché il vecchio non resta senza compiti e si spegne. In pratica:

• Si mette una facciata davanti al sistema esistente: le richieste passano da un livello che decide se servirle con il vecchio codice o con il nuovo
• Si sceglie il primo modulo da sostituire: quello con il miglior rapporto tra valore per l'azienda e rischio. Spesso è la parte che oggi produce più lamentele
• Si riscrive quel modulo su base moderna, mantenendo lo stesso database o introducendo una sincronizzazione controllata
• Si dirotta il traffico sul nuovo modulo, con possibilità immediata di tornare indietro
• Si ripete, un modulo alla volta, finché il vecchio sistema non serve più

I vantaggi sono concreti: valore consegnato ogni poche settimane invece che a fine progetto, rischio distribuito, possibilità di fermarsi in qualunque momento con un risultato comunque utile, e conoscenza del vecchio sistema che si recupera per gradi invece che tutta insieme. È lo stesso principio del rilascio a fasi descritto in questo caso studio e in come digitalizzare senza bloccare il lavoro.

Come si decide: sei domande, una risposta

Se le risposte sono miste — ed è il caso più comune — la sostituzione progressiva è quasi sempre la strada giusta.

Le prime cose da fare, in qualunque scenario

• Mettere sotto controllo di versione il codice, se non lo è già. Capita ancora di trovare gestionali che vivono solo sul server di produzione, ed è la condizione più pericolosa in assoluto
• Creare un ambiente di prova con dati realistici e anonimizzati
• Scrivere test sui flussi che generano fatturato, non su tutto: sono la rete che permette di modificare senza paura
• Attivare log ed errori tracciati: senza visibilità si lavora alla cieca
• Mappare le integrazioni esterne: sono i vincoli che decidono le priorità di sostituzione
• Documentare il comportamento reale, non quello dichiarato nel manuale del 2014

Sono attività che costano poche giornate, servono in entrambi gli scenari e sono il modo migliore per iniziare a lavorare mentre la decisione strategica matura.

Ordini di grandezza

• Messa in sicurezza e visibilità (versionamento, ambiente di prova, log, test essenziali): 5-10 giornate
• Refactoring mirato di un'area problematica: 10-20 giornate
• Sostituzione progressiva di un gestionale di media complessità: 40-100 giornate distribuite su 12-24 mesi, con valore consegnato lungo tutto il percorso
• Riscrittura completa: da 60 giornate in su, con nessun beneficio operativo fino al rilascio

Una nota sui costi che spesso non compare nei preventivi: mantenere un sistema legacy ha un costo ricorrente fatto di modifiche più lente, errori più frequenti e opportunità commerciali non colte perché "il gestionale non lo permette". Vale la pena stimarlo, perché è il termine di paragone corretto per qualsiasi investimento di ammodernamento.

Domande frequenti

Il fornitore originale non c'è più. Siamo bloccati?

No, se avete accesso a codice, database e credenziali. Un'analisi tecnica di qualche giorno permette a un nuovo fornitore di prendere in carico il sistema. Se invece manca l'accesso al codice, il problema è contrattuale prima che tecnico: è la ragione per cui la proprietà del codice va scritta nel contratto.

Possiamo cambiare tecnologia strada facendo?

Sì, ed è uno dei vantaggi della sostituzione progressiva: i nuovi moduli nascono su base moderna mentre il vecchio continua a servire il resto. La condizione è che i due mondi condividano l'autenticazione e una sorgente di verità sui dati.

Quanto tempo serve per capire cosa fare?

Un audit tecnico serio su un gestionale di media complessità richiede 3-5 giornate e produce una fotografia utilizzabile: stato del codice, rischi di sicurezza, qualità del modello dati, aree critiche e una strada consigliata con stime. È l'investimento che evita di scegliere a intuito.

E se l'azienda non può fermarsi nemmeno un giorno?

È la norma, non l'eccezione — e proprio per questo la sostituzione progressiva è nata. Ogni passaggio è reversibile e il vecchio sistema resta disponibile finché il nuovo non ha dimostrato di funzionare.

MameTech: ammodernamento di applicazioni PHP esistenti

Prendo in carico gestionali e applicazioni PHP ereditate da altri fornitori: audit tecnico, messa in sicurezza, refactoring mirato e sostituzione progressiva verso Yii2, senza fermare l'operatività aziendale. Codice, repository e credenziali sempre di proprietà del cliente. Lavoro con PMI e web agency in tutta Italia, anche in modalità white-label. Contattami per una prima valutazione gratuita del tuo software: ti dico con franchezza se conviene sistemarlo o rifarlo.