In breve:
La modernizzazione IT legacy è il percorso con cui un’azienda aggiorna, migra o sostituisce sistemi e applicazioni obsolete che restano critiche per l’operatività. Secondo le stime McKinsey, il debito tecnico legato ai sistemi legacy assorbe tra il 40% e il 60% dei budget IT aziendali e incrementa i costi di progetto tra il 10% e il 20%. Un’indagine Researchscape International su 504 professionisti IT rileva che il 62% delle organizzazioni utilizza ancora almeno un sistema legacy. La modernizzazione efficace non passa dalla riscrittura totale, ma da un approccio incrementale basato sulle R-Strategies: rehost, replatform, refactor, rearchitect, rebuild o replace, scelte caso per caso in base al valore di business e alla qualità tecnica di ciascun sistema.
Perché la modernizzazione IT legacy non può più aspettare
La modernizzazione IT legacy è uno di quei progetti che ogni azienda sa di dover affrontare e che quasi ogni azienda rimanda. La ragione è comprensibile: i sistemi legacy funzionano. Gestiscono transazioni, custodiscono dati strategici, incorporano logiche di business sedimentate in decenni di aggiustamenti. Sostituirli espone a rischi che poche organizzazioni sono disposte ad accettare.
Il costo dell’inerzia è però documentato. Secondo le stime McKinsey, il debito tecnico legato ai sistemi legacy assorbe tra il 40% e il 60% dei budget IT aziendali, con un incremento dei costi di progetto stimato tra il 10% e il 20%. Un’indagine Researchscape International su 504 professionisti IT rileva inoltre che il 62% delle organizzazioni utilizza ancora almeno un sistema legacy, con percentuali che salgono al 67% nelle realtà sopra i mille dipendenti.
Il debito tecnico non resta fermo: matura interessi. Ogni anno di rinvio aumenta il costo della manutenzione, allarga la superficie di vulnerabilità, riduce la capacità di integrare nuove tecnologie e assottiglia il numero di persone che sanno ancora come funziona quel sistema.
Come riconoscere un sistema legacy critico
Non tutti i sistemi datati sono un problema. Un applicativo stabile, documentato e senza vincoli di integrazione può restare in esercizio a lungo senza generare rischi. I segnali che indicano invece una criticità reale sono altri.
Il fornitore non lo supporta più
Sistemi operativi fuori supporto, database non più aggiornati, applicativi il cui vendor è uscito dal mercato. Senza patch di sicurezza, ogni vulnerabilità scoperta resta aperta in modo permanente — un problema che diventa anche di compliance con NIS2 e DORA.
La conoscenza è concentrata in poche persone
Il rischio più sottovalutato è il decadimento della conoscenza. Regole di business, decisioni sullo schema dati e logiche di gestione delle eccezioni esistono spesso solo nella memoria di chi ha lavorato al sistema anni fa. Quando quelle persone lasciano l’azienda, il sistema diventa una scatola nera che nessuno osa toccare.
Ogni integrazione richiede uno sforzo sproporzionato
Assenza di API, formati proprietari, connessioni punto-punto costruite nel tempo senza documentazione. Ogni nuovo progetto che deve dialogare con quel sistema paga una tassa di integrazione che cresce in modo non lineare.
Il sistema blocca iniziative di business
Il segnale più chiaro in assoluto: quando un progetto viene ridimensionato o abbandonato perché “il gestionale non lo permette”, il costo del legacy ha superato quello della modernizzazione.
Le sei strategie di modernizzazione: quale scegliere
Il framework delle R-Strategies offre un vocabolario condiviso per decidere cosa fare di ciascun sistema. La scelta non è tecnologica ma economica: dipende dal valore di business dell’applicazione e dalla sua qualità tecnica attuale.
| Strategia | In cosa consiste | Quando ha senso | Sforzo |
|---|---|---|---|
| Rehost | Spostare il sistema su nuova infrastruttura senza modifiche (lift-and-shift) | Sistema funzionante su hardware obsoleto | Basso |
| Replatform | Migrare adattando alcuni componenti (es. database gestito) | Si vogliono benefici cloud senza riscrivere | Medio-basso |
| Refactor | Riscrivere parti di codice mantenendo funzionalità e architettura | Codice degradato ma architettura valida | Medio |
| Rearchitect | Ridisegnare l’architettura (es. da monolite a servizi) | Servono scalabilità e integrazione | Alto |
| Rebuild | Riprogettare da zero mantenendo i requisiti funzionali | Sistema strategico ma tecnicamente insostenibile | Molto alto |
| Replace | Sostituire con una soluzione di mercato | Basso valore differenziante, esistono alternative | Alto |
L’errore più costoso è applicare la stessa strategia a tutto il parco applicativo. Un portafoglio maturo combina più approcci: rehost per i sistemi periferici, refactor per quelli che reggono ma invecchiano male, replace per ciò che non genera vantaggio competitivo.
Il percorso di modernizzazione in cinque fasi
1. Inventario e mappatura delle dipendenze
Il primo passo è costruire un inventario che vada oltre nome e versione del software: criticità di business, debito tecnico accumulato, rischio di sicurezza, performance operative. L’output di questa fase dovrebbe essere triplice — inventario completo delle applicazioni, mappa delle dipendenze e delle integrazioni, scorecard di priorità.
La mappa delle dipendenze è la parte che viene più spesso sottovalutata ed è quella che determina il successo del progetto: nei sistemi legacy le connessioni non documentate sono la norma, non l’eccezione.
2. Business case e definizione delle priorità
Modernizzare tutto insieme non è realistico. La prioritizzazione deve incrociare l’impatto sul business, il rischio di sicurezza, il costo di mantenimento attuale e la complessità dell’intervento. È lo stesso ragionamento che permette di presentare al board un’analisi TCO comparativa, un approccio che abbiamo descritto parlando di business transformation e del ruolo dei CIO.
3. Scelta della strategia per ciascun sistema
Con inventario e priorità alla mano, si applica il framework delle R-Strategies sistema per sistema, documentando il criterio di scelta. Questa documentazione è preziosa: nei progetti pluriennali le persone cambiano e le decisioni prese devono restare comprensibili.
4. Migrazione incrementale
La modernizzazione riuscita procede per incrementi, mai con un big bang. Tecniche come il wrapping delle funzionalità esistenti dietro API moderne permettono di proteggere il valore applicativo accumulato e di sostituire i componenti progressivamente, riducendo l’impatto operativo e mantenendo la possibilità di tornare indietro.
5. Governance e prevenzione del nuovo debito
Un progetto di modernizzazione che non stabilisce standard di integrazione, proprietà documentata e un registro centrale delle integrazioni ricrea in pochi anni lo stesso debito che ha appena estinto. La governance non è la fase finale: va definita all’inizio.
Il ruolo dell’AI generativa nella modernizzazione
Gli strumenti di AI generativa stanno cambiando l’economia di alcune attività di modernizzazione: comprensione di codice non documentato, traduzione tra linguaggi, generazione di test, ricostruzione della logica di business a partire dal codice sorgente.
Il beneficio è reale ma condizionato dalla supervisione. Nelle mani di sviluppatori esperti questi strumenti producono guadagni di efficienza significativi. Utilizzati senza controllo strutturato e senza una base documentale solida, rischiano di introdurre vulnerabilità e di accumulare nuovo debito tecnico — esattamente il problema che il progetto doveva risolvere.
Il ruolo del system integrator nella transizione dal legacy
Un progetto di modernizzazione tocca infrastruttura, applicazioni, dati, sicurezza e processi di business contemporaneamente. Richiede competenze verticali su tecnologie che spesso convivono per anni durante la transizione, e la capacità di gestire il cambiamento senza interrompere l’operatività.
AD Consulting affianca le aziende con i servizi di IT Infrastructure Assessment & Design e di Advisory & Migration Services, dall’assessment iniziale del parco applicativo alla definizione della roadmap, dalla migrazione al consolidamento e alla gestione continuativa.
Un’ultima considerazione economica: il tema del debito tecnico si intreccia con quello più ampio della razionalizzazione della spesa IT, che abbiamo affrontato nell’articolo sulle 7 insidie da evitare nell’ottimizzazione dei costi IT. Rimandare la modernizzazione è una delle forme più diffuse di falso risparmio.
Vuoi approfondire?
Scopri i servizi di IT Infrastructure Assessment & Design di AD Consulting.
FAQ: domande frequenti
Cos’è un sistema legacy?
Un sistema legacy è una tecnologia ancora in uso ma ormai superata: un gestionale sviluppato su misura anni fa, un database su hardware obsoleto o un’applicazione scritta in un linguaggio che pochi in azienda conoscono ancora. Il criterio non è l’età anagrafica, ma la difficoltà di manutenzione, integrazione ed evoluzione.
Quanto costa il debito tecnico legato ai sistemi legacy?
Secondo le stime McKinsey, il debito tecnico assorbe tra il 40% e il 60% dei budget IT aziendali e incrementa i costi dei nuovi progetti tra il 10% e il 20%. A questi si aggiungono costi indiretti: downtime, rischio di sicurezza e opportunità di business non realizzate.
Conviene riscrivere tutto da zero?
Raramente. La riscrittura totale è l’opzione più costosa e più rischiosa, perché i sistemi legacy contengono anni di logiche di business validate sul campo che vanno ricostruite integralmente. Nella maggior parte dei casi un approccio incrementale, che combina strategie diverse per sistemi diversi, produce risultati migliori a parità di budget.
Quanto dura un progetto di modernizzazione IT?
Dipende dall’ampiezza del parco applicativo e dalla strategia scelta. Un rehost su singolo sistema può richiedere poche settimane; un programma di modernizzazione su un portafoglio applicativo enterprise si sviluppa tipicamente su 18-36 mesi, procedendo per incrementi successivi.
Da dove si parte per modernizzare i sistemi legacy?
Dall’inventario. Serve una mappa completa delle applicazioni in uso, delle loro dipendenze e integrazioni, e una scorecard che assegni a ciascun sistema una priorità basata su criticità di business, rischio di sicurezza e costo di mantenimento. Senza questa base, qualsiasi scelta successiva è arbitraria.
Fonti e riferimenti
- McKinsey — Stime sul debito tecnico: assorbe tra il 40% e il 60% dei budget IT, con incremento dei costi di progetto tra il 10% e il 20%.
- Researchscape International — Indagine su 504 professionisti IT: il 62% delle organizzazioni utilizza almeno un sistema legacy (67% oltre i 1.000 dipendenti).
- HFS Research in collaborazione con EY — Legacy Application Modernization Services, 2025: spostamento del mercato dal lift-and-shift alla modernizzazione AI-nativa.
- Framework R-Strategies — Rehost, Replatform, Refactor, Rearchitect, Rebuild, Replace: modello consolidato per la scelta della strategia di modernizzazione.
- Direttiva (UE) 2022/2555 (NIS2) — Requisiti sulla gestione delle vulnerabilità applicabili anche ai sistemi non più supportati dal fornitore.