"Funziona, non lo tocchiamo." È una frase che sentiamo spesso. E in un certo senso è comprensibile: cambiare un sistema che regge i processi aziendali fa paura, costa, richiede tempo. Meglio lasciarlo stare.
Il problema è che il software legacy non sta fermo. Invecchia, e invecchiando accumula costi che non compaiono in nessuna voce di bilancio ma che si fanno sentire lo stesso: nei tempi di lavorazione, nelle opportunità mancate, nel turnover delle persone che devono usarlo ogni giorno. A un certo punto il costo di non cambiare supera il costo di cambiare, spesso senza che nessuno se ne accorga con chiarezza.
Questo articolo non è un invito a buttare tutto e ripartire da zero. È un tentativo di dare strumenti concreti per capire quando un sistema legacy è davvero un problema, quanto costa tenerlo, e quali opzioni esistono oltre alla sostituzione integrale.
Cos'è il software legacy, esattamente
La parola "legacy" evoca immagini di mainframe degli anni Ottanta e schermi verdi su sfondo nero. Ma nella realtà aziendale il software legacy è spesso molto più recente di così. Un gestionale sviluppato dieci anni fa su tecnologie che oggi non vengono più mantenute, un e-commerce costruito su una versione di una piattaforma che non riceve più aggiornamenti di sicurezza, un'applicazione web che funziona solo su una versione specifica di Internet Explorer: tutti questi sono software legacy, indipendentemente dall'anno in cui sono stati scritti.
La definizione più utile non è temporale ma funzionale: è legacy qualsiasi sistema che costa più di quanto rende mantenere, considerando non solo i costi diretti di manutenzione ma anche i costi indiretti di opportunità, produttività e rischio.
I costi che non si vedono nel budget
Il costo più ovvio del software legacy è la manutenzione tecnica: aggiornamenti, patch di sicurezza, interventi per risolvere bug che si accumulano nel tempo. Ma questi sono in realtà i costi più visibili, e spesso non sono i più significativi.
Il primo costo nascosto è il tempo delle persone. Un sistema lento, con interfacce poco intuitive o con processi manuali che potrebbero essere automatizzati, sottrae ore di lavoro ogni giorno. Cinque minuti in più per elaborare un ordine, dieci minuti per estrarre un report che il sistema non produce automaticamente, mezz'ora per riconciliare dati tra due sistemi che non si parlano: moltiplicato per il numero di persone e di giorni lavorativi, il totale è spesso sorprendente.
Il secondo è il rischio di sicurezza. Software non aggiornato è software vulnerabile. Le vulnerabilità nei sistemi legacy sono spesso note e documentate, il che le rende facili da sfruttare per chi volesse farlo. Non è un rischio teorico: molti degli attacchi ransomware degli ultimi anni hanno colpito aziende attraverso sistemi non aggiornati. Il costo di un incidente di sicurezza, in termini di dati persi, fermo operativo e danni reputazionali, può essere molto superiore al costo di una migrazione.
Il terzo è la difficoltà di trovare chi lo mantiene. Tecnologie vecchie hanno comunità di sviluppatori che si riducono nel tempo. Trovare qualcuno capace di lavorare su un sistema scritto in un linguaggio o un framework obsoleto è sempre più difficile e costoso. E quando quella persona se ne va, il problema si moltiplica.
Il quarto, forse il più sottovalutato, è il freno all'innovazione. Ogni volta che si vuole aggiungere una funzionalità nuova, integrare uno strumento moderno o rispondere a un'opportunità di mercato, il sistema legacy diventa un ostacolo. Si può fare, ma richiede compromessi, workaround, costi extra. Nel tempo, questo frena la capacità dell'azienda di evolvere, indipendentemente dalla volontà delle persone.
Come capire se il problema è davvero il sistema
Non tutti i problemi operativi dipendono dal software. Prima di concludere che il sistema legacy è il colpevole, vale la pena fare qualche verifica.
Un segnale chiaro è quando le richieste di modifica o integrazione vengono sistematicamente rifiutate o rimaste in attesa perché "il sistema non lo permette". Se ogni nuova esigenza si scontra con un limite tecnico del software, il sistema sta frenando l'azienda in modo misurabile.
Un altro è la dipendenza da processi manuali paralleli. Fogli Excel usati per compensare quello che il sistema non fa, email come sistema di notifica perché il software non ha questa funzionalità, export manuali periodici per produrre report che dovrebbero essere automatici: sono tutti segnali che il sistema non copre più le esigenze reali.
C'è poi la questione delle integrazioni impossibili o costosissime. Se collegare il sistema a uno strumento moderno richiede mesi di lavoro e budget significativi, o se semplicemente non è fattibile, il sistema sta limitando le opzioni strategiche dell'azienda.
Infine, un segnale che viene spesso ignorato: il feedback delle persone che lo usano ogni giorno. Chi lavora con un sistema lento, complicato o poco affidabile lo sa benissimo. Il problema è che spesso questo feedback non arriva mai a chi prende le decisioni tecnologiche, o arriva come lamentela generica senza essere tradotto in costi concreti.
Le opzioni disponibili: non è tutto o niente
La paura di affrontare il problema del software legacy deriva spesso dall'idea che l'unica alternativa sia una sostituzione totale, con tutto il rischio, il costo e la discontinuità operativa che comporta. Ma le opzioni sono più sfumate.
La migrazione progressiva è spesso la scelta più sensata. Invece di sostituire tutto in una volta, si identifica la parte del sistema che causa più problemi o che blocca la crescita e si interviene su quella. Il resto continua a funzionare mentre si costruisce il nuovo, con la possibilità di validare ogni pezzo prima di procedere al successivo.
Il wrapping è un'altra opzione, utile quando il sistema legacy contiene logiche di business complesse e ben funzionanti che sarebbe costoso ricostruire. Si costruisce uno strato moderno attorno al vecchio sistema, esponendo le sue funzionalità tramite API standard e aggiungendo un'interfaccia aggiornata. Il cuore rimane, ma smette di essere un ostacolo all'integrazione con il resto.
In alcuni casi, la soluzione giusta è un software custom che sostituisce il legacy in modo mirato, costruito specificamente sulle esigenze attuali dell'azienda invece che adattato da una soluzione generica. Questo è particolarmente rilevante quando il sistema legacy era già un software su misura che ha semplicemente esaurito la sua vita utile, o quando le esigenze dell'azienda si sono evolute abbastanza da rendere inadeguata qualsiasi soluzione standard disponibile sul mercato.
In Redergo affrontiamo spesso progetti di questo tipo. Il primo passo è sempre un'analisi onesta: capire cosa fa davvero il sistema attuale, dove si trovano i colli di bottiglia, quali parti hanno ancora valore e quali vanno riprogettate. Solo dopo si decide come intervenire.
Prima di decidere: il calcolo che vale la pena fare
Quando si valuta se e come intervenire su un sistema legacy, c'è un esercizio utile che raramente viene fatto in modo esplicito: stimare il costo annuale del non fare niente.
Ore di lavoro sprecate per processi manuali, moltiplicato per il costo orario medio delle persone coinvolte. Stima del rischio di sicurezza, anche solo in termini di probabilità di incidente moltiplicata per il costo medio di un fermo operativo. Opportunità mancate perché il sistema non permette di integrare uno strumento che avrebbe un impatto misurabile sul business.
Questo numero, anche se approssimativo, cambia spesso la conversazione. Il problema non è più "quanto costa cambiare" ma "quanto stiamo già pagando per non cambiare". Sono due domande diverse, e la seconda porta quasi sempre a decisioni più lucide.
Il software legacy non è un problema da affrontare per forza oggi. Ma è un problema da conoscere, misurare e tenere sotto controllo. Lasciarlo crescere senza una strategia è la scelta più costosa di tutte.
