Modernizzazione dei Sistemi Legacy: Best Practice per le Imprese Europee

La modernizzazione dei sistemi legacy è l'aggiornamento strutturato, la sostituzione o la riarchitetturazione di software, infrastrutture e integrazioni obsoleti, in modo che soddisfino gli attuali requisiti aziendali, di sicurezza e di conformità. Per le aziende europee, due fattori hanno recentemente modificato la valutazione: le normative sulla cibersicurezza che impattano sul patrimonio legacy sono entrate nella fase di applicazione effettiva, e sono giunte le prime evidenze concrete sul fatto che lo sviluppo assistito dall'IA offra ritorni differenti a seconda del livello di accoppiamento dei sistemi.

Questo articolo analizza ciò che indicano i dati attuali, quale strategia di modernizzazione si adatti a ciascun sistema e come sequenziare le attività per evitare che un sistema critico si interrompa nel corso del processo.

Punti chiave

• L'adozione di servizi cloud a pagamento tra le imprese dell'UE ha raggiunto il 52,7% nel 2025, mentre l'adozione dell'IA ha toccato il 20,0%. Il cloud costituisce ormai un'infrastruttura standard, l'IA non ancora, e il divario tra queste due cifre è il punto in cui emergono solitamente i vincoli architetturali.
• La direttiva NIS2 è entrata nella fase di applicazione, sebbene non nella modalità che la maggior parte delle persone si aspetta: a luglio 2026 la Commissione ha deferito quattro Stati membri alla Corte di Giustizia per non aver recepito la direttiva.
• La ricerca DORA 2025 di Google Cloud ha rilevato che l'adozione dell'IA migliora il throughput di rilascio pur mantenendo una relazione negativa con la stabilità delle distribuzioni, e che i team vincolati da sistemi fortemente accoppiati e processi lenti ottengono benefici minimi o nulli.
• Un'analisi del governo britannico ha rilevato che circa il 28% del patrimonio tecnologico dell'amministrazione centrale è classificato come legacy, con alcune organizzazioni che spendono dal 70 all'85% del proprio budget tecnologico per la manutenzione anziché per la modernizzazione.
• La sequenziazione supera l'ambito. In primo luogo razionalizzare, in secondo luogo avvolgere il core con API stabili, in terzo luogo eseguire il refactoring in modo selettivo, e infine verificare che la dismissione sia effettivamente avvenuta.

Cos'è la modernizzazione dei sistemi legacy e perché è rilevante oggi?

La modernizzazione dei sistemi legacy è il processo di miglioramento di applicazioni, database, infrastrutture e integrazioni obsoleti affinché diventino sicuri, manutenibili e idonei alle attuali esigenze di business. È rilevante perché i vecchi sistemi rallentano il cambiamento, aumentano il rischio operativo, indeboliscono le evidenze di conformità e limitano le prestazioni dei livelli più recenti dello stack che vi poggiano sopra.

Un sistema legacy non è semplicemente un sistema vecchio. Diventa un problema aziendale quando è difficile da modificare, scarsamente documentato, costoso da supportare o dipendente da competenze rare sul mercato. Nelle medie imprese europee, lo schema ricorrente vede processi critici in esecuzione su estensioni ERP monolitiche, applicazioni .NET o Java datate, versioni di database non più supportate, integrazioni batch e infrastrutture on-premise la cui mappa delle dipendenze risiede unicamente nella memoria di persone che potrebbero non lavorare più lì.

Il quadro macroeconomico merita di essere enunciato con precisione, poiché viene spesso citato in modo impreciso. Sono in circolazione due diversi indicatori sul cloud e non sono intercambiabili:

Le due cifre sul cloud differiscono perché misurano elementi diversi su periodi di riferimento differenti, non perché una sia errata. Chiunque citando una singola cifra sull'"adozione del cloud nell'UE" senza specificare l'indicatore di riferimento sta fornendo un dato impreciso.

Per un CTO o un VP of Engineering, la modernizzazione si scompone in quattro attività:

• Discovery: catalogazione di applicazioni, dipendenze, flussi dati, utenti e infrastruttura.
• Assessment: classificazione dei sistemi in base a criticità per il business, rischio tecnico, esposizione alla sicurezza e frequenza dei cambiamenti.
• Target design: definizione dell'architettura futura, del modello di rilascio e della sequenza di migrazione.
• Execution: migrazione, refactoring, integrazione, testing, dismissione e monitoraggio.

Un artefatto iniziale utile è una matrice d'impatto (heatmap) che metta in relazione il valore di business con la salute tecnica. Questo strumento fornisce al consiglio di amministrazione un'unica panoramica in cui si incrociano rischio, costo e impatto sul cliente, supportando la decisione di intervenire su priorità strategiche anziché sul sistema che genera momentaneamente le maggiori segnalazioni.

Cosa è cambiato concretamente a livello normativo?

Gli obblighi sono passati dalla fase di redazione a quella di applicazione effettiva, ma le modalità di tale applicazione meritano di essere comprese con precisione, poiché vengono ampiamente travisate.

NIS2. Il termine ultimo per il recepimento era il 17 ottobre 2024. L'8 luglio 2026 la Commissione Europea ha deferito Irlanda, Spagna, Francia e Paesi Bassi alla Corte di Giustizia per mancata notifica delle misure di recepimento, a seguito delle lettere di costituzione in mora del novembre 2024 e dei pareri motivati inviati a 19 Stati membri nel maggio 2025. È importante notare la natura di questo atto: si tratta di un'azione sanzionatoria contro gli Stati membri per mancato recepimento, non contro le imprese. La conseguenza pratica è che gli obblighi decorrono dall'attuazione nazionale; pertanto, il calendario di conformità per un'azienda dipende dai Paesi in cui opera. La NIS2 attribuisce inoltre la responsabilità ai vertici: l'Articolo 20 richiede che gli organi di gestione dei soggetti essenziali e importanti approvino le misure di gestione dei rischi di cibersicurezza e ne sovrintendano l'attuazione.

Italia. La NIS2 è recepita dal Decreto Legislativo 138/2024, in vigore dal 16 ottobre 2024, con le determinazioni dell'ACN che stabiliscono i passaggi operativi: obblighi di notifica degli incidenti dal 15 gennaio 2026, misure di sicurezza di base operative entro il 31 ottobre 2026 e una finestra annuale di rinnovo della registrazione nei primi due mesi dell'anno.

DORA. Il Regolamento (UE) 2022/2554 si applica dal 17 gennaio 2025. Il 18 novembre 2025 le Autorità di vigilanza europee hanno designato i primi fornitori terzi critici di tecnologie ICT, che sono ora soggetti a vigilanza diretta. La rilevanza per un fornitore di software è diretta: se si gestiscono infrastrutture o si fornisce software a un ente finanziario, il DORA determina le condizioni contrattuali, la segnalazione degli incidenti e i test di resilienza.

GDPR. L'Articolo 83(5) fissa le sanzioni amministrative pecuniarie fino a 20 milioni di euro o al 4% del fatturato mondiale totale annuo dell'esercizio precedente, se superiore. Il CMS Enforcement Tracker indica un totale cumulativo di circa 6,3 miliardi di euro su oltre 3.200 sanzioni ad agosto 2026. La rilevanza della modernizzazione: gli archivi di dati personali, i log di audit, i percorsi di accesso, i perimetri di cifratura e i rapporti con i responsabili del trattamento sono decisioni architetturali economiche in fase di progettazione e onerose da integrare a posteriori.

Il quadro della sicurezza si affianca a quello normativo. Il report Threat Landscape 2025 dell'ENISA, che copre 4.875 incidenti tra luglio 2024 e giugno 2025, ha posizionato nuovamente i DDoS e il ransomware in cima alle minacce principali. Il Cost of a Data Breach Report 2026 di IBM, pubblicato il 29 luglio 2026, ha attestato il costo medio globale di una violazione a 4,99 milioni di USD, un massimo storico, rilevando che una violazione dannosa su quattro è stata favorita dall'IA, con un costo medio di 6 milioni di USD. (ibm.com)

Le piattaforme legacy rendono la gestione di questo scenario più complessa per ragioni specifiche: percorsi di patch che non ricevono più aggiornamenti, controlli di identità antecedenti alla moderna federazione, procedure di ripristino manuali e comportamenti a runtime che non possono essere tracciati adeguatamente per evidenziare quanto accaduto durante un incidente.

Perché gli investimenti nell'IA sottoperformano sulle architetture legacy?

Perché l'IA aumenta il tasso di variazione e l'accoppiamento converte il cambiamento in instabilità. Questa è la conclusione che ridefinisce il business case della modernizzazione, derivante dal più ampio corpus di ricerche sulle prestazioni di delivery attualmente disponibile.

Il report DORA 2025 di Google Cloud, basato sulle risposte di quasi 5.000 professionisti del settore tecnologico, ha rilevato che il 90% utilizza l'IA sul lavoro e oltre l'80% riferisce incrementi di produttività. Ha inoltre evidenziato che l'adozione dell'IA continua ad avere una relazione negativa con la stabilità del rilascio del software. Il meccanismo è descritto in modo chiaro: in assenza di test automatizzati solidi, di un controllo versione maturo e di cicli di feedback rapidi, l'aumento del volume dei cambiamenti porta all'instabilità; i team che operano su architetture a basso accoppiamento con cicli di feedback rapidi ottengono vantaggi, mentre quelli vincolati da sistemi fortemente accoppiati e processi lenti registrano benefici minimi o nulli. Il report definisce l'IA come un amplificatore del sistema già esistente, anziché come una soluzione per correggerlo.

La successiva ricerca DORA sull'ROI dello sviluppo assistito da IA (versione 2026.1, aprile 2026) modella finanziariamente questo stesso effetto, includendo una curva a J in cui la produttività cala prima di salire, e mostra come l'aumento dei tassi di fallimento dei rilasci riduca il rendimento.

Due condizioni coesistono in questo rilevamento: il forte accoppiamento e i processi lenti. L'interpretazione corretta non è che l'IA sia sopravvalutata, bensì che il rendimento dello sviluppo assistito da IA dipende dall'architettura e dalla disciplina di rilascio, elementi che vengono trasformati proprio da un programma di modernizzazione. Ciò rende la modernizzazione un prerequisito per l'investimento nell'IA piuttosto che un concorrente per lo stesso budget.

Qual è l'impatto economico?

Tre fonti definiscono il quadro finanziario, e una di esse viene quasi sempre citata in modo errato.

Run versus change. L'evidenza pubblica più chiara su come il legacy assorba il budget proviene dalla State of Digital Government Review del governo britannico (gennaio 2025). Ha rilevato che circa il 28% del patrimonio tecnologico è classificato come legacy e che organizzazioni come il DWP e l'NHS England spendono fino al 70-85% dei propri budget tecnologici per la manutenzione. Ha inoltre evidenziato che il 22% dei sistemi legacy presenta un livello di rischio critico e che il 28% di questi non dispone di fondi per il risanamento. Il meccanismo chiave: il mancato finanziamento del risanamento causa l'aggravarsi del problema legacy.

Debito tecnico. La cifra citata secondo cui dal 10 al 20% del budget tecnologico destinato ai nuovi prodotti viene dirottato sulla risoluzione del debito tecnico proviene dallo studio di McKinsey "Tech debt: reclaiming tech equity" (ottobre 2020, basato su 50 CIO di aziende con ricavi superiori a 1 miliardo di USD). La ricerca sul budget di McKinsey del marzo 2026, basata su 17 aziende globali, descrive la gestione adottata dalle realtà più disciplinate: mantengono almeno un terzo della spesa tecnologica totale destinata al change anziché al run, mantengono i costi infrastrutturali legati al run inferiori di almeno il 20% rispetto ad altre organizzazioni e indirizzano il 57% della spesa applicativa specificamente alle categorie di change.

Le stime di crescita. La ricerca di Accenture del 2024 indica che le organizzazioni dotate di un core digitale avanzato, combinato con investimenti strategici nell'innovazione e un approccio equilibrato al debito tecnico, hanno raggiunto un tasso di crescita dei ricavi "fino al" 60% più elevato e profitti superiori del 40%. Si tratta di un risultato condizionato al verificarsi di tre fattori con un limite massimo specificato. La modernizzazione crea le condizioni per la crescita, ma presentarla come causa diretta non corrisponde a quanto riportato dalla ricerca.

Per il contesto di mercato, le previsioni di Gartner del 27 luglio 2026 stimano la spesa IT mondiale a 6,37 mila miliardi di USD nel 2026, con un incremento del 14,2%, mentre l'Infrastructure as a Service cresce da 222 miliardi di USD nel 2025 a 287 miliardi di USD nel 2026.

Quale strategia di modernizzazione si adatta a ciascun sistema?

Una modernizzazione efficace costituisce una decisione gestita a livello di portafoglio anziché un singolo progetto. Di seguito le sette opzioni standard:

Tre prassi determinano il successo dell'approccio a portafoglio:

Razionalizzare prima di sviluppare. Prima di produrre nuovo codice, occorre individuare applicazioni duplicate, report inutilizzati, interfacce ridondanti e procedure manuali alternative. L'ambito si riduce frequentemente in questa fase, tramite dismissioni dirette o sostituzioni con modifiche di processo. È la forma di modernizzazione più economica e quella più facilmente omessa.

Isolare il core, quindi ridurne il ruolo. Anziché riscrivere un sistema centrale tramite un unico programma ad alto rischio, realizzare API stabili attorno ad esso, instradare le nuove funzionalità attraverso servizi moderni e trasferire progressivamente le responsabilità fuori dal core legacy, finché quanto rimane sia sufficientemente contenuto da essere sostituito o mantenuto in modo deliberato. Questo approccio corrisponde allo strangler pattern. Gli incrementi che aggiungono unicamente percorsi di lettura o nuovi servizi sono semplici da ripristinare. Gli incrementi che migrano la scrittura o la titolarità dei dati richiedono una progettazione specifica per il rollback.

Eseguire il refactoring in modo selettivo. Applicarlo alle aree caratterizzate da un'elevata frequenza di modifica, scarsa affidabilità o impatto diretto sul cliente. Ristrutturare una funzione di back-office stabile unicamente perché il codice appare datato rappresenta una scelta estetica presentata come decisione ingegneristica.

Una sequenza pratica di rilascio:

1. Creare un inventario del portafoglio e una mappa delle dipendenze.
2. Classificare ogni applicazione in base al valore di business e alla salute tecnica.
3. Selezionare una strategia per ciascuna applicazione, assegnando un referente responsabile.
4. Definire le fasi di migrazione con criteri espliciti di rollback.
5. Automatizzare test, deployment, scansioni di sicurezza e monitoraggio prima del primo passaggio in produzione.
6. Dismettere la vecchia infrastruttura una volta confermata la stabilità in produzione, verificando che la dismissione sia stata effettivamente completata.

Il punto 6 è quello che rimane più frequentemente incompiuto; i sistemi non dismessi portano le organizzazioni a sostenere contemporaneamente i costi della vecchia e della nuova infrastruttura.

In che modo i diagrammi di modernizzazione migliorano la pianificazione e l'esecuzione?

Un diagramma di modernizzazione rende visibili contestualmente ai referenti tecnici e non tecnici i sistemi attuali, le dipendenze, i flussi dati, i rischi e l'architettura target. Trasforma le ipotesi in artefatti verificabili ed evidenzia le lacune di integrazione, sicurezza ed operatività prima che raggiungano l'ambiente di produzione.

Un programma richiede quattro rappresentazioni:

• Architettura dello stato attuale: applicazioni, database, integrazioni, utenti, infrastruttura.
• Mappa delle dipendenze: sistemi a monte e a valle, processi batch, API, trasferimenti di file.
• Architettura dello stato target: futuri servizi, archivi dati, gestione delle identità, monitoraggio, modello di deployment.
• Roadmap di migrazione: fasi, punti di go-live, periodi di coesistenza, prerequisiti per la dismissione.

Il modello C4 fornisce una gerarchia funzionale articolata in contesto di sistema, container, componenti e codice, mentre arc42 integra le viste relative ai blocchi costruttivi e al runtime. Entrambi sono volutamente leggeri, permettendo loro di rimanere aggiornati parallelamente al piano di rilascio.

Due elementi distinguono un diagramma utilizzato da uno ignorato. In primo luogo, deve essere gestito sotto controllo versione e aggiornato come il codice. In secondo luogo, deve evidenziare esplicitamente gli elementi rilevanti ai fini della conformità: archivi di dati personali, log di audit, percorsi di accesso, perimetri di cifratura, responsabili terzi del trattamento e monitoraggio operativo. Questo livello informativo consente ai responsabili di GDPR, NIS2 e DORA di valutare una decisione architetturale mentre è ancora in fase decisionale.

Un diagramma utile risponde a cinque domande: cosa esiste oggi, cosa dipende da cosa, cosa deve cambiare, cosa non deve interrompersi e cosa può essere disattivato.

Cosa include un progetto di modernizzazione?

Un progetto di modernizzazione strutturato copre l'intero ciclo di vita, dalla fase di discovery fino al passaggio consegne operativo:

• Assessment: analisi di codice sorgente, infrastruttura, database, interfacce, licenze, controlli di sicurezza e processi operativi, unita a interviste con gli stakeholder. L'output è una mappa di portafoglio prioritizzata.
• Roadmap architetturale: definizione dello stato target nei livelli applicativo, dati, integrazione e infrastruttura.
• Pianificazione della migrazione: piani per fasi, modelli di rollback, strategia degli ambienti, criteri di go-live.
• Esecuzione ingegneristica: refactoring, containerizzazione, sviluppo API, migrazione database, automazione.
• Quality assurance: test di regressione, prestazioni e sicurezza, riconciliazione dei dati.
• Modello operativo: CI/CD, osservabilità, gestione degli incidenti, passaggio consegne al team interno.

Un aspetto strutturale prescinde dal fornitore selezionato: l'esternalizzazione dell'esecuzione non comporta l'esternalizzazione della responsabilità. Il product owner interno, il responsabile della sicurezza e l'enterprise architect devono rimanere i decisori finali, poiché le dipendenze che interrompono un programma di modernizzazione sono generalmente organizzative anziché tecniche, ed un team esterno non può risolverle. Un progetto ben strutturato si conclude con il team interno che possiede la documentazione, le pipeline e i manuali operativi necessari per gestire il risultato in autonomia.

Se state valutando la modernizzazione in vista di una scadenza NIS2 o DORA, o se avete un'iniziativa di IA che non sta fornendo i ritorni previsti dai progetti pilota, potete contattare direttamente il nostro team di ingegneria. Senza moduli o demo: un confronto diretto con le persone che gestirebbero l'attività.

Contatta il nostro team di ingegneria →

Fonti

• Eurostat, "52,7% of EU enterprises bought cloud computing services in 2025", 3 febbraio 2026: ec.europa.eu
• Eurostat, "20% of EU enterprises use AI technologies", 11 dicembre 2025: ec.europa.eu
• Commissione Europea, "2026 State of the Digital Decade", 17 giugno 2026: digital-strategy.ec.europa.eu
• Commissione Europea, infrazione NIS2 — deferimento alla Corte di Giustizia, 8 luglio 2026
• Decreto Legislativo 138/2024, recepimento NIS2 in Italia
• Regolamento (UE) 2022/2554 (DORA): eur-lex.europa.eu
• EIOPA, EBA ed ESMA, designazione dei fornitori terzi critici di ICT, 18 novembre 2025: eiopa.europa.eu
• Regolamento (UE) 2016/679 (GDPR), Articolo 83: eur-lex.europa.eu
• ENISA, Threat Landscape 2025: enisa.europa.eu
• IBM, Cost of a Data Breach Report 2026, 29 luglio 2026: ibm.com
• Google Cloud, DORA Report 2025: dora.dev
• Google Cloud, DORA AI-assisted Development ROI 2026.1, aprile 2026
• UK DSIT, State of Digital Government Review, gennaio 2025
• McKinsey, "Tech debt: reclaiming tech equity", ottobre 2020: mckinsey.com
• McKinsey, ricerca sul budget IT, marzo 2026
• Accenture, "Digital core investments accelerate reinvention", 17 luglio 2024: newsroom.accenture.com
• Gartner, previsioni spesa IT mondiale, 27 luglio 2026
• C4 Model: c4model.com
• arc42: arc42.org