Legacy non è una parolaccia: quando NON riscrivere da zero

“Il nostro sistema è vecchio, buttiamo tutto e ripartiamo da zero.” È una delle richieste che sento più spesso, ed è quasi sempre la conclusione sbagliata tratta da una diagnosi giusta: il sistema è effettivamente difficile da mantenere, lento ad accogliere nuove funzionalità, costruito su tecnologie che pochi conoscono più bene. Il problema è reale. La riscrittura completa, però, è quasi sempre la risposta più rischiosa e più costosa a quel problema, non la più efficace.

Il motivo per cui le riscritture falliscono così spesso

Un sistema legacy, per quanto disordinato, incorpora anni di decisioni di business validate dalla realtà: casi limite scoperti da clienti reali, regole fiscali specifiche, eccezioni che esistono perché un cliente importante le ha richieste tre anni fa e nessuno ricorda più il perché — ma se le togli, quel cliente se ne accorge. Riscrivere da zero significa, quasi sempre, riscoprire tutte queste regole una per una, spesso a costo di errori in produzione che il sistema vecchio non avrebbe mai fatto.

C’è poi un problema di tempo: durante una riscrittura completa, il team che dovrebbe lavorare sul nuovo sistema è quasi sempre anche l’unico in grado di mantenere il vecchio, che nel frattempo deve continuare a funzionare. Il risultato tipico è un progetto di riscrittura che dura il doppio del previsto, con un sistema vecchio sempre più trascurato nel frattempo.

Cosa guardo prima di consigliare una riscrittura

Quando faccio un audit su un sistema legacy, la domanda che mi pongo non è “è vecchio?” ma “dove sta davvero il costo di mantenerlo così com’è, e quel costo è più alto del rischio di cambiarlo?” In pratica, valuto separatamente:

Il rischio di sicurezza. Dipendenze non aggiornate da anni, vulnerabilità note, dati sensibili gestiti senza gli standard minimi attuali — qui l’intervento è spesso urgente e non negoziabile, ma non richiede necessariamente una riscrittura totale: spesso basta un lavoro mirato di aggiornamento e messa in sicurezza.

Il costo di manutenzione reale, misurato in ore spese al mese su bug e piccole modifiche, non percepito. A volte un sistema “brutto” ma stabile costa meno di quanto sembri, perché semplicemente nessuno lo tocca quasi mai.

La capacità di accogliere crescita. Se il vero problema è che il sistema non regge il carico attuale, o non permette di aggiungere le funzionalità che il business richiede per crescere, allora il costo di non intervenire supera rapidamente quello di un intervento serio.

L’alternativa che propongo quasi sempre: lo strangolamento progressivo

Nella maggior parte dei progetti di modernizzazione che seguo, l’approccio che funziona meglio è quello che in inglese si chiama strangler pattern: si costruisce il nuovo sistema a fianco del vecchio, modulo per modulo, reindirizzando gradualmente il traffico verso le parti nuove mano a mano che vengono completate e verificate. Il sistema vecchio continua a funzionare per le parti non ancora migrate, il rischio è distribuito nel tempo invece che concentrato in un unico rilascio “big bang”, e il business non si ferma mai durante la transizione. Vale per un gestionale interno quanto per un sito web o un e-commerce costruito anni fa su basi ormai fragili.

È un approccio meno spettacolare di un “rifacciamo tutto da zero”, richiede più disciplina architetturale in fase di pianificazione, e per questo viene scelto meno spesso di quanto dovrebbe. Ma nella mia esperienza è quasi sempre quello che, un anno dopo, il cliente è contento di aver scelto.