Restare su una versione di PHP fuori supporto sembra la scelta più economica. Il server costa quello che costava, l’applicazione funziona, il preventivo di migrazione è una cifra concreta da approvare oggi mentre i rischi sono ipotetici e lontani. Per questo, quando si confrontano le due strade, la migrazione perde spesso in partenza: si confronta un costo certo con un costo che nessuno ha mai calcolato.
In questo articolo proviamo a rendere visibile quel costo. Non pubblichiamo percentuali o medie di settore, perché ogni azienda ha numeri suoi e quelle che circolano raramente sono confrontabili. Proponiamo invece un modello in tre voci, rischio, tempo e debito tecnico, con le formule per stimarle, le fonti da cui ricavare i dati e un esempio dichiaratamente inventato per mostrare come si usa. Alla fine il modello serve a una cosa sola: presentare alla direzione una decisione informata.
Perché il costo non si vede
I costi visibili di un’applicazione legacy sono quelli che arrivano in fattura: hosting, canone di manutenzione, eventuali licenze. Sono stabili, facili da confrontare e spesso bassi. Gli altri sono distribuiti in voci di bilancio diverse, o non compaiono affatto: le ore che un tecnico interno dedica a tenere in piedi il sistema, l’intervento notturno per un’urgenza, il progetto rinviato perché la libreria richiesta non gira sulla versione in uso, il rischio di un incidente che non si è ancora verificato.
C’è poi un effetto temporale. Ogni anno su un ramo fuori supporto si accumulano nuove vulnerabilità senza correzione ufficiale, le librerie si allontanano e le persone che conoscono il codice cambiano lavoro. Il costo di restare cresce, e con lui cresce il costo della migrazione che si sta rinviando.
Prima voce: il rischio
Il rischio si esprime come perdita attesa: la probabilità che in un anno si verifichi un incidente, moltiplicata per il suo impatto. Nessuno dei due fattori è noto con precisione, ed è normale. L’errore è rinunciare alla stima per questo motivo, perché così si usa implicitamente una probabilità pari a zero.
L’impatto
L’impatto è la parte più stimabile, perché si compone di voci che l’azienda conosce:
- fermo: ore di indisponibilità moltiplicate per il margine che il sistema genera o protegge in un’ora;
- ripristino: analisi forense, ricostruzione dei server, recupero dei dati, ore interne ed esterne;
- obblighi: notifica al Garante, ove possibile entro 72 ore, se sono coinvolti dati personali (art. 33 del GDPR), notifiche al CSIRT Italia per i soggetti NIS2, consulenze legali;
- conseguenze: sanzioni, penali contrattuali, clienti persi. Per le sanzioni le norme indicano soglie massime, utili solo come ordine di grandezza del caso peggiore.
La probabilità
La probabilità si stima per intervalli. I fattori che la spostano sono noti: quanto il sistema è esposto su Internet, da quanto tempo il ramo è fuori supporto, quante vulnerabilità pubblicate riguardano davvero la configurazione in uso, se esistono exploit pubblici. Due fonti ufficiali aiutano a ragionare su basi concrete: il catalogo delle vulnerabilità sfruttate della CISA, che elenca le CVE per cui esiste evidenza di sfruttamento reale, e il punteggio EPSS di FIRST, che stima la probabilità di sfruttamento di ogni CVE nei trenta giorni successivi.
Seconda voce: il tempo
Il tempo è la voce più sottovalutata perché è già pagata, sotto forma di stipendi e di contratti a ore. Si misura raccogliendo, per qualche mese, le ore dedicate a:
- verificare e applicare correzioni a mano, o cercare soluzioni alternative quando la correzione non esiste;
- gestire urgenze, spesso fuori orario e quindi con un costo maggiore;
- rispondere a scanner, questionari dei clienti e auditor che segnalano la versione obsoleta;
- adattare configurazioni del sistema operativo per tenere in vita pacchetti datati;
- spiegare internamente perché una richiesta non si può fare “su questo sistema”.
Se le ore non sono registrate, una stima ragionevole si ottiene chiedendo alle persone coinvolte quante ne hanno dedicate nell’ultimo trimestre, con un intervallo minimo e massimo.
Terza voce: il debito tecnico
Il debito tecnico è il sovraccosto che si paga su ogni modifica perché il codice e la piattaforma sono vecchi. Come per un debito finanziario, c’è un capitale, cioè il lavoro necessario per aggiornare, e ci sono gli interessi, cioè il tempo in più speso ogni volta che si interviene. Gli interessi si vedono in tre modi:
- modifiche più lente: senza test automatici e con librerie datate, ogni intervento richiede più verifiche manuali e più cautela;
- opportunità bloccate: un SDK di pagamento, un connettore o una libreria che richiedono una versione di PHP più recente non si possono adottare;
- competenze più costose: trovare chi lavori volentieri su codice e strumenti fuori supporto è sempre più difficile.
La stima pratica è il numero di modifiche fatte in un anno moltiplicato per il sovraccosto medio di ciascuna, che chi sviluppa sa indicare con un intervallo onesto confrontando interventi simili su sistemi aggiornati.
Il modello completo
La tabella riassume dove trovare i dati per ogni fattore.
| Fattore | Come si stima | Fonte del dato |
|---|---|---|
| Probabilità (P) | intervallo annuo, rivisto ogni trimestre | esposizione, CVE applicabili, catalogo CISA, EPSS |
| Impatto (I) | somma di fermo, ripristino, obblighi, conseguenze | margini, contratti, piano di continuità |
| Ore (H) | ore registrate o stimate su un trimestre | sistema di ticket, interviste |
| Tariffa (T) | costo orario pieno, interno o esterno | amministrazione, contratti |
| Modifiche (M) | interventi all’anno sull’applicazione | storico del repository e dei ticket |
| Sovraccosto (S) | tempo in più per intervento | confronto con interventi simili su sistemi aggiornati |
Un esempio con numeri inventati
Per mostrare il metodo, immaginiamo un gestionale esposto su Internet. I valori che seguono sono di fantasia e non descrivono un caso reale. Il reparto IT stima tra 60 e 120 ore all’anno di gestione legata alla versione obsoleta. Gli sviluppatori registrano una ventina di interventi all’anno, ciascuno con un sovraccosto stimato tra 2 e 6 ore. Il tempo e il debito tecnico valgono quindi, insieme, tra 100 e 240 ore all’anno, da moltiplicare per la tariffa oraria.
Per il rischio, il gruppo di lavoro stima l’impatto di un incidente grave partendo da tre giorni di fermo, dal costo di ricostruzione e dalle notifiche, e assegna alla probabilità annua un intervallo prudente. Il prodotto si aggiunge alle ore. Il totale, espresso come intervallo, è il costo annuo di restare. Confrontato con la stima della migrazione, dà il numero di anni in cui la migrazione si ripaga. Con intervalli ampi il risultato sarà ampio anch’esso, e va bene: indica già se la decisione è chiara o se conviene approfondire una voce in particolare.
Per la stima del costo della migrazione rimandiamo all’articolo su come stimare tempi e costi della migrazione di un gestionale.
Gli errori più comuni
- Contare solo la fattura. Il confronto tra canone attuale e preventivo di migrazione ignora le tre voci che contano di più.
- Confondere “non è successo” con “non succede”. L’assenza di incidenti negli anni passati dice poco sulla probabilità futura, soprattutto quando le vulnerabilità aperte aumentano.
- Usare il caso peggiore come valore atteso. Le sanzioni massime spaventano ma distorcono il calcolo; vanno indicate a parte come scenario estremo.
- Ragionare sui soldi già spesi. Nella decisione conta il costo da qui in avanti; quanto è costato sviluppare il sistema è già speso.
- Dimenticare il periodo di transizione. Una migrazione dura mesi; nel frattempo il sistema va protetto, e anche questo costo va messo in conto.
Come presentarlo alla direzione
Il risultato va portato a chi decide in una pagina: le tre voci con i loro intervalli, le ipotesi principali, il costo della migrazione, gli anni di rientro e le opzioni. Le opzioni di solito sono tre: migrare subito, migrare in un periodo definito proteggendo nel frattempo la produzione con il backport delle patch, oppure accettare il rischio per un tempo limitato con una data di revisione. Le confrontiamo nel dettaglio nell’articolo backport o migrazione.
Per le organizzazioni soggette alla NIS2 questo passaggio è anche un obbligo: il decreto italiano attribuisce agli organi di amministrazione l’approvazione delle misure di gestione dei rischi e la responsabilità delle violazioni. Una decisione documentata, con numeri e ipotesi, è la base per dimostrarlo.
In breve
Il costo di un PHP legacy va ben oltre la fattura dell’hosting e si divide in tre voci che si possono stimare: il rischio, come probabilità annua per impatto di un incidente; il tempo, come ore di gestione manuale, urgenze e audit per la tariffa; il debito tecnico, come numero di modifiche per il sovraccosto di ciascuna. Ogni fattore va espresso come intervallo, con le fonti e le ipotesi scritte accanto: catalogo CISA ed EPSS per la probabilità, piani di continuità e contratti per l’impatto, ticket e repository per tempo e modifiche. La somma dà il costo annuo di restare, il confronto con la migrazione dà gli anni di rientro. Il modello lascia la decisione a chi la deve prendere e gli permette di basarla su numeri dichiarati.
