Modernizzare le applicazioni legacy: come sostituire un software che funziona ancora

La modernizzazione delle applicazioni legacy è il processo disciplinato con cui si sostituisce, si sposta su una nuova piattaforma (replatforming), si ristruttura (refactoring) o si ricostruisce un software aziendale datato, perché diventi sicuro, manutenibile, scalabile e più facile da integrare. Per i CTO europei la priorità non è «la tecnologia nuova fine a se stessa»: è ridurre il rischio operativo e, insieme, rilasciare più in fretta, usare meglio i dati, adottare il cloud e crescere in modo resiliente.

TL;DR: punti chiave

• La modernizzazione delle applicazioni legacy è un programma di gestione del rischio di business, non solo un progetto di ingegneria.
• Non partite per default da una riscrittura completa: usate la valutazione del portafoglio applicativo, le 7R e la sostituzione a fasi.
• La migrazione al cloud aiuta solo se accompagnata da un cambio di architettura e di modello operativo.
• La modernizzazione deve affrontare insieme dati, sicurezza, conformità e gestione del cambiamento.
• Il primo passo migliore è un inventario delle applicazioni basato su evidenze, con dipendenze, costi, rischi e valore per il business.

Cosa significa modernizzare le applicazioni legacy per un'azienda europea in crescita?

Modernizzare le applicazioni legacy significa migliorare o sostituire software datati perché possano sostenere gli attuali requisiti di business, sicurezza, normativa, integrazione e scalabilità. È diverso dalla manutenzione, perché cambia il costo futuro e l'adattabilità del sistema invece di tenerlo in vita a colpi di patch, soluzioni di ripiego e supporto specialistico.

Un'applicazione legacy non è semplicemente un software «vecchio»: diventa legacy quando frena il cambiamento. Può girare su tecnologie non più supportate, dipendere da competenze introvabili, bloccare le integrazioni via API, non rispettare gli standard di sicurezza o rendere ogni modifica al prodotto lenta e rischiosa.

La State of Digital Government Review del DSIT britannico (pubblicata il 21 gennaio 2025 e basata su evidenze del settore pubblico, non su un benchmark privato) definisce legacy i sistemi basati su prodotti a fine vita, senza supporto del fornitore, impossibili da aggiornare, non più convenienti o oltre una soglia di rischio accettabile. La stessa analisi ha rilevato che alcune organizzazioni, come DWP e NHS England, spendono fino al 70-85% del budget tecnologico in mantenimento invece che in modernizzazione; il dato illustra il peso del legacy, ma non va esteso senza cautela alle PMI europee. (gov.uk)

Modernizzare conta adesso perché le imprese europee stanno andando sempre più verso modelli operativi basati su cloud, dati e IA. Secondo Eurostat (pubblicato il 3 febbraio 2026, anno di riferimento 2025), nel 2025 il 52,7% delle imprese dell'UE ha usato servizi di cloud computing a pagamento, 7,4 punti percentuali in più rispetto al 2023. Eurostat ha anche riportato (pubblicato l'11 dicembre 2025, anno di riferimento 2025) che il 20,0% delle imprese dell'UE con almeno 10 dipendenti ha usato tecnologie di IA nel 2025, contro il 13,5% del 2024. (ec.europa.eu, ec.europa.eu)

Non confondete questi dati con altre metriche di «adozione del cloud». Il pacchetto 2026 State of the Digital Decade della Commissione europea, pubblicato il 17 giugno 2026, riporta un indicatore di monitoraggio diverso: il 46,7% delle imprese dell'UE usa il cloud computing, il 39,9% usa l'analisi dei dati e quasi il 20% adotta l'IA. La differenza conta perché ogni metrica ha una definizione e un contesto normativo propri. (digital-strategy.ec.europa.eu)

Uno strumento utile da portare al consiglio di amministrazione è una semplice «mappa della pressione legacy»: valore per il business su un asse, rischio tecnico sull'altro, e i sistemi raggruppati in candidati da dismettere, sostituire, spostare su nuova piattaforma o ristrutturare. Per la visione d'insieme sul portafoglio, comprese le novità normative e il costo di tenere in vita i sistemi datati, vedete la nostra guida ai sistemi legacy: cosa sono e come modernizzarli; questo articolo si concentra su come sostituire una singola applicazione.

Modernizzare non è la stessa cosa che manutenere

La manutenzione tiene in funzione il sistema attuale. La modernizzazione ne cambia la traiettoria economica e operativa.

Manutenzione di solito significa correggere difetti, rinnovare licenze, aggiungere piccoli miglioramenti e assistere gli utenti. La modernizzazione può comprendere migrazione al cloud, sostituzione del database, esposizione di API, modularizzazione, riprogettazione dell'esperienza utente, test automatizzati, adozione di DevOps o la sostituzione completa del software legacy.

I segnali tipici che è il momento di modernizzare:

• cicli di rilascio misurati in mesi invece che in giorni o settimane;
• framework, sistemi operativi, database o middleware non più supportati;
• test di regressione manuali che rallentano ogni modifica;
• regole di business nascoste nel codice che poche persone capiscono;
• integrazioni punto a punto che si rompono quando cambia un solo sistema;
• scarsa osservabilità, tracciabilità debole o procedure di ripristino fragili;
• costi in crescita senza un aumento corrispondente delle capacità per il business;
• impossibilità di supportare mobile, self-service, API per i partner, analisi dei dati o casi d'uso di IA.

Per i CTO di aziende con 50-500 dipendenti, la decisione non dovrebbe partire da «quale cloud?» o «quale framework?», ma dal ruolo che l'applicazione ha nel business. Un sistema legacy che gestisce un processo interno in declino richiede una risposta diversa da uno che sostiene ricavi, reporting normativo, logistica o esperienza cliente.

Quali strategie funzionano meglio per sostituire un software legacy?

La strategia migliore dipende da valore per il business, rischio tecnico, esposizione normativa, complessità delle dipendenze e velocità di cambiamento richiesta. La maggior parte delle aziende ha bisogno di un mix: dismettere i sistemi di poco valore, acquistare prodotti pronti per le esigenze standard, spostare su nuova piattaforma i carichi stabili e ristrutturare o ricostruire a piccoli passi le funzionalità che vi distinguono dalla concorrenza.

AWS Prescriptive Guidance descrive sette strategie di migrazione comuni, le cosiddette 7R (retire, retain, rehost, relocate, repurchase, replatform e refactor o re-architect), e osserva che il refactoring durante grandi migrazioni è complesso: molti programmi prima migrano o cambiano piattaforma, poi modernizzano. È una struttura utile anche al di fuori di AWS, perché separa l'obiettivo di business dai dettagli di implementazione. (docs.aws.amazon.com)

La strategia «repurchase» è quella che molte aziende italiane conoscono come «cambiare gestionale»: conviene quando il processo è standard e un prodotto di mercato lo copre bene. Se invece il gestionale contiene logiche che fanno la differenza per il vostro business, sostituirlo con un prodotto generico spesso significa perderle.

Un piano di sostituzione pratico, passo per passo

Partite dalla discovery. Costruite un inventario delle applicazioni che registri responsabili, utenti, processi di business, integrazioni, archivi dati, infrastruttura, licenze, storico degli incidenti, frequenza dei rilasci, requisiti di conformità e vulnerabilità note.

Poi valutate ogni sistema su quattro dimensioni:

1. Criticità per il business: ricavi, impatto sui clienti, dipendenza operativa.
2. Salute tecnica: qualità del codice, copertura dei test, stato del supporto, manutenibilità.
3. Domanda di cambiamento: pressione del backlog, cambiamenti del mercato, cambiamenti normativi.
4. Fattibilità della sostituzione: complessità dei dati, alternative disponibili, rischio di integrazione.

Quindi preparate un piano a ondate. Non modernizzate per prima l'applicazione più fragile e critica, a meno che una pressione esterna non vi costringa. È più sicuro collaudare il modello di delivery su un sistema a rischio medio e passare ai carichi di maggior valore quando pattern, strumenti e governance funzionano.

La migrazione al cloud può dare molto, ma solo se cambia il modello operativo. Spostare macchine virtuali nel cloud senza migliorare deployment, osservabilità, sicurezza, gestione dei costi o integrazioni spesso conserva i vecchi problemi in un nuovo ambiente di hosting.

I microservizi possono aiutare dove i team hanno bisogno di rilasciare in modo indipendente, di confini chiari tra funzionalità di business e di scalabilità elastica. Ma non sono una cura universale. Molte aziende di medie dimensioni stanno meglio con un monolite modulare, API chiare, test automatizzati e un database gestito, prima di introdurre la complessità di un sistema distribuito. Se state ancora decidendo tra riscrivere e migliorare il codice esistente, il nostro framework decisionale tra riscrittura e refactoring analizza i compromessi.

Lo strangler fig pattern

Lo strangler fig pattern (letteralmente «fico strangolatore») è spesso la strada più sicura per i sistemi critici. Martin Fowler usa il termine per descrivere un approccio graduale alla modernizzazione legacy, in cui le nuove funzionalità crescono attorno al vecchio sistema e lo sostituiscono progressivamente. (martinfowler.com)

L'architettura di solito mette un livello di API, proxy o integrazione davanti all'applicazione legacy. I nuovi servizi prendono poi in carico una funzionalità alla volta, mentre il vecchio sistema continua a funzionare.

Un buon piano di modernizzazione definisce anche i criteri di uscita. Per esempio: «tutto il traffico di onboarding clienti passa dal nuovo servizio», «il vecchio database di reporting è in sola lettura» oppure «la licenza del fornitore si può disdire dopo la chiusura del trimestre». Senza criteri di uscita, la modernizzazione diventa una convivenza permanente.

Come possono i CTO superare le difficoltà della modernizzazione?

I CTO superano le difficoltà della modernizzazione trattandole come rischi di prodotto, architettura, dati, sicurezza e gestione del cambiamento, non come attività tecniche isolate. I programmi più solidi combinano mappatura delle dipendenze, delivery a fasi, test automatizzati, controlli di sicurezza, governance condivisa e responsabilità chiare sui risultati di business, non solo sul passaggio al nuovo sistema.

La prima difficoltà è la conoscenza incompleta. I sistemi legacy contengono spesso regole di business non documentate, job batch, report, trigger sul database, trasferimenti di file e soluzioni manuali. Prima di sostituirli, organizzate workshop di discovery strutturati con utenti di business, assistenza, sicurezza, amministrazione, operations e gli sviluppatori che conoscono i casi limite.

La seconda difficoltà sono i dati. La migrazione dei dati raramente è un semplice esporta e importa. Può servire eliminare i duplicati, mappare i vecchi campi sui nuovi modelli di dominio, conservare le tracce di audit, definire le regole di conservazione e riconciliare i dati dopo il passaggio. Nei settori regolamentati tutto questo deve rispettare l'articolo 32 del GDPR sulla sicurezza del trattamento, che richiede misure tecniche e organizzative adeguate al rischio. (eur-lex.europa.eu)

La terza difficoltà è la conformità. La NIS2 imponeva agli Stati membri di recepire la direttiva entro il 17 ottobre 2024 (in Italia con il D.Lgs. 138/2024); l'articolo 20 chiede agli organi di gestione dei soggetti essenziali e importanti di approvare e supervisionare le misure di gestione del rischio di cybersecurity, mentre l'articolo 21 ne definisce i contenuti. Gli obblighi concreti dipendono dal recepimento nazionale, ma la direzione è chiara: la resilienza informatica è sempre più una questione di vertice, non solo un controllo IT. (digital-strategy.ec.europa.eu)

Nei servizi finanziari il regolamento DORA è vincolante dal 17 gennaio 2025 per le entità finanziarie di tutta l'UE, dopo essere entrato in vigore il 16 gennaio 2023. Secondo ENISA, DORA rafforza la resilienza operativa digitale e la vigilanza sui fornitori terzi critici di servizi ICT: questo rende le dipendenze legacy e la concentrazione dei fornitori direttamente rilevanti per le scelte di architettura. (enisa.europa.eu)

Anche l'EU Data Act si applica dal 12 settembre 2025, con disposizioni pensate per aiutare chi usa il cloud a cambiare fornitore o a usarne più d'uno in parallelo. Per i programmi di modernizzazione questo rafforza le ragioni per la portabilità, un piano di uscita e meno vincoli inutili nei livelli di dati e integrazione. (digital-strategy.ec.europa.eu)

Un modello pratico di controllo del rischio ha quattro livelli: continuità operativa, integrità dei dati, sicurezza e adozione. Ognuno ha bisogno di responsabili, test e possibilità di tornare indietro.

La gestione del cambiamento fa parte dell'architettura

Una collaborazione efficace decide se il nuovo sistema verrà usato davvero. Se amministrazione, operations, commerciale o compliance sentono che il programma viene «fatto su di loro», difenderanno i vecchi processi, i fogli Excel e i sistemi paralleli.

Usate un modello di governance orientato al prodotto. Date a ogni filone di modernizzazione un responsabile di business, un responsabile tecnico, un responsabile della delivery e un referente per la sicurezza. Fate passare le decisioni da un comitato di architettura snello, capace di sbloccare in fretta i compromessi.

Per i team, gli strumenti IT moderni devono comprendere CI/CD, test di regressione automatizzati, infrastructure as code, gestione dei segreti, monitoraggio delle prestazioni applicative, log centralizzati e procedure per la gestione degli incidenti. Queste capacità riducono il rischio di toccare un sistema vecchio, perché ogni rilascio diventa più osservabile e ripetibile.

Infine, tenete sotto controllo il perimetro. I programmi di modernizzazione peggiori mettono insieme in un unico rilascio sostituzione, riprogettazione, trasformazione dei processi, pulizia dei dati, rifacimento del reporting e nuova analitica. Separate ciò che «va spostato adesso» da ciò che «conviene migliorare dopo». Modernizzate la pista, non solo l'aereo.

Quali benefici può aspettarsi un'azienda dalla modernizzazione delle applicazioni legacy?

Modernizzare le applicazioni legacy migliora velocità di rilascio, resilienza operativa, sicurezza, scalabilità, integrazione, esperienza utente e qualità dei dati. Il beneficio economico viene dalla riduzione della manutenzione evitabile, del lavoro manuale, degli incidenti e del costo opportunità, e insieme da prodotti che cambiano più in fretta, analisi migliori e un'infrastruttura più adattabile.

Il caso di business deve essere specifico, non generico. «Costi più bassi» è un argomento debole se non lo collegate alla dismissione di server, a meno licenze, all'automazione del supporto manuale, al consolidamento delle piattaforme, a più test automatizzati o all'eliminazione di dipendenze da competenze legacy rare.

La ricerca Reinventing with a Digital Core di Accenture, pubblicata il 17 luglio 2024 e basata su 1.500 dirigenti IT di livello C in 19 settori e 10 paesi, ha rilevato che le organizzazioni che uniscono un digital core avanzato, investimenti strategici in innovazione e un approccio equilibrato al debito tecnico ottengono una crescita dei ricavi fino al 60% più alta e profitti fino al 40% più alti. È un risultato condizionato e con un tetto, tratto dallo studio di Accenture, non un aumento garantito da un singolo progetto di modernizzazione. (newsroom.accenture.com)

La modernizzazione aumenta anche le opzioni strategiche. Quando le applicazioni principali espongono API affidabili, girano su piattaforme supportate e usano modelli di dati più puliti, l'azienda può introdurre più velocemente portali per i partner, percorsi self-service, prodotti di analisi, automazioni e assistenti di IA.

Un semplice volano dei benefici parte da un'architettura migliore, che permette rilasci più rapidi, che migliorano il feedback del business, che finanzia ulteriori semplificazioni.

Come si presenta una modernizzazione riuscita

I casi studio dei fornitori vanno letti come esempi, non come benchmark universali. Il caso OYAK ANKER Bank di Microsoft, pubblicato il 21 settembre 2026, racconta che la banca è passata da sistemi monolitici datati a servizi PaaS di Azure, tra cui App Services, Function Apps, Logic Apps, API Management e Azure SQL. Microsoft riporta il 100% di uptime durante la migrazione, lanci di prodotto circa l'80% più rapidi, il 55% dei carichi di lavoro automatizzati e una risoluzione degli incidenti il 50% più veloce: sono risultati dichiarati dal fornitore per quel caso bancario specifico. (microsoft.com)

Per un'azienda da 50-500 dipendenti lo stesso schema è spesso più piccolo, ma altrettanto importante. Un distributore all'ingrosso potrebbe sostituire una fragile applicazione di inserimento ordini con un workflow cloud-native e un livello di API. Un'azienda manifatturiera potrebbe spostare su nuova piattaforma il sistema di pianificazione della produzione mantenendo le integrazioni on-premise con le macchine. Uno studio professionale potrebbe dismettere flussi amministrativi su misura e passare a una piattaforma SaaS.

Il filo comune non è il marchio della tecnologia, ma la sequenza: scoprire, dare priorità, stabilizzare, modernizzare a fette, migrare i dati con attenzione, automatizzare la delivery e dismettere ciò che non serve più.

Misurate i risultati con una scheda bilanciata:

• Delivery: frequenza dei deployment, lead time delle modifiche, difetti sfuggiti in produzione.
• Affidabilità: frequenza degli incidenti, tempo di ripristino, disponibilità, error budget.
• Costi: riduzione delle licenze, costo dell'infrastruttura, ore di supporto.
• Sicurezza: vulnerabilità critiche, tempi di applicazione delle patch, rilievi sul controllo degli accessi.
• Business: tempi di onboarding, ciclo dell'ordine, self-service dei clienti, produttività del personale.

Il caso di business più solido unisce risparmi concreti e abilitazione della crescita. La modernizzazione deve liberare capacità dalla manutenzione a basso valore e spostarla su prodotti digitali, integrazioni, automazione e decisioni basate sui dati.

Per i responsabili digitali europei, modernizzare le applicazioni legacy è in fondo una questione di controllo: controllo su rischio, roadmap, costi, dati e ritmo del cambiamento. Ecco perché sostituire un software che «funziona ancora» può essere una delle decisioni tecnologiche più importanti dal punto di vista commerciale.

Se il sistema oggi è fragile, stabilizzatelo prima di sostituirlo: il servizio di stabilizzazione del software di WWG mette in sicurezza incidenti, rilasci e monitoraggio, così la sostituzione non parte in emergenza. Se prima vi serve una base di evidenze per decidere, un audit del software mappa codice, architettura, dipendenze e rischi dell'applicazione che state pensando di sostituire.

Contatta il nostro team di ingegneria →

Fonti

Le fonti seguenti sono state usate per verificare statistiche, date normative, casi studio e framework di modernizzazione citati nell'articolo. Quando un dato è dichiarato da un fornitore o deriva da un'analisi specifica del settore pubblico, l'articolo ne indica il perimetro e non lo tratta come benchmark universale.

• Eurostat — «53% EU enterprises used paid cloud services in 2025», pubblicato il 3 febbraio 2026. (ec.europa.eu)
• Eurostat — «20% of EU enterprises use AI technologies», pubblicato l'11 dicembre 2025. (ec.europa.eu)
• Commissione europea — «2026 State of the Digital Decade package», pubblicato il 17 giugno 2026. (digital-strategy.ec.europa.eu)
• UK DSIT — State of Digital Government Review, pubblicata il 21 gennaio 2025. (gov.uk)
• Accenture — «New Research from Accenture Finds that Digital Core Investments Accelerate Reinvention and Innovation», pubblicato il 17 luglio 2024. (newsroom.accenture.com)
• AWS Prescriptive Guidance — «About the migration strategies». (docs.aws.amazon.com)
• Martin Fowler — «Strangler Fig Application». (martinfowler.com)
• Commissione europea — «NIS2 Directive: securing network and information systems». (digital-strategy.ec.europa.eu)
• EUR-Lex — Direttiva NIS2, Direttiva (UE) 2022/2555, articoli 20 e 21. (eur-lex.europa.eu)
• ENISA — «EU financial entities cybersecurity upgrade: DORA is now alive and kicking», pubblicato il 17 gennaio 2025. (enisa.europa.eu)
• Commissione europea — «EU Data Act gives users control over data from connected devices», pubblicato il 12 settembre 2025. (digital-strategy.ec.europa.eu)
• EUR-Lex — GDPR, Regolamento (UE) 2016/679, articolo 32. (eur-lex.europa.eu)
• Microsoft Customer Stories — «OYAK ANKER Bank transforms operations on Microsoft Azure», pubblicato il 21 settembre 2026. (microsoft.com)