Modernizzazione dei sistemi legacy: riscrivere, fare refactoring o sostituire gradualmente

Molte aziende sul mercato da diversi anni hanno un sistema di cui, in riunione, si parla con cautela. Su di esso girano la fatturazione, il magazzino o la produzione. È passato per molte mani, pochi lo conoscono nel dettaglio e ogni modifica è lenta e costosa.

Quando finalmente arriva il momento di decidere, sul tavolo compare di norma una frase: riscriviamo tutto da zero. Suona allettante, ma è rischioso: il vecchio codice è un archivio di regole di business, eccezioni e correzioni accumulate negli anni, che spesso nessuno ha messo per iscritto, e chi lo butta via in un colpo solo butta via anche questa conoscenza. Eppure la modernizzazione dei sistemi legacy non si riduce all’alternativa tra «lasciare com’è» e «riscrivere» e, per un sistema critico di grandi dimensioni, di solito è più sicuro sostituirlo per parti senza interrompere l’operatività.

Sintomi: il sistema che fa paura all’azienda

Michael Feathers, autore del libro Working Effectively with Legacy Code, definisce il codice legacy semplicemente come codice senza test. Un sistema legacy, quindi, non si riconosce dall’età, ma dalla possibilità di modificarlo in sicurezza. I sintomi tipici:

• Una sola persona che conosce il sistema. Quando se ne va, l’azienda perde la capacità di modificare un processo chiave.
• Paura dei rilasci. Le modifiche si accumulano in grandi blocchi, così in caso di errore è più difficile individuarne la causa.
• Tecnologie obsolete, per le quali è difficile trovare professionisti e che il produttore ha smesso di supportare.
• Rischi per la sicurezza che non si possono eliminare senza intervenire sul nucleo del sistema.
• Impossibilità di collegare nuovi strumenti. Il sistema non ha un layer API, cioè un’interfaccia definita per lo scambio di dati, quindi ogni collegamento con un e-commerce o con uno strumento di AI è un progetto a sé.

Sono tutte forme di debito tecnico: l’articolo Un’azienda è un solo prodotto lo affronta come principio che riguarda l’intera organizzazione.

Vale anche per lo Stato. In un rapporto del luglio 2025, l’ente di controllo statunitense GAO ha indicato gli 11 sistemi federali più critici che necessitano di modernizzazione. Otto di questi utilizzano linguaggi obsoleti come COBOL e assembler e sette, secondo le agenzie, funzionano con vulnerabilità note che senza modernizzazione non si possono eliminare.

Perché «riscriviamo tutto da zero» è così allettante

Il big bang rewrite consiste nel costruire un nuovo sistema da zero e nel far passare su di esso l’intera azienda in un colpo solo. Promette una ripartenza pulita e una tecnologia moderna. Joel Spolsky, in un saggio del 2000, aggiunge un motivo meno lusinghiero: i programmatori considerano il vecchio codice un pasticcio soprattutto perché leggere codice è più difficile che scriverlo. Definisce la riscrittura del codice da zero il peggior errore strategico che un’azienda di software possa commettere. Come esempio cita Netscape: la versione 6.0 è arrivata alla prima beta pubblica quasi tre anni dopo la versione 4.0 e nel frattempo la quota di mercato dell’azienda calava bruscamente.

È un’opinione netta, ma i meccanismi concreti del fallimento si possono identificare:

• Regole nascoste. Secondo Spolsky, le parti poco eleganti del vecchio codice sono spesso correzioni di bug emersi solo dopo settimane di utilizzo reale. La riscrittura le cancella e gli stessi errori possono ripresentarsi, di nuovo soltanto in produzione.
• Doppio sviluppo. Secondo gli autori di Thoughtworks, le normali richieste del business continuano a essere gestite nel vecchio sistema, così l’azienda paga due linee di sviluppo contemporaneamente.
• Un lungo periodo senza valore. Martin Fowler ricorda che sostituire un sistema IT di una certa importanza richiede molto tempo e che gli utenti non possono restare in attesa delle nuove funzionalità.
• Un bersaglio mobile. Gli autori di Thoughtworks descrivono un’organizzazione con una serie di programmi di modernizzazione di durata compresa tra tre e cinque anni. In ciascuno di essi le esigenze del business, nel frattempo cambiate, hanno superato la strategia tecnologica e si è ricominciato da capo. Dove il programma era impostato come big bang, questo ha significato buttare via la maggior parte del lavoro.

Sei opzioni e quando ha senso ciascuna

1. Mantenere e stabilizzare. Aggiungere il monitoraggio di errori e disservizi, i backup e la documentazione, formare una seconda persona che conosca il sistema. È la scelta giusta quando il sistema fa il suo lavoro e cambia di rado. Di solito è il modo più economico per ridurre il rischio.
2. Fare refactoring. Secondo Martin Fowler, il refactoring è un intervento sulla struttura interna del software che lo rende più comprensibile e meno costoso da modificare, senza cambiarne il comportamento osservabile. È indicato quando la tecnologia è adeguata, ma il codice è intricato.
3. Trasferire su una nuova infrastruttura, ad esempio da un server aziendale al cloud. Ha senso quando i punti dolenti sono la gestione operativa o l’hardware. Il trasferimento non cura una logica applicativa sbagliata.
4. Sostituire gradualmente. È adatto ai grandi sistemi critici che non possono fermarsi, il cui comportamento nessuno conosce per intero e che possono ancora funzionare a lungo in parallelo a quelli nuovi.
5. Acquistare una soluzione pronta. Per un processo standard, come la contabilità o la rilevazione delle presenze, lo sviluppo su misura è in genere superfluo, ma è il processo a doversi adattare al prodotto. Questa scelta è approfondita nell’articolo Sette SaaS o un solo sistema?
6. Dismettere. Se il sistema serve un processo che non esiste più, resta da verificare che altri sistemi o report non attingano ai suoi dati.

Strangler fig: il nuovo sistema cresce accanto al vecchio

Il nome strangler fig pattern deriva da una metafora di Martin Fowler: nel 2001, nelle foreste pluviali del Queensland, ha osservato i fichi strangolatori, che avvolgono progressivamente l’albero ospite fino a sostituirlo. Allo stesso modo il nuovo sistema non nasce al posto del vecchio, ma al suo fianco. Ne prende in carico le funzioni una dopo l’altra, finché il vecchio non può essere spento.

La documentazione di Microsoft ne descrive il meccanismo: tra gli utenti e i due sistemi si inserisce una facciata, cioè un intermediario che sposta gradualmente le richieste dal vecchio sistema al nuovo, ad esempio, in una prima fase, solo quelle per il calcolo dei preventivi. Gli utenti non sanno nulla della migrazione. Secondo Feathers, il vecchio sistema resta come riserva in caso di problemi.

Fowler ne ammette il costo: un’architettura transitoria per far funzionare in parallelo i due sistemi, destinata a scomparire a lavoro concluso. A suo avviso, il rischio più basso e il valore ottenuto prima lo compensano, perché le parti sostituite sono piccole. Avverte però che, senza un cambiamento della cultura e del management, anche il nuovo sistema finirà in un pasticcio simile.

I dati sono la parte più difficile

Il codice si può sostituire un pezzo alla volta, ma durante la transizione i dati servono a entrambi i sistemi contemporaneamente. La migrazione dei dati, cioè il trasferimento delle informazioni dalla vecchia struttura alla nuova, non è una semplice copia. I ricercatori del Trinity College Dublin avvertono che i dati dei sistemi legacy tendono a essere di scarsa qualità, vanno mappati sulla nuova struttura e in molti casi anche ripuliti. In pratica si tratta, ad esempio, di duplicati, di campi usati per altri scopi e di valori che solo il vecchio codice sa interpretare.

Microsoft raccomanda di separare i dati gradualmente, un’area alla volta: popolare il nuovo database con un caricamento iniziale, propagare gli aggiornamenti successivi con la tecnica del change data capture, cioè intercettando le modifiche nel vecchio database, verificare che i dati coincidano prima del passaggio ed eliminare i vecchi oggetti solo dopo la validazione del nuovo sistema. Fino ad allora si può tornare indietro, dopo diventa molto più complesso e rischioso.

Durante la transizione deve essere chiaro, per ogni tipo di dato, quale sistema rappresenta l’unica fonte di verità. Se l’indirizzo di un cliente si può modificare in entrambi i sistemi, c’è il rischio che ciascuno ne riporti uno diverso. La nostra conclusione pratica: un determinato dato le persone devono modificarlo sempre in un solo sistema e gli altri sistemi si limitano a riprenderlo da lì. Al ruolo più ampio dei dati è dedicato l’articolo I vostri dati sono il vantaggio.

Come scoprire che cosa fa davvero il sistema

Feathers fa notare che le persone hanno in testa un’idea di ciò che il sistema fa e dimenticano di andare a vedere che cosa fa in realtà. Sono utili tre fonti:

• Osservazione degli utenti. Guardare che cosa fanno le persone con il sistema, non che cosa ne raccontano. Qui emergono i workaround, i fogli di calcolo tenuti a parte e i passaggi manuali.
• Log, cioè le registrazioni dell’attività del sistema. Mostrano quali funzioni vengono usate, con quale frequenza e da chi, e aiutano a scoprire dipendenze inattese.
• Test del comportamento attuale. Feathers descrive i test di caratterizzazione: si pone una domanda al codice e la risposta ottenuta viene registrata come risultato atteso. Nascono così i test di regressione, cioè controlli automatici che dopo ogni modifica verificano che ciò che funzionava continui a funzionare.

Gli autori di Thoughtworks raccontano di un team che stava testando in produzione la sostituzione di un middleware di integrazione, cioè del software che collega gli altri sistemi. Poco dopo, i report direzionali critici hanno smesso di quadrare. Al termine di una lunga indagine si è scoperto che il database del middleware veniva replicato in un data warehouse da cui i report attingevano i dati. A risolvere la situazione è stato solo un meccanismo temporaneo che integrava nel data warehouse i dati mancanti.

L’ordine: il problema più sentito, il rischio più basso

La migrazione non deve essere il primo passo. Anche qui applichiamo l’ordine Remove, Simplify, Automate, Augment: prima eliminare, poi semplificare e solo dopo automatizzare ed estendere. Gli autori di Thoughtworks osservano che la maggior parte dei sistemi legacy, col tempo, si gonfia di funzionalità che nessuno usa, e citano un rapporto dello Standish Group del 2014 secondo cui si tratta del 50% delle funzionalità. Per un sistema specifico è solo un dato indicativo: la realtà la mostrano i log. Una funzionalità eliminata non va analizzata, né migrata, né testata, e i workaround per aggirare i limiti del vecchio sistema conviene semplificarli durante il trasferimento, non copiarli.

La prima parte da sostituire dovrebbe creare un disagio tangibile, ad esempio frenare l’attività commerciale, ed essere allo stesso tempo relativamente separata dal nucleo. Feathers consiglia di concentrarsi sulle parti che cresceranno e che nel contempo creano difficoltà e, per deviare le richieste, di individuare le «cuciture» (seam), come chiama i punti in cui un comportamento può essere sostituito da un altro.

I rischi e come misurarli durante la transizione

La sostituzione graduale non elimina il rischio, lo suddivide in parti più piccole e misurabili. Il caso opposto emerge dalla decisione del regolatore britannico FCA del 20 dicembre 2022. Nel fine settimana dal 20 al 22 aprile 2018, la banca TSB ha trasferito la maggior parte dell’operatività e dei dati dei clienti su una piattaforma nuova, non ancora collaudata. Sono seguiti gravi problemi con l’internet banking e il mobile banking, oltre che con i pagamenti con carta, ed entro il 7 aprile 2019 la banca aveva ricevuto 225.492 reclami. La FCA ha riscontrato carenze nella pianificazione, nei test, nella gestione dei rischi e nella supervisione del fornitore esterno, ha sottolineato che dopo l’avvio la banca non aveva di fatto la possibilità di tornare alla piattaforma originaria e le ha irrogato una sanzione di 29,75 milioni di GBP.

Vicent Martí di GitHub ha descritto nel 2015 una strada più sicura. Il team stava sostituendo una delle parti più critiche del codice direttamente in produzione: il vecchio e il nuovo codice giravano in parallelo, i risultati venivano confrontati e l’utente riceveva sempre il risultato del vecchio. L’esperimento è partito dall’1% delle richieste e si è esteso gradualmente, fino a girare per 24 ore sul 100% del traffico senza discrepanze. Il confronto ha inoltre fatto emergere 2 bug gravi nella soluzione originale, che per anni nessuno aveva individuato.

Che cosa monitorare, quindi:

• La corrispondenza dei risultati tra la vecchia e la nuova soluzione su dati reali, prima del passaggio.
• Il tasso di errore e le prestazioni dopo ogni reindirizzamento.
• La via del ritorno: con quale rapidità l’azienda può tornare alla situazione di partenza.
• La coerenza dei dati e il numero di correzioni manuali.
• La quota di operatività presa in carico dal nuovo sistema. Se per lungo tempo non cresce, il progetto si trasforma in una doppia gestione senza fine.

Quando una riscrittura completa è giustificata

Riscrivere tutto da capo non è sempre un errore. Feathers lo descrive come una decisione di business legata al ritorno dell’investimento, ma lui stesso prova prima con il refactoring e ricorda che nella maggior parte dei casi non è necessario riscrivere l’intero sistema e che le riscritture mirate di singole parti sono spesso molto efficaci. Microsoft indica quando la sostituzione graduale non è adatta: il sistema è piccolo e si può sostituire facilmente per intero, non si ha accesso al codice sorgente oppure la soluzione originaria va dismessa in tempi rapidi. Gli autori di Thoughtworks ammettono la replica fedele delle vecchie funzionalità per i sistemi con una specifica ben nota, in cui a un dato input deve corrispondere un dato output, ma considerano questi casi eccezionali.

La nostra opinione: una riscrittura è difendibile anche quando il business è cambiato al punto che il vecchio sistema supporta un modo di lavorare che l’azienda sta abbandonando. In quel caso, però, si tratta di un nuovo prodotto con nuovi requisiti, non di una copia delle vecchie funzionalità.

Per questo la modernizzazione dei sistemi legacy non comincia dalla scelta della tecnologia, ma dal capire quale lavoro svolge il sistema per l’azienda, quali sue parti si usano davvero e dove nasce esattamente il problema. Chi salta questa diagnosi sceglie alla cieca tra riscrittura e refactoring.

Cosa portarsi a casa

• Non scegliete solo tra «lasciare com’è» e «riscrivere», ma tra sei opzioni. La stabilizzazione, una soluzione pronta o la dismissione costano spesso meno di una riscrittura.
• Prima della migrazione scoprite che cosa fa davvero il sistema: con l’osservazione delle persone, con i log e con i test del comportamento attuale.
• Eliminate prima le funzionalità inutilizzate, altrimenti le migrerete e le testerete inutilmente.
• Sostituite un grande sistema critico per parti: cominciate da dove il problema è più sentito e il rischio più basso, e assicuratevi una via di ritorno.
• Per ogni tipo di dato definite un’unica fonte di verità e misurate la corrispondenza dei risultati, il tasso di errore e la quota di operatività presa in carico dal nuovo sistema.