C'è un numero che dovrebbe terrorizzare ogni CTO nel settore bancario e assicurativo: dal 60 all'80 percento. È la quota dei budget IT che la maggior parte delle istituzioni finanziarie spende per mantenere i sistemi legacy — non per costruire nuove funzionalità, non per innovare, non per rispondere ai cambiamenti del mercato. Solo per tenere le luci accese.
Ho passato oltre 12 anni a costruire e modernizzare software enterprise per organizzazioni in finanza, assicurazioni, difesa ed energia. Ho visto piattaforme di core banking in COBOL scritte prima che esistesse internet. Ho visto sistemi di gestione sinistri dove una singola richiesta di modifica richiede 6 mesi e costa 200.000€. E ho visto cosa succede quando le organizzazioni finalmente decidono di modernizzare — sia i successi che i fallimenti spettacolari.
Questo articolo è la guida che avrei voluto avere quando ho iniziato a lavorare sulla modernizzazione dei legacy. È scritto per il decision maker — il CTO, CIO o VP of Engineering — che sa che i propri sistemi devono cambiare ma non è sicuro da dove iniziare, quanto costerà o come evitare le storie dell'orrore.
Il Vero Costo di Mantenere in Vita i Sistemi Legacy
Permettetemi di essere diretto: il costo più grande dei sistemi legacy non è la manutenzione. È il costo opportunità. Ogni euro e ogni ora-ingegnere spesa a patchare un sistema di 25 anni è un euro e un'ora non spesa su prodotti digitali che potrebbero aprire nuovi flussi di ricavo, migliorare la customer experience o darti un vantaggio competitivo.
I Costi Visibili
- Contratti di manutenzione: I vendor legacy applicano tariffe premium per il supporto su sistemi a fine vita. Ho visto contratti di supporto mainframe che costano 2-5M€ all'anno per una singola istituzione.
- Talento specializzato: Sviluppatori COBOL, programmatori RPG e specialisti mainframe stanno andando in pensione più velocemente di quanto possano essere sostituiti. Quelli ancora disponibili chiedono 150-250€/ora.
- Overhead di integrazione: Ogni nuovo prodotto digitale deve connettersi ai sistemi legacy attraverso integrazioni fragili e custom-built che si rompono ogni volta che qualcosa cambia.
- Onere di conformità: Soddisfare i nuovi requisiti normativi (DORA, PSD3, Open Banking) su architetture legacy richiede workaround su workaround.
I Costi Nascosti
- Time to market: Una funzionalità che a una fintech richiede 2 settimane, a una banca vincolata ai legacy ne richiede 6-12 mesi. È questo il gap che sta uccidendo gli incumbent.
- Attrazione dei talenti: I migliori ingegneri non vogliono lavorare su COBOL. Stai competendo per il talento con uno stack tecnologico del 1985.
- Esposizione alla sicurezza: I sistemi legacy spesso non supportano i protocolli di sicurezza moderni, creando superfici d'attacco che si allargano ogni anno.
- Silos di dati: I dati aziendali critici sono intrappolati in sistemi che non comunicano tra loro, rendendo impossibile costruire una vista unificata del cliente.
Il Parere di Michele
Dico a ogni dirigente la stessa cosa: la domanda non è se potete permettervi di modernizzare. La domanda è se potete permettervi di non farlo. Ogni mese che ritardate, fintech e insurtech stanno costruendo il futuro che i vostri clienti prima o poi pretenderanno. Il costo della modernizzazione è fisso. Il costo dell'inazione si moltiplica.
Le 5 Strategie di Modernizzazione (E Quando Usarle)
Non esiste un unico modo giusto per modernizzare. L'approccio corretto dipende dalla criticità del sistema, dalla qualità del codice esistente e da quanta disruption potete tollerare. Ecco i cinque pattern che ho utilizzato in decine di progetti enterprise.
1. Incapsulare (API Wrapper)
Cos'è: Si mantiene il sistema legacy in funzione ma lo si avvolge con API moderne, permettendo alle nuove applicazioni di interagire attraverso interfacce pulite invece di accesso diretto al database o integrazioni basate su file.
Ideale per: Sistemi che funzionano correttamente ma sono difficili da integrare. Ledger di core banking, sistemi di amministrazione polizze o motori sinistri stabili ma isolati. Rischio: Basso.
2. Rehost (Lift and Shift nel Cloud)
Cos'è: Si sposta il sistema legacy dall'infrastruttura on-premise al cloud senza modificare il codice applicativo. Riduce i costi infrastrutturali e migliora la scalabilità. Rischio: Da basso a medio.
3. Replatform (Modernizzare lo Stack)
Cos'è: Si migra l'applicazione su una piattaforma moderna — ad esempio, da un database Oracle on-premise a PostgreSQL cloud-native, o da un application server J2EE monolitico a microservizi containerizzati. Rischio: Medio.
4. Refactor (Il Pattern Strangler Fig)
Cos'è: Si sostituiscono progressivamente parti del sistema legacy con nuovi servizi moderni. I sistemi vecchio e nuovo funzionano in parallelo, con il traffico che si sposta gradualmente. È l'approccio che raccomando per la maggior parte delle piattaforme di core banking e assicurative. Rischio: Medio.
Lo Strangler Fig nella Pratica
Ho guidato progetti dove abbiamo estratto un microservizio alla volta da una piattaforma assicurativa monolitica — partendo dal modulo meno critico (generazione documenti) per provare il pattern, poi passando progressivamente alla gestione polizze e sinistri. In 18 mesi, il 60% del sistema girava su architettura moderna mentre il core legacy continuava a gestire il resto. Zero downtime. Zero perdita di dati.
5. Sostituire (Riscrittura Completa)
Cos'è: Si costruisce un sistema completamente nuovo da zero. Ideale per: Sistemi piccoli e isolati dove il codice esistente è irrecuperabile. Rischio: Alto.
Attenzione
La trappola della riscrittura completa: Ho visto più progetti di modernizzazione fallire a causa di riscritture big-bang che per qualsiasi altra causa. La tentazione di "ripartire da zero" è forte, ma la realtà è che i sistemi legacy contengono decenni di logica di business accumulata — gran parte non documentata. La mia regola: riscrivi solo ciò che puoi permetterti di sbagliare per 6 mesi.
Un Framework Decisionale: Quale Strategia per Quale Sistema?
| Fattore | Incapsulare | Rehost | Replatform | Refactor | Sostituire |
|---|---|---|---|---|---|
| La logica di business è solida | ✓ | ✓ | ✓ | ✓ | — |
| Il codice è mantenibile | ✓ | ✓ | Parziale | — | — |
| Servono UX/API moderne | ✓ | — | — | ✓ | ✓ |
| Budget indicativo | 200K-500K€ | 100K-300K€ | 300K-800K€ | 500K-2M€ | 1M-5M+€ |
| Timeline | 2-4 mesi | 1-3 mesi | 3-6 mesi | 6-18 mesi | 12-36 mesi |
I 7 Errori che Uccidono i Progetti di Modernizzazione
- Iniziare dal sistema più critico. Il vostro ledger di core banking non è il posto dove imparare. Iniziate da un sistema a rischio inferiore.
- Sottovalutare la migrazione dati. La migrazione dati rappresenta tipicamente il 40-60% dello sforzo. È noiosa, è caotica, ed è dove i progetti muoiono in silenzio.
- Nessun piano di rollback. Ogni passo della modernizzazione dovrebbe essere reversibile.
- Ignorare le persone. La migrazione tecnica è la parte facile. Far adottare nuovi workflow a 500 operativi è la parte difficile. Prevedete almeno il 20% del budget per change management.
- Scegliere la tecnologia prima di capire il problema. "Ci spostiamo sui microservizi" non è una strategia.
- Nessuna consegna di valore incrementale. Se il progetto non porta valore misurabile entro 6 mesi, perderete lo sponsorship esecutivo.
- Trattarlo come un progetto IT. La modernizzazione legacy è una trasformazione di business. Serve ownership di business, non solo IT.
Costruire il Business Case: Come Ottenere il Buy-In Esecutivo
La sfida più grande nella modernizzazione legacy non è tecnica — è politica. Ecco come aiuto i clienti a costruire un business case che viene approvato.
- Quantificate il costo del non fare nulla: Calcolate il costo annuale totale di manutenzione: licenze, contratti di supporto, personale dedicato, manutenzione integrazioni e costo delle feature ritardate.
- Modellate l'impatto sul fatturato: Per ogni mese in cui un nuovo prodotto digitale è ritardato, calcolate l'opportunità di ricavo persa.
- Presentate una roadmap a fasi: Non presentate mai la modernizzazione come un singolo progetto da 10M€. Dividetela in fasi con milestone chiare.
Il Parere di Michele
Il pitch di modernizzazione di maggior successo che ho visto seguiva questa struttura: "Spendiamo 3.2M€/anno per mantenere il Sistema X. Con 400K€ possiamo modernizzare il Modulo A in 4 mesi, riducendo i costi di manutenzione di 600K€/anno e abilitando la Feature Y che le Vendite chiedono da tempo."
Il Ruolo dell'AI nella Modernizzazione Legacy
Dal 2024, l'AI ha iniziato a giocare un ruolo significativo nella modernizzazione legacy — non nel modo hype promesso dai vendor, ma in applicazioni specifiche e pratiche.
- Comprensione del codice: Strumenti AI come Claude e GPT-4 possono leggere e spiegare codice COBOL o RPG legacy, aiutando gli sviluppatori moderni a capire la logica di business.
- Generazione automatica di test: L'AI può generare suite di test dal codice legacy, creando una rete di sicurezza prima di iniziare le modifiche.
- Recupero della documentazione: Per sistemi dove la documentazione è incompleta, l'AI può analizzare codice e schemi database per ricostruire regole di business e flussi dati.
- Assistenza alla migrazione: L'AI può tradurre pattern di codice da linguaggi legacy a equivalenti moderni — non perfettamente, ma abbastanza bene da accelerare il processo del 30-40%.
Presso Lasting Dynamics, abbiamo integrato l'AI nel nostro workflow di modernizzazione specificamente per la comprensione del codice COBOL e la generazione automatica di test. Non sostituisce la necessità di architetti esperti, ma riduce significativamente il tempo richiesto per la fase di discovery e analisi.
Come Si Presenta il Successo: Una Timeline Realistica
| Fase | Durata | Deliverable | Impatto Business |
|---|---|---|---|
| Discovery & Assessment | 4-6 settimane | Inventario sistemi, mappa dipendenze, valutazione rischi | Visione chiara di cosa avete e cosa deve cambiare |
| Layer API (Incapsulamento) | 2-4 mesi | API moderne sopra il core legacy | Nuovi prodotti digitali senza toccare il codice legacy |
| Migrazione Primo Modulo | 3-6 mesi | Un dominio di business su architettura moderna | Prova che la modernizzazione funziona |
| Migrazione Progressiva | 12-24 mesi | Sistemi core migrati incrementalmente | Costi di manutenzione -30-50%, time-to-market 3-5x più veloce |
| Decommissioning Legacy | 3-6 mesi | Vecchi sistemi spenti | Risparmi completi realizzati |
Timeline totale: da 18 a 36 mesi per una trasformazione completa. Ma il punto chiave è che iniziate a consegnare valore dal mese 3, non dal mese 36.
La Conclusione
La modernizzazione dei sistemi legacy non è un progetto tecnologico. È una decisione strategica sulla capacità della vostra organizzazione di competere nel prossimo decennio.
La buona notizia: non dovete fare tutto in una volta. Iniziate con l'assessment. Capite cosa avete, quanto vi costa e cosa c'è in gioco. Poi scegliete la strategia giusta per ogni sistema ed eseguite a fasi che consegnano valore misurabile ogni trimestre.
“Il momento migliore per iniziare a modernizzare era cinque anni fa. Il secondo migliore è questo trimestre.”
— Michele Cimmino