Cos'è un sistema legacy?

Un sistema legacy è un'applicazione o un'infrastruttura ancora in produzione, spesso al centro di processi critici, che è diventata difficile da cambiare: lo stack su cui gira non è più supportato o aggiornato, le competenze per intervenirci sono rare o concentrate in una sola persona, e il fornitore originale non offre più assistenza. Non è una questione di età: un sistema scritto vent'anni fa che riceve ancora patch, ha test e documentazione aggiornata non è legacy, mentre un'applicazione di cinque anni scritta senza test e mai più toccata può già esserlo. Il NIST la inquadra come un ambiente che deve restare sicuro contro minacce attuali pur usando meccanismi di comunicazione più vecchi e meno protetti, ed è proprio questo lo scarto che definisce il problema: il sistema continua a funzionare, ma il mondo che lo circonda, minacce, normative, aspettative di integrazione, non si è fermato.

Leggi anche: Modernizzazione del mainframe e del COBOL · Le strategie per portare applicazioni COBOL su mainframe verso assetti sostenibili: rehosting, conversione, riscrittura, API.

I segnali che lo tradiscono

Un sistema è legacy quando compaiono insieme alcuni segnali precisi. La piattaforma o il linguaggio non ricevono più aggiornamenti di sicurezza, oppure il fornitore ha dichiarato l'end of life. Nessun fornitore esterno offre più contratti di assistenza su quella versione. Le persone che conoscono davvero la logica interna sono una o due, spesso vicine alla pensione, ed è il caso di conoscenza tacita concentrata in poche teste invece che nella documentazione. Integrarlo con un sistema nuovo, un CRM, una dashboard, un modello di AI, richiede lavoro su misura invece di un'API standard. Nessuno di questi segnali da solo basta a dichiarare un sistema legacy: insieme, indicano un rischio che cresce ogni anno senza un piano.

Le opzioni, in sintesi

Le strategie disponibili si dispongono su uno spettro di rischio e costo. Tenerlo e incapsularlo: non toccare la logica interna, ma esporla con uno strato di integrazione che la rende consumabile dal resto dell'azienda, il principio dietro un anti-corruption layer. Rehosting: spostare il sistema così com'è su un'infrastruttura più moderna, guadagnando tempo senza risolvere il problema di fondo. Refactoring progressivo: sostituirlo un modulo alla volta dietro una facciata comune, il pattern noto come strangler fig, l'approccio più citato per casi come la modernizzazione AS/400, o del mainframe COBOL. Sostituzione completa: abbandonarlo per una piattaforma nuova, tipicamente un pacchetto standard, come avviene in una migrazione ERP, accettando il rischio di riscrivere anche la logica di business che funzionava.

Un esempio concreto

Una PMI della meccanica gestisce ordini e distinte base su un applicativo scritto su misura quindici anni fa. Gira ancora, ma il sistema operativo del server non riceve più patch e l'unico sviluppatore che lo conosce è un consulente esterno prossimo al ritiro. Invece di riscriverlo, l'azienda espone le sue funzioni con un'API per collegarlo al nuovo e-commerce e intanto documenta le regole di calcolo delle distinte, che nessuno aveva mai messo per iscritto.

Perché conta per chi decide

Non fare nulla ha un costo che cresce nel tempo. Un sistema senza patch di sicurezza è una superficie di attacco che si allarga ogni mese che passa. Normative come NIS2 o il GDPR chiedono di dimostrare controlli adeguati su ogni sistema che tratta dati critici, e un ambiente non più aggiornabile è difficile da mettere in regola. E il debito tecnico accumulato non è il sistema che continua a girare: è tutto ciò che non si può costruire sopra finché resta bloccato lì, mentre la persona che lo conosce davvero si avvicina alla pensione. Decidere quale strategia adottare, e quando, è più economico che farlo decidere da un incidente o da un turnover che nessuno ha pianificato.