Blog

Legacy e innovazione tra refactor e progetti greenfield

Il tema del legacy code non è soltanto una questione tecnica, ma una variabile strategica che influenza la capacità delle aziende di innovare. Nella maggior parte delle organizzazioni IT, il codice esistente rappresenta al tempo stesso un asset e un vincolo: custodisce logiche di business fondamentali e garantisce continuità operativa, ma porta con sé complessità accumulate, dipendenze obsolete e costi crescenti di manutenzione.

La portata del problema è ben documentata. Secondo Gartner, oltre il 70% del budget IT medio è assorbito da manutenzione e gestione del legacy, lasciando uno spazio ridotto per iniziative di innovazione. Stripe stima che gli sviluppatori spendano circa il 33% del loro tempo a gestire debito tecnico, con un impatto diretto sulla velocità di rilascio (The Developer Coefficient Report). McKinsey evidenzia che aziende con elevato debito tecnico vedono i loro cicli di rilascio rallentare fino al 60%, con un aumento dei costi di progetto del 20–40%.

In parallelo, la pressione competitiva spinge verso nuove iniziative: sperimentare prodotti digitali, adottare architetture cloud-native, integrare AI e automazione. La tensione è evidente: dedicare risorse al refactoring rallenta la capacità di innovare, mentre concentrarsi solo su progetti greenfield rischia di generare nuovo debito tecnico e di compromettere la stabilità dei sistemi core.

Bilanciare queste due forze è diventato quindi un tema di governance IT: non si tratta più di scegliere tra manutenzione o innovazione, ma di orchestrare un percorso in cui la riduzione del debito tecnico e lo sviluppo di nuove capacità digitali procedano in parallelo, supportati da metriche oggettive e da una visione strategica di lungo periodo.

Perché il legacy non può essere ignorato

Nessuna organizzazione può permettersi di trattare il legacy code come un problema secondario. La gestione del debito tecnico è infatti un tema che impatta direttamente su velocità di rilascio, costi operativi e resilienza dei sistemi.

Uno studio McKinsey (2020) mostra che team con alto debito tecnico vedono aumentare del 60% il time-to-market per nuove funzionalità rispetto ai team con codebase moderne. Questo rallentamento diventa critico in contesti dove la capacità di innovare è un fattore competitivo decisivo.

Gli effetti concreti più ricorrenti includono:

• Riduzione della produttività: sviluppatori che passano più tempo a correggere bug e gestire regressioni che a creare valore nuovo.
• Aumento dei rischi di sicurezza: componenti non aggiornati, librerie deprecate e architetture non più supportate aprono vulnerabilità critiche.
• Costi di manutenzione crescenti: secondo IDC, il costo operativo di sistemi legacy può arrivare a essere 2–3 volte superiore rispetto a soluzioni moderne basate su cloud e architetture modulari.
• Limitazioni architetturali: un monolite scritto in linguaggi datati rende complesso introdurre modelli cloud-native, API-first o servizi basati su AI.

Non va però dimenticato che il legacy spesso incorpora conoscenza di dominio unica e processi mission-critical difficilmente sostituibili in tempi brevi. Proprio per questo il tema non è “eliminare il vecchio per fare spazio al nuovo”, ma definire una strategia di evoluzione graduale in cui stabilità e innovazione procedano di pari passo.

Refactoring come investimento

Il refactoring è spesso percepito come un costo, un’attività “a basso impatto visibile” rispetto allo sviluppo di nuove feature. In realtà rappresenta un investimento strategico: migliora la qualità del codice, riduce i rischi operativi e, soprattutto, crea le condizioni per innovare in modo sostenibile. In assenza di un refactoring mirato, ogni nuovo progetto rischia di innestarsi su una base fragile, amplificando i problemi anziché risolverli.

Approcci e pattern consolidati

Il refactoring non implica necessariamente la riscrittura completa di un sistema: si tratta piuttosto di interventi mirati e progressivi. Alcuni modelli consolidati includono:

• Strangler Fig Pattern: introdotto da Martin Fowler, consiste nel sostituire gradualmente componenti legacy con nuovi moduli, lasciando che la parte obsoleta “muoia” lentamente. Questo approccio riduce al minimo i rischi di downtime e consente di validare passo dopo passo l’architettura moderna.
• Refactoring incrementale: anziché grandi progetti “big bang”, si interviene su porzioni mirate del codice, spesso identificate tramite hotspot analysis, cioè l’incrocio tra la complessità del codice e la sua frequenza di modifica. In questo modo, gli sforzi si concentrano dove l’impatto è massimo.
• Refactoring opportunistico: introdurre miglioramenti minori ogni volta che un modulo viene toccato per nuove feature o bug fixing. È un modo per distribuire i costi e costruire una cultura della qualità continua.

Metriche per misurare il progresso

Uno degli errori più comuni è trattare il refactoring come attività invisibile e difficile da quantificare. Per questo, è cruciale legarlo a metriche oggettive, che consentano di giustificare le scelte tecniche agli stakeholder:

• Code Complexity: indici come la complessità ciclomatica o il coupling tra moduli permettono di misurare quanto un codice sia comprensibile e modificabile.
• Coverage dei test automatizzati: ogni refactor ben eseguito aumenta la robustezza della suite di test.
• Technical Debt Ratio (TDR): proposto da Gartner, rapporta il costo del debito tecnico al costo di riscrittura dell’intero sistema.
• Change Lead Time: uno degli indicatori DORA, misura il tempo medio tra l’ideazione e il rilascio di una modifica.

Strumenti a supporto

Il mercato offre numerosi strumenti che aiutano i team a identificare, monitorare e gestire il debito tecnico: SonarQube e CodeScene per l’analisi statica e la visualizzazione di hotspot, OpenRewrite per refactoring automatizzati, e le pipeline CI/CD (GitHub Actions, GitLab CI, Jenkins) per garantire test e controlli di qualità continui.

Benefici attesi

Investire nel refactoring significa sbloccare valore su più livelli: maggiore produttività e onboarding più rapido, riduzione dei bug e dei rischi in produzione, sostenibilità economica grazie a cicli incrementali e capacità di integrare più facilmente API, servizi cloud e componenti AI.

Il refactoring non è un lusso né una deviazione dalle priorità di business: è una forma di manutenzione evolutiva che riduce il debito tecnico e prepara il terreno per l’innovazione futura.

Innovazione e progetti greenfield

Se il refactoring rappresenta la via per migliorare ciò che esiste, i progetti greenfield incarnano l’opportunità di costruire da zero soluzioni moderne, libere dai vincoli del passato. Consentono di adottare subito architetture cloud-native, microservizi, design API-first e pratiche DevSecOps, accelerano la validazione di nuove funzionalità tramite MVP e rendono più stimolante il lavoro dei team.

D’altro canto, lanciarsi in progetti greenfield senza una governance chiara può generare nuovo debito tecnico già nelle fasi iniziali. Non va sottovalutato nemmeno il fattore tempo: costruire da zero richiede cicli lunghi di sviluppo e test, e spesso i business owner non possono attendere mesi per ottenere le prime funzionalità.

Il refactoring, al contrario, garantisce continuità: ogni intervento produce benefici immediati, riduce i rischi di downtime e mantiene allineati gli sviluppatori con la logica di dominio già consolidata. Tuttavia, focalizzarsi solo sul legacy rischia di intrappolare i team in un ciclo infinito di manutenzione, rallentando l’adozione di tecnologie emergenti e limitando la capacità di differenziarsi sul mercato.

In prospettiva strategica, la chiave è nel bilanciamento: i progetti greenfield devono essere selettivi, mirati alle aree dove l’innovazione può generare maggiore vantaggio competitivo, mentre il refactoring deve essere continuo, incrementale e guidato da metriche. Solo un approccio ibrido consente di preservare la stabilità operativa e al tempo stesso aprire nuove traiettorie di crescita digitale.

Strategie di modernizzazione: oltre refactor e greenfield

Il bilanciamento tra refactoring e innovazione non esaurisce l’insieme delle possibilità a disposizione dei team IT. Nella pratica, le aziende adottano una gamma più ampia di strategie di modernizzazione, spesso ricondotte al framework delle 8R proposto da Gartner: replatform, rearchitect, replace e retain sono alcune delle opzioni più diffuse. Integrare queste possibilità nella roadmap aiuta CIO e tech lead a evitare decisioni binarie e a comporre percorsi ibridi e incrementali, calibrati su valore di business e criticità tecnica.

Come bilanciare refactor e innovazione

Trovare il giusto equilibrio tra manutenzione del legacy e sviluppo di nuovi progetti non è un esercizio di stile, ma una scelta di governance che incide direttamente sulla capacità di un’organizzazione di innovare senza compromettere la continuità operativa.

Un criterio ricorrente è quello di allocare intenzionalmente il tempo e le risorse. Modelli come il famoso “70/20/10” non hanno valore prescrittivo, ma servono a ricordare che la manutenzione dei sistemi core non può assorbire l’intera capacità dei team, così come l’innovazione radicale non può diventare l’unica voce in agenda. In molte realtà la proporzione si ridisegna continuamente: nelle fasi di consolidamento l’ago della bilancia pende verso il refactoring, mentre nei momenti di espansione prevalgono i progetti greenfield.

Un altro approccio utile è quello portafoglio, che invita a guardare alle iniziative IT come a un insieme bilanciato di investimenti. Il refactoring rappresenta il “titolo a basso rischio”: non genera entusiasmo immediato, ma protegge l’azienda da perdite maggiori nel futuro. I progetti greenfield, invece, hanno la natura della “scommessa ad alto rendimento”: possono fallire, ma se riescono creano differenziali competitivi significativi.

Per rendere queste decisioni meno soggettive e più ancorate alla realtà, diventano indispensabili metriche affidabili. Le DORA metrics permettono di capire se una codebase sta accelerando o frenando la capacità di rilascio. Indicatori come il Technical Debt Ratio o il Cost of Delay aiutano a misurare rispettivamente il peso del debito tecnico e l’impatto economico del rinviare una nuova funzionalità.

Infine, nessuna formula tecnica può prescindere dall’allineamento con la strategia aziendale. Un’istituzione finanziaria regolamentata non avrà lo stesso grado di tolleranza al rischio di un’azienda SaaS che compete sulla velocità di innovazione. Il bilanciamento tra refactoring e greenfield riflette, in ultima analisi, la cultura organizzativa, il livello di maturità digitale e la propensione al rischio.

AI e automazione nel refactoring

Negli ultimi anni, l’Intelligenza Artificiale ha introdotto nuove possibilità per accelerare la gestione del debito tecnico e la modernizzazione del legacy. I Large Language Model (LLM), ad esempio, supportano la comprensione del codice obsoleto e la generazione di documentazione. Altri approcci includono: Natural Language Processing per tradurre codice legacy in linguaggi moderni, Reinforcement Learning per ottimizzare dinamicamente le strategie di migrazione, e Deep Learning per automatizzare test di regressione e validazioni sui sistemi migrati.

Queste tecniche, già integrate in strumenti commerciali e open source, consentono di ridurre tempi e costi di refactoring, aumentando al contempo l’accuratezza delle migrazioni. È importante, tuttavia, considerare l’AI come un acceleratore e non come un sostituto della governance tecnica e del contributo umano: senza un quadro di metriche e priorità chiare, anche i sistemi più avanzati rischiano di generare nuovo debito.

Bilanciare refactoring e innovazione non è un esercizio astratto: richiede strumenti, metriche e processi chiari. Il rischio più comune è trattare il refactoring come un’attività “di serie B”, sacrificata in nome delle nuove feature. Al contrario, i team più efficaci lo considerano parte integrante della delivery, pianificandolo e misurandolo con la stessa attenzione riservata alle roadmap di prodotto.

Il bilanciamento non è mai definitivo, ma un processo iterativo e misurabile. Un team che adotta un approccio basato su metriche e framework, non solo sull’intuizione, sarà in grado di gestire il debito tecnico, preservare la stabilità dei sistemi core e, allo stesso tempo, aprire la strada a progetti innovativi.

Bibliografia e Fonti:

• Cunningham, W. (1992). The WyCash Portfolio Management System. OOPSLA Experience Report – introduzione del concetto di Technical Debt.
• Gartner (2019). 7 Options to Modernize Legacy Systems. Gartner.
• Stripe (2018). The Developer Coefficient: Software Engineering Productivity.
• Forsgren, N., Humble, J., Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution Press – introduzione delle DORA metrics.
• McKinsey & Company (2020). Tech Debt: Reclaiming Tech Equity.
• IDC (2021). Future of Digital Infrastructure: Modernization Imperatives.
• Fowler, M. (2018). Strangler Fig Application. martinfowler.com.
• Assunção, W. K., Marchezan, L., Egyed, A., & Ramler, R. (2024). Contemporary Software Modernization: Perspectives and Challenges to Deal with Legacy Systems. arXiv preprint arXiv:2407.04017.
• Somula, S. R. (2025). Legacy System Modernization: Strategic Imperatives and Transformation Metrics in Digital Evolution. International Journal of Scientific Research in Computer Science, Engineering and Information Technology, 11(1), 2597–2606.
• Mishra, A. (2025). Legacy System Modernization: Effective Strategies and Best Practices. IJLRP – International Journal of Leading Research Publication, 1(3).

Autore: Martina Pegoraro