Ogni anno che passa, il software legacy diventa più costoso da mantenere e più rischioso da ignorare. Questa guida mostra come uscirne senza fermare la produzione, con strategie testate su PMI italiane reali.
Panoramica in 20 secondi
C'è una frase che sentiamo ripetere da anni nelle sale riunioni delle PMI italiane: "il gestionale funziona, perché cambiarlo?". È una domanda ragionevole, finché non si guarda cosa succede dietro le quinte. Un'azienda metalmeccanica della provincia di Brescia, sessanta dipendenti e trent'anni di storia, ha scoperto nel 2025 che il programmatore RPG — il linguaggio che gira sugli AS400, quei server IBM neri che molti hanno ancora nel seminterrato — era l'unico al mondo a conoscere le personalizzazioni fatte nel 1998. L'uomo aveva sessantadue anni e nessuna intenzione di restare un altro inverno. Non è un caso isolato: secondo i dati dell'Osservatorio del Politecnico di Milano, in Italia l'età media degli sviluppatori COBOL e RPG supera i cinquantotto anni. Quando questi professionisti vanno in pensione, portano via competenze che non esistono sul mercato. Nel frattempo, la manutenzione di questi sistemi assorbe in media il settantaquattro per cento del budget IT delle aziende che li utilizzano. Soldi spesi non per innovare, ma per tenere in piedi qualcosa che andava bene quando i fax erano lo strumento di comunicazione principale. Il debito tecnico — cioè il costo accumulato di scelte tecnologiche rimandate — cresce ogni trimestre come un interesse composto che nessuno ha il coraggio di calcolare.
Il problema non è solo economico. Questi sistemi legacy non parlano con il mondo esterno. Provate a collegare un AS400 a un e-commerce Shopify, a un'app mobile per la forza vendita, o alle API di un partner logistico come GLS o BRT: servono strati su strati di middleware, gateway personalizzati, fogli Excel esportati a mano. Una PMI del settore tessile a Prato ha calcolato che i propri operatori perdevano undici ore alla settimana per ricopiare dati dal terminale verde del sistema legacy verso il portale ordini dei clienti esteri. Undici ore, ogni settimana, per fare il lavoro di un'integrazione automatica che costerebbe meno di tre mesi di quella manodopera sprecata. E poi ci sono i rischi di sicurezza: stack software non più aggiornati dai produttori originali rappresentano superfici di attacco enormi. Con la direttiva NIS2 entrata pienamente in vigore, le aziende che operano in settori critici — manifattura, logistica, energia, sanità — devono dimostrare di gestire attivamente le vulnerabilità. Un sistema operativo fuori supporto, un database senza patch da cinque anni, un protocollo di comunicazione senza cifratura: sono tutte non conformità che espongono a sanzioni concrete e, peggio ancora, a incidenti reali.
Esistono quattro strategie principali per affrontare la modernizzazione, e la scelta dipende dalla situazione specifica. Il rehost, chiamato anche lift and shift, significa prendere l'applicazione così com'è e spostarla su un'infrastruttura cloud: è veloce (da due a quattro mesi), costa relativamente poco, ma non risolve il problema del codice obsoleto — lo sposta solo su server più nuovi. Il replatform prevede di inserire l'applicazione in container Docker o ambienti cloud-native, adattando il minimo indispensabile: è utile quando il codice è stabile ma l'infrastruttura è a fine vita, e richiede dai quattro agli otto mesi. Il refactor è la riscrittura modulare del codice in linguaggi moderni come Java, C# o TypeScript, mantenendo la logica di business: è l'opzione più costosa (dai dieci ai diciotto mesi) ma produce il risultato migliore nel lungo periodo. Infine il replace, la sostituzione con un software commerciale come Zucchetti, Oracle NetSuite o soluzioni settoriali, che ha senso quando l'applicazione legacy non contiene logica di business realmente unica. La strategia che funziona meglio per la maggior parte delle PMI italiane è il pattern strangler fig, letteralmente "fico strangolatore": come la pianta che cresce attorno a un albero sostituendolo gradualmente, si costruisce il nuovo sistema pezzo per pezzo attorno al vecchio, senza mai spegnere tutto in un colpo. Niente big bang, niente weekend di terrore con il telefono in mano aspettando che qualcosa si rompa.
La pianificazione di una migrazione inizia sempre dalla stessa domanda: cosa fa davvero questo sistema? Sembra banale, ma dopo vent'anni di modifiche incrementali, personalizzazioni notturne e workaround creativi, spesso nessuno in azienda ha una mappa completa delle dipendenze. Il primo passo è un assessment tecnico serio: analisi statica del codice sorgente (quante righe, quali linguaggi, quali librerie), dependency mapping (quali moduli chiamano quali altri, quali database vengono letti e scritti), e — parte spesso sottovalutata — interviste con gli utenti chiave. Il magazziniere che usa il terminale ogni mattina sa cose che nessun documento tecnico riporta. In un progetto per un'azienda manifatturiera di Lecco, l'assessment ha rivelato che il sistema AS400 conteneva centoquarantadue programmi RPG, ma solo trentasei venivano effettivamente utilizzati. Gli altri erano residui di funzionalità dismesse anni prima, mai rimosse per paura di rompere qualcosa. Questa scoperta ha ridotto la portata del progetto del sessanta per cento. La fase di assessment dura tipicamente dalle tre alle sei settimane e costa tra i quindicimila e i trentamila euro, ma è l'investimento con il ritorno più alto dell'intero percorso, perché evita di migrare codice morto o di sottostimare la complessità reale.
Dopo l'assessment viene la definizione delle priorità: quali moduli migrare per primi. La risposta non è mai "quelli più vecchi" o "quelli più facili". La risposta corretta è: quelli che generano più valore di business se modernizzati. Un esempio concreto: l'azienda manifatturiera di Lecco ha scelto di partire dal modulo ordini clienti, perché era il collo di bottiglia per l'integrazione con il portale B2B che i clienti esteri chiedevano da due anni. In quattordici mesi, l'intero sistema è stato migrato verso un'architettura a microservizi con frontend React e backend in Node.js, ma il modulo ordini era operativo già dopo quattro mesi. Durante la transizione, il vecchio AS400 e i nuovi servizi hanno convissuto grazie a un layer di integrazione — un componente software che traduce le chiamate tra i due mondi, come un interprete simultaneo tra due persone che parlano lingue diverse. Questo approccio di coesistenza è fondamentale: il business non si ferma mai, gli utenti migrano gradualmente, e se qualcosa nel nuovo sistema non funziona come previsto, il vecchio è ancora lì come rete di sicurezza. Un altro caso significativo: una PMI di logistica con sede a Verona, venticinque dipendenti, gestiva l'intera operatività su un database Access del 2004. Trentasettemila record di spedizioni, macro VBA scritte dal titolare nei weekend, nessuna possibilità di accesso da mobile.
La PMI veronese ha sostituito Access con una web application in React e PostgreSQL in sei mesi, mantenendo ogni singolo record storico attraverso uno script di migrazione dati testato su tre ambienti separati prima del go-live. Il titolare oggi consulta le spedizioni dal telefono mentre è in magazzino, e i corrieri aggiornano lo stato di consegna in tempo reale invece di compilare fogli cartacei. Il costo totale del progetto è stato di quarantottomila euro, ammortizzati in meno di un anno grazie all'eliminazione di errori manuali che generavano in media tremila euro al mese di contestazioni. Questi numeri non sono eccezionali: sono la norma quando si smette di rattoppare e si inizia a ricostruire con criterio. Il punto critico che molti imprenditori non considerano è la gestione del cambiamento umano. Le persone che usano un sistema da quindici anni hanno sviluppato automatismi, scorciatoie, persino affetto per quell'interfaccia a caratteri verdi su sfondo nero. Ignorare questa dimensione significa ritrovarsi con un sistema nuovo che nessuno vuole usare. Per questo ogni progetto di migrazione serio include formazione progressiva, affiancamento nelle prime settimane e un canale diretto per segnalare problemi senza sentirsi giudicati. La tecnologia è la parte semplice. Portare le persone a bordo è ciò che fa la differenza tra un progetto che funziona e uno che finisce in un cassetto.
Analisi completa del codice sorgente legacy con dependency mapping automatizzato. Identifichiamo moduli attivi, codice morto e integrazioni nascoste attraverso scansione statica e interviste con gli utenti operativi, riducendo la portata reale del progetto fino al sessanta per cento.
Italy Soft applica il pattern strangler fig costruendo i nuovi moduli attorno al sistema esistente. Ogni componente viene sostituito singolarmente con un layer di integrazione che garantisce la coesistenza tra vecchio e nuovo, eliminando il rischio di fermi operativi durante la transizione.
Ogni record storico viene trasferito attraverso pipeline di migrazione testate su ambienti di staging, pre-produzione e produzione. Controlli automatici verificano integrità, coerenza e completezza dei dati prima del go-live, proteggendo decenni di informazioni aziendali critiche.
Programma di affiancamento strutturato per gli utenti del sistema legacy. Sessioni pratiche a piccoli gruppi, documentazione operativa con screenshot reali e canale di supporto dedicato nelle prime otto settimane. Il nuovo sistema viene adottato davvero, non solo installato.
Italy Soft
In 30 minuti di audit gratuito analizziamo i tuoi processi e calcoliamo il ROI concreto. Nessun impegno.