Modernizzazione software legacy: come farlo senza fermare la produzione

La definizione che nessuno ti ha mai dato

Un sistema legacy non è semplicemente software vecchio.

Un sistema del 2010 può essere legacy. Un sistema del 1990 potrebbe non esserlo.

La discriminante è una sola: puoi modificarlo con fiducia?

Se la risposta è no, hai un sistema legacy. Indipendentemente dall'anno di costruzione e dalla tecnologia usata.

Un sistema è legacy quando modificarlo richiede più paura che competenza.

Quando nessuno sa perché certe scelte architetturali siano state fatte.

Quando aggiungere una funzionalità semplice richiede settimane e lascia tutti con il fiato sospeso.

Quando il team usa frasi come "tocca quella parte e non sai cosa succede" o "non abbiamo ancora capito perché funziona così".

Quello è il segnale. Non l'anno di costruzione.

Le cinque caratteristiche tecniche che identificano il problema

Per essere precisi, un sistema è legacy quando presenta almeno tre di queste cinque caratteristiche.

• Zero test automatizzati: ogni modifica richiede test manuali estesi e lascia comunque margini di rischio. Nessuno sa con certezza se aggiungere una funzionalità rompe qualcosa altrove.
• Documentazione assente o obsoleta: le regole di business sono nel codice o, peggio, nella testa di una sola persona. Il documento che esiste è del 2009 e non è mai stato aggiornato.
• Tecnologie fuori supporto: .NET Framework 2.0, Visual Basic 6, Delphi, ASP.NET WebForms su versioni senza patch di sicurezza da anni.
• Accoppiamento estremo tra moduli: toccare il modulo ordini rompe qualcosa nella gestione magazzino, apparentemente senza correlazione. Il codice è una rete di dipendenze non documentate.
• Dipendenza da una singola persona: una sola figura sa davvero come funziona il sistema. Tutti gli altri sanno usarlo ma non capirlo. Quando quella persona è assente, tutto si ferma.

Se riconosci tre o più di questi segnali, stai leggendo l'articolo giusto.

Il paradosso che blocca le aziende: "ma funziona"

Questo è il punto più sottile e più importante.

Il paradosso del sistema legacy funzionante è questo: più funziona, meno lo vuoi toccare.

Meno lo tocchi, meno chi arriva dopo sa come funziona.

Meno qualcuno sa come funziona, più dipendi dalla persona che lo conosce.

È un circolo che si stringe. Sempre più stretto. Fino a quando si rompe qualcosa, o la persona chiave lascia l'azienda, o un'integrazione diventa urgente e impossibile.

Ho visto questo scenario in aziende piccole con venti dipendenti e in aziende con ottocento.

Il meccanismo è identico. Cambia solo la scala del danno quando si manifesta.

Il fatto che il sistema funzioni non è una garanzia. È una dilazione del problema, con interessi.

Perché le PMI manifatturiere italiane sono particolarmente esposte

Negli anni Novanta e Duemila molte aziende italiane hanno costruito software su misura che funzionava perfettamente per le esigenze di quel momento.

Gestionali, MRP, sistemi di controllo produzione: scritti in Visual Basic 6, Access, Delphi o le prime versioni di ASP.NET WebForms.

Nessuno li ha mai sostituiti perché funzionavano. Oggi quei sistemi reggono il cuore del business ma sono anche il rischio tecnologico più grande dell'azienda.

Il problema non è che il software sia lento o brutto. Il problema è che non puoi più controllarlo davvero.

Non puoi integrarlo con i nuovi sistemi ERP. Non puoi esportare i dati nel formato che chiede il cliente grande. Non puoi aggiungere il portale fornitori che stai progettando da tre anni.

Tra i sistemi legacy esempi più comuni nelle PMI italiane troviamo gestionali in VB6, applicativi di controllo qualità su Access, portali interni su ASP.NET WebForms e sistemi MES costruiti su misura vent'anni fa.

Se il tuo sistema gira ancora su Visual Basic 6, il corso di migrazione da VB6 a .NET è il primo passo tecnico concreto verso il pieno controllo del codice.

La matematica del debito tecnico che si accumula

Il debito tecnico cresce come un debito finanziario. Ma con una differenza cruciale: non appare in bilancio.

Nessuno registra le ore perse in test manuali. Nessuno contabilizza i giorni di sviluppo sprecati a decifrare codice non documentato.

Nessuno mette a preventivo il costo di un bug risolto che ne genera altri tre in moduli apparentemente non correlati.

Eppure quei costi esistono. E crescono ogni anno, anche senza fare nulla.

Ho analizzato i costi di manutenzione di un sistema legacy in un'azienda del settore ceramico di Modena.

La stima per aggiungere un report di produzione: quindici giorni di sviluppo. In un sistema moderno progettato bene: due giorni.

Tredici giorni di differenza per ogni singola funzionalità. Moltiplicato per tutte le modifiche che fai ogni anno.

In quell'azienda, il costo nascosto del sistema legacy era di circa centoventi giorni di sviluppo all'anno. Ogni anno. Da anni.

La riduzione dei costi di manutenzione software è uno dei benefici più immediati e misurabili di qualsiasi intervento di modernizzazione.

Sicurezza: le vulnerabilità che nessuno sta correggendo

.NET Framework 4.x riceve ancora patch di sicurezza, ma versioni precedenti no.

Un sistema su .NET Framework 2.0 o .NET Framework 3.5 è esposto a vulnerabilità note pubblicamente da anni. Vulnerabilità con numero CVE pubblico che chiunque può consultare.

In un'azienda manifatturiera con il gestionale connesso alla rete aziendale, un'unica vulnerabilità non corretta è la porta d'ingresso per un attacco ransomware.

Non è un caso teorico. Ho lavorato con un'azienda del settore alimentare che ha subito un attacco proprio attraverso un componente legacy con una CVE aperta da tre anni.

La produzione si è fermata per quattro giorni. Il danno stimato: oltre trecentomila euro tra perdita di produzione, ripristino dei sistemi e gestione della crisi.

Non era una grande azienda. Era una PMI con ottanta dipendenti.

La cosa che mi ha colpito di più non era il danno economico. Era che tutti sapevano da mesi che quel componente era vulnerabile. Nessuno aveva deciso di intervenire perché "il sistema funzionava".

Il componente continuava a funzionare. Era la backdoor degli attaccanti che lavorava in silenzio.

GDPR e software legacy: una bomba a orologeria silenziosa

I sistemi legacy sono quasi sempre non conformi al GDPR. Non per negligenza: semplicemente, il regolamento è del 2018 e il software è del 2005.

Il problema non è intenzionale. Il problema è strutturale.

Un sistema costruito nel 2005 non è stato progettato per gestire il diritto all'oblio. Non sa esportare tutti i dati di un singolo interessato su richiesta. Non ha log di accesso ai dati personali.

I problemi tipici che trovo nei sistemi legacy nelle PMI italiane sono sempre gli stessi.

• Impossibilità di cancellare i dati di un cliente specifico senza toccare tabelle correlate in modi non documentati.
• Assenza di log di accesso ai dati personali: nessuno sa chi ha visto i dati di chi.
• Consenso al trattamento non tracciato digitalmente: esistono solo fogli firmati negli archivi fisici.
• Impossibilità di dimostrare la base giuridica del trattamento per ogni categoria di dato.
• Dati personali distribuiti in tabelle non normalizzate senza un indice che permetta di tracciarli tutti.

Il Garante per la protezione dei dati personali ha già irrogato sanzioni a PMI italiane per mancata adeguatezza tecnica dei sistemi. Non è un rischio futuro: è un rischio presente.

La modernizzazione risolve questi problemi in modo strutturale. Le correzioni temporanee su un sistema legacy non bastano: il problema è architetturale, non di codice.

Il costo crescente della manutenzione ordinaria

In un sistema ben progettato, aggiungere una funzionalità richiede ore.

In un sistema legacy con anni di modifiche stratificate senza metodo, la stessa funzionalità richiede settimane.

Ogni modifica richiede test automatizzati che in un sistema legacy non esistono. Quindi ogni modifica richiede test manuali estesi. E lascia comunque aree di rischio residuo.

Ogni bug risolto ne genera altri perché il codice è accoppiato in modi non documentati. Risolvi il problema nella gestione ordini. Due giorni dopo trovi un comportamento anomalo nella fatturazione.

Questo non è un problema di competenza del team. È un problema strutturale del sistema.

Un team bravo in un sistema legacy produce meno di un team mediocre in un sistema moderno. Non è colpa loro.

Con ogni anno che passa, la curva di produttività del team sul sistema legacy scende. Il costo per sviluppatore aumenta. I tempi di consegna si allungano.

I migliori sviluppatori se ne vanno. Non vogliono lavorare su codice che non hanno scritto, che non capiscono e che non possono migliorare.

Il rischio della persona chiave: il vero debito umano

In molte PMI italiane c'è una sola persona che sa come funziona davvero il sistema legacy.

Spesso è il responsabile IT che lo ha costruito. Spesso si avvicina alla pensione. Spesso è anche l'unico che sa gestire il server fisico su cui gira.

Quando quella persona lascia l'azienda, porta con sé anni di conoscenza che non è scritta da nessuna parte.

Non è una conoscenza documentabile semplicemente. Non è solo come funziona il codice. È perché certe scelte sono state fatte. Quali eccezioni vengono gestite in quel modo. Cosa succede se si tocca quel parametro.

Ho visto aziende spendere mesi in sessioni di "trasferimento di conoscenza" con la persona chiave in uscita.

L'esercizio produce documenti. Non trasferisce davvero la conoscenza. Perché molta della conoscenza su un sistema legacy non è verbalizzabile: è tattile. La sai perché hai toccato il sistema migliaia di volte.

L'integrazione impossibile che ti taglia fuori dal mercato

Il mercato si muove. I clienti grandi chiedono integrazioni EDI per la gestione ordini. Il tuo fornitore principale vuole un portale online. La banca propone un collegamento diretto per la riconciliazione bancaria.

In un sistema moderno, costruire un'integrazione richiede settimane. In un sistema legacy, richiede mesi. Spesso è impossibile senza intervenire nel cuore del codice.

Il risultato è che costruisci soluzioni alternative: file Excel condivisi, copie manuali di dati tra sistemi, export notturni scritti da terzi che nessuno capisce più.

Ogni soluzione alternativa è un nuovo punto di rischio. Un nuovo posto dove i dati possono divergere. Un nuovo processo che dipende da qualcuno che sa come si fa.

Ho analizzato sistemi dove il flusso di dati tra gestionale e sistema di spedizione passava per tre file Excel intermedi, due macro VBA scritte dieci anni fa e un job notturno che nessuno sapeva più dove girasse esattamente.

Ogni volta che qualcosa andava storto in quella catena, trovare il problema richiedeva ore. Spesso giorni.

"Abbiamo delle persone che conoscono il sistema"

Quante?

Se la risposta è due, la situazione è fragile. Se la risposta è una, hai già un problema serio.

Se quella persona è malata per una settimana, cosa succede? Se decide di lasciare l'azienda con due settimane di preavviso, cosa fate?

"Le abbiamo fatto fare un documento." Lo so. L'ho visto decine di volte. Quel documento descrive cosa fa il sistema, non come funziona davvero il codice.

La conoscenza di un sistema legacy non si trasferisce con un documento. Si trasferisce con mesi di lavoro fianco a fianco sul codice.

Se non hai quella continuità strutturata, la conoscenza se ne va quando se ne va la persona.

"Stiamo già lavorando alla migrazione da un po'"

Quanto è "un po'"?

Se è più di diciotto mesi senza un singolo modulo in produzione, il progetto è bloccato. Non in corso: bloccato.

Lo so perché l'ho visto molte volte. Il progetto di modernizzazione che "è in corso" da due o tre anni ma che non ha ancora prodotto nulla di concreto in produzione.

Le cause sono sempre le stesse: nessuna valutazione tecnica iniziale, approccio di riscrittura integrale mascherato da modernizzazione, team interno senza esperienza specifica su questo tipo di progetto.

Un progetto di modernizzazione fatto con il metodo giusto produce i primi risultati in produzione entro novanta giorni. Se non li stai vedendo, il problema non è la complessità del sistema: è il metodo.

"Facciamo delle modifiche periodiche per tenerlo aggiornato"

Questo è il più insidioso.

Le modifiche fatte su un sistema legacy senza un metodo strutturato non riducono il rischio. Lo aumentano.

Ogni modifica fatta senza test aggiunge un nuovo strato di codice non verificato sopra a strati già esistenti di codice non verificato.

La complessità cresce. L'accoppiamento aumenta. Il numero di "parti da non toccare" si espande.

Quando mi chiedono di analizzare sistemi "tenuti aggiornati" in questo modo, trovo invariabilmente la stessa cosa: la parte aggiunta più di recente è quella più fragile, perché chi l'ha scritta aveva paura di toccare quello che c'era già.

Il sistema è più grande di prima. Ma non è più controllabile di prima. Spesso lo è meno.

"La persona chiave va in pensione tra qualche anno"

"Tra qualche anno" non è un piano. È una speranza.

La modernizzazione di un sistema di medie dimensioni richiede dai sei ai diciotto mesi. A cui si aggiunge la fase di valutazione tecnica.

Se la persona chiave va in pensione tra due anni e inizi adesso la valutazione tecnica, sei già in ritardo.

Se aspetti altri sei mesi perché "prima dobbiamo chiudere il trimestre" o "prima finiamo questo progetto", sei in ritardo di un anno.

Il piano di successione tecnologica non si fa quando la persona è già in uscita. Si fa mentre è ancora in azienda e può partecipare attivamente alla trasmissione della conoscenza.

Ogni mese che aspetti è un mese di conoscenza che non documenti, non trasferisci, non metti in sicurezza.

"Non abbiamo il budget per una migrazione completa"

Capisco. Il budget è sempre un vincolo reale.

Ma il confronto giusto non è tra il costo della modernizzazione e il costo zero di non fare nulla.

Il confronto giusto è tra il costo della modernizzazione e il costo cumulativo di quello che stai già pagando ogni anno.

Costo della manutenzione crescente. Costo delle opportunità perse per integrazioni impossibili. Costo del rischio di sicurezza. Costo del rischio GDPR. Costo del rischio operativo se la persona chiave lascia l'azienda improvvisamente.

Nella maggior parte dei casi in cui ho fatto questo calcolo con le aziende, il costo cumulativo del non fare nulla supera il costo della modernizzazione già al secondo o terzo anno.

Non stai risparmiando. Stai spostando il costo nel futuro, dove sarà più alto.

Perché la riscrittura integrale fallisce quasi sempre

La riscrittura integrale è l'approccio intuitivo. Il sistema vecchio fa schifo, lo buttiamo via e riscriviamo tutto da zero.

L'idea sembra logica. I dati dicono altro: fallisce nel 60-70% dei casi.

Non per mancanza di competenza tecnica del team. Ma per un motivo preciso: nel vecchio sistema ci sono anni di regole di business che nessuno ha mai documentato.

Quelle regole sono nel codice. Alcune sono bug che nel tempo sono diventati comportamenti attesi dai reparti. Alcune sono eccezioni non standard gestite in modi che nessuno ha mai messo per iscritto.

Quando riscrivi da zero, perdi quelle regole. Non sai nemmeno di averle perse.

Lo scopri quando il nuovo sistema è in produzione e qualcosa smette di funzionare. Oppure quando il responsabile di magazzino ti dice che "prima era diverso" e tu non sai perché fosse diverso.

Fermi la produzione per diciotto mesi. Riscrivi tutto. Scopri che metà delle regole operative erano nascoste nel codice. La linea si ferma. L'investimento va perso.

Ho visto questo scenario tre volte nella mia carriera. Tre aziende che hanno perso anni di lavoro e budget considerevoli. In un caso, l'azienda ha finito per tornare al sistema vecchio dopo aver speso sei mesi sulla riscrittura.

Il pattern Strangler Fig: il metodo che funziona davvero

Martin Fowler ha descritto un approccio con il nome di Strangler Fig Pattern.

Il nome viene da un fico selvatico che cresce attorno a un albero ospite. Il fico non abbatte l'albero. Cresce attorno a lui, lentamente, finché non lo avvolge completamente. Poi l'albero originale muore per cause naturali, ma la struttura del fico è già lì, completamente formata.

Il principio applicato al software: non sostituisci il sistema legacy tutto in una volta.

Costruisci il sistema nuovo attorno a quello vecchio, modulo per modulo.

La produzione non si ferma mai. Il vecchio sistema continua a girare mentre il nuovo prende progressivamente il suo posto.

Il vecchio sistema e il nuovo coesistono per un periodo. Poi, quando sei certo che il nuovo modulo si comporta esattamente come il vecchio (incluse le eccezioni), disattivi quello vecchio.

Ripeti per ogni modulo. Lentamente, senza mai fermare nulla, il sistema vecchio viene avvolto e sostituito.

I cinque passi operativi per applicarlo

In pratica, il metodo si applica così, un modulo alla volta.

1. Identifica il modulo da modernizzare per primo: non il più critico, non il più grande. Quello meno critico e più isolato. Il successo del primo modulo costruisce la fiducia e il metodo per quelli successivi.
2. Scrivi i test di verifica comportamentale: prima di toccare una sola riga di codice nuovo, cattura il comportamento esatto del modulo vecchio con test automatici. Questi test sono il contratto di equivalenza che il nuovo modulo dovrà rispettare.
3. Costruisci il modulo nuovo sulla nuova piattaforma tecnologica: lo costruisci in parallelo, senza fermare quello vecchio. Il vecchio continua a girare normalmente.
4. Esercizio parallelo e validazione: il nuovo modulo gira affiancato al vecchio per un periodo definito. I risultati vengono confrontati. Se c'è una divergenza, si analizza e si corregge.
5. Smetti di usare il vecchio modulo e decommissionalo: solo quando il comportamento è certificato come equivalente sposti il traffico reale sul nuovo. Poi il vecchio modulo viene dismesso. Si ripete con il modulo successivo nella lista.

Questo approccio richiede più disciplina rispetto alla riscrittura integrale. Non richiede più tempo: richiede un diverso tipo di lavoro.

La produzione non si ferma mai. Il rischio è distribuito nel tempo, non concentrato in un singolo rilascio catastrofico.

I test di verifica comportamentale: il pilastro invisibile della modernizzazione

Questo è il punto che quasi nessuno capisce fino a quando non lo vive in prima persona.

Prima di costruire il sistema nuovo, devi capire esattamente come si comporta quello vecchio.

Non come dovrebbe comportarsi secondo la documentazione del 2009. Come si comporta davvero, oggi, inclusi i bug che nel tempo sono diventati comportamenti attesi.

Lo fai scrivendo test che catturano il comportamento attuale del sistema. Si chiamano test di verifica comportamentale.

Ogni volta che il vecchio sistema elabora una fattura, gestisce un ordine o calcola una distinta base, il test registra l'input e l'output.

Questi test diventano il contratto che il nuovo sistema dovrà rispettare. Se il nuovo sistema si comporta diversamente, i test te lo dicono prima che qualcuno in produzione lo scopra.

Ho lavorato con un'azienda dove un bug nella gestione degli arrotondamenti IVA su fatture con articoli a peso variabile era diventato, nel corso di anni, il comportamento atteso dal commerciale.

I clienti si aspettavano quel calcolo specifico. Il commerciale ne teneva conto nei preventivi. Nessuno lo aveva mai documentato perché "così ha sempre funzionato".

Il test di verifica comportamentale lo ha catturato automaticamente. Lo abbiamo replicato nel sistema nuovo, documentato e convertito in una funzionalità esplicita.

Senza quel test, avremmo riscritto "correttamente" e rotto qualcosa di critico per il business senza saperlo.

Come si sceglie l'ordine dei moduli da modernizzare

La scelta dell'ordine non è casuale. Segue criteri precisi che bilanciano rischio e valore.

Ci sono due criteri principali che uso per costruire la lista di priorità.

Il primo criterio è il rischio tecnico: quale modulo genera il maggior numero di bug, richiede il maggior numero di interventi urgenti, dipende dalla tecnologia più obsoleta con vulnerabilità aperte.

Il secondo criterio è il valore operativo: quale modulo, se modernizzato, sblocca le integrazioni che stai aspettando, riduce il carico manuale sui reparti o abilita processi che oggi non puoi fare.

L'ordine ottimale bilancia i due: si inizia con qualcosa di moderato in entrambi, per acquisire metodo e fiducia, poi si procede con i moduli più critici.

Non si inizia mai con il modulo più critico per l'operatività. Non in un primo progetto. Non senza aver collaudato il metodo su qualcosa di meno rischioso.

Perché tutti saltano la valutazione tecnica e cosa succede

La pressione a saltare la valutazione tecnica viene sempre dall'alto.

"Non abbiamo tempo per analisi. Dobbiamo fare." "L'analisi la facciamo mentre lavoriamo." "Conosciamo già il sistema abbastanza bene."

Ho sentito queste frasi decine di volte. E in ogni caso in cui il team le ha seguite, il progetto è poi finito in difficoltà.

Cosa succede quando salti la valutazione tecnica?

Inizi a costruire il sistema nuovo basandoti su quello che pensi di sapere del vecchio. A metà progetto scopri che il vecchio sistema ha una logica di calcolo in un modulo secondario che non hai incluso nelle specifiche.

Quel modulo secondario influenza tre altri moduli che hai già costruito. Devi tornare indietro. Settimane di lavoro da rifare.

Tre settimane di valutazione tecnica all'inizio evitano mesi di rifacimento a progetto avanzato.

Cosa mappa una valutazione tecnica e cosa produce

La valutazione tecnica non è una riunione con Post-it. È un lavoro tecnico strutturato che produce un documento preciso.

La valutazione risponde a queste domande concrete.

• Quanti moduli ha il sistema e come dipendono l'uno dall'altro? Dove sono i confini naturali tra moduli?
• Quali moduli sono critici per l'operatività e quali sono secondari o sostituibili?
• Dove si concentrano i bug più frequenti e le richieste di modifica più costose?
• Quali regole operative sono nel codice ma non nella documentazione? Dove si nasconde la logica di business non scritta?
• Con quali sistemi esterni il software si integra e in che modo? Quali di queste integrazioni sono documentate e quali sono soluzioni alternative non formali?
• Qual è lo stato del codice: complessità ciclomatica, dipendenze circolari, aree con zero test?
• Quali tecnologie sono fuori supporto e con quali vulnerabilità note?

L'output della valutazione è una mappa del sistema: moduli, dipendenze, rischi e una lista ordinata degli interventi.

Con quella mappa, il progetto di modernizzazione parte su basi solide. Senza quella mappa, parte su ipotesi.

Gli strumenti tecnici per una valutazione seria

Una valutazione tecnica professionale usa strumenti specifici, non solo interviste.

• Analisi statica del codice: strumenti come SonarQube o NDepend mappano la complessità ciclomatica, le dipendenze tra classi e i moduli con più problemi strutturali.
• Mappatura delle dipendenze: un grafo visivo delle dipendenze tra moduli e librerie esterne rivela accoppiamenti nascosti che nessuno aveva mai reso espliciti.
• Inventario delle integrazioni: lista completa di tutti i sistemi esterni con cui il software comunica, incluse le integrazioni informali via file o database condivisi.
• Sessioni di knowledge transfer strutturate: non interviste libere. Sessioni in cui la persona chiave lavora sul codice mentre un tecnico esperto prende nota delle decisioni implicite.
• Test di carico sui moduli critici: si eseguono test per capire dove il sistema ha problemi di performance sotto carico, prima di migrare quei moduli.

Questa fase richiede in media trenta giorni per un sistema di medie dimensioni. Non è tempo perso: è tempo investito per non perdere il triplo dopo.

I novanta giorni dall'analisi al primo modulo in produzione

Il primo obiettivo concreto di qualsiasi progetto di modernizzazione è avere qualcosa di reale in produzione entro novanta giorni.

Non una demo. Non un prototipo che "funzionerà quando sarà completo". Qualcosa di reale che processa transazioni reali con dati reali.

1. Giorni 1-30: valutazione tecnica completa. Mappa di tutti i moduli, dipendenze, integrazioni e punti critici. Identificazione del primo modulo da modernizzare.
2. Giorni 31-60: costruzione del modulo e dei test di verifica comportamentale. Il modulo nuovo viene costruito in parallelo. I test vengono scritti sia sul vecchio che sul nuovo per confronto continuo.
3. Giorni 61-90: esercizio parallelo e validazione in ambiente di pre-produzione con dati reali. Il nuovo modulo gira affiancato al vecchio. Si confrontano i risultati. Si correggono le divergenze.

Alla fine dei novanta giorni hai tre cose concrete: la mappa esatta del sistema, un modulo modernizzato funzionante in produzione e la certezza tecnica che il metodo funziona per il tuo sistema specifico.

È il momento in cui smetti di agire per paura e inizi ad agire per metodo.

Perché migrare direttamente alla versione più recente e non fermarsi a metà strada

Molti responsabili IT chiedono: perché non fare una migrazione intermedia?

La risposta è questa: ogni migrazione ha un costo. Pagarlo due volte non ha senso.

Se oggi migri a una versione intermedia, tra due anni ti trovi di nuovo con un sistema su una versione non supportata. Il ciclo ricomincia: test da aggiornare, dipendenze da verificare, documentazione da rifare.

La migrazione giusta è quella che ti porta dove vuoi stare tra cinque anni, non tra due.

Una volta sola. Fatta bene. Con il team formato per mantenere il sistema senza dipendere da nessuno.

Le tecnologie che richiedono vera riscrittura

Non tutto si migra allo stesso modo. Alcune tecnologie di .NET Framework non hanno equivalente diretto in .NET 10 e richiedono una riscrittura vera e propria.

• ASP.NET WebForms: non ha equivalente in .NET 10. Deve essere riscritto in ASP.NET Core MVC o Blazor. Il pattern Strangler Fig applicato a livello di singola pagina è il metodo più efficace.
• Windows Communication Foundation (WCF): non esiste in .NET 10. Si sostituisce con CoreWCF per compatibilità parziale, o con gRPC per servizi interni, o con API REST per integrazioni esterne.
• Entity Framework 6: si migra a Entity Framework Core. Le API sono simili ma non identiche. Alcune query LINQ devono essere riscritte perché le traduzioni SQL sono diverse.
• Web.config: sostituito da appsettings.json con Dependency Injection nativa. La configurazione per ambienti multipli (sviluppo, pre-produzione, produzione) diventa più semplice e leggibile.
• COM Interop: il caso più complesso. I componenti COM possono essere avvolti in un servizio .NET Framework separato che espone un'API REST. Il resto dell'applicazione migra a .NET 10 comunicando con quel servizio di transizione.

Per il codice di accesso ai dati, il corso Entity Framework copre la migrazione da Entity Framework 6 a Entity Framework Core in modo progressivo.

Per le interfacce web, il corso Blazor è il percorso più diretto per chi deve abbandonare ASP.NET WebForms.

Il capitolo dei test nella migrazione: dove quasi tutti si sbagliano

In un sistema legacy senza test automatizzati, prima di migrare devi scrivere i test di verifica comportamentale.

Questi test catturano il comportamento attuale del sistema, inclusi i bug che nel tempo sono diventati funzionalità attese.

È la fase che quasi tutti sottostimano o ignorano completamente.

Chi ignora questa fase si trova con un sistema migrato che si comporta in modo leggermente diverso dall'originale. Lo scopre quando la linea produttiva è già in esercizio.

La differenza di comportamento non è sempre un bug tecnico. È spesso una regola di business implicita che il vecchio sistema implementava in un modo particolare.

Questa fase richiede in media il quaranta percento del lavoro complessivo del progetto di migrazione. Chi non la prevede nel piano si trova a fare straordinari nelle settimane dopo il go-live.

Tempi realistici per la migrazione per dimensione del sistema

Le stime che do qui sono basate su progetti reali. Non su teorie.

Queste stime includono la fase di valutazione tecnica e la scrittura dei test di verifica comportamentale. Non sono stime di "solo sviluppo".

Il confronto corretto non è tra il costo della migrazione e il costo zero. È tra il costo della migrazione e il costo cumulativo di manutenzione crescente, vulnerabilità di sicurezza, rischio GDPR e dipendenza dalla persona chiave.

Per approfondire le architetture software adatte ai sistemi aziendali moderni dopo la migrazione, ho descritto i modelli più efficaci nel contesto manifatturiero.

Vale anche la pena capire perché il software va trattato come un patrimonio aziendale: il valore non è solo nel codice, è nelle regole operative che quel codice contiene.

Errore 1: iniziare senza valutazione tecnica

"Conosciamo già il sistema." "L'analisi la facciamo mentre costruiamo." "Non possiamo permetterci sei settimane di analisi prima di iniziare."

Ogni volta che sento una di queste frasi, so già come finirà il progetto.

Il progetto parte veloce. Nei primi tre mesi sembra andare bene. Al quinto mese emerge la prima dipendenza non mappata. Al sesto inizia il rifacimento. Al nono il progetto è fermo.

Non è una previsione. È un pattern che si ripete con matematica precisione.

La valutazione tecnica non è un lusso. È l'investimento con il ritorno più alto dell'intero progetto.

Trenta giorni di analisi all'inizio risparmiano sei mesi di rifacimento nel mezzo.

Errore 2: migrare senza test di verifica comportamentale

Questo errore si manifesta sempre nello stesso modo: il sistema migrato va in produzione, tutto sembra funzionare, poi dopo due settimane iniziano le segnalazioni.

"Il calcolo della distinta base è diverso da prima." "Le bolle di uscita hanno un totale leggermente diverso." "Il report mensile non torna con quello che avevamo prima."

Non sono bug tecnici. Sono comportamenti impliciti del sistema vecchio che il sistema nuovo non ha replicato perché nessuno li aveva documentati.

Senza test di verifica comportamentale, non hai un contratto di equivalenza. Non sai se il sistema nuovo si comporta come quello vecchio. Lo scopri in produzione.

Scoprirlo in produzione costa dieci volte di più che scoprirlo durante la fase di validazione parallela.

Errore 3: affidare la migrazione solo al team interno senza affiancamento

Il team interno conosce il business. Conosce i processi. Conosce le eccezioni che nessuno ha mai scritto da nessuna parte.

Quello che spesso non conosce è come si gestisce una migrazione di questa portata. Non per mancanza di competenza tecnica. Per mancanza di esperienza specifica su questo tipo di progetto.

Migrare un sistema legacy in produzione senza fermare il business è un problema diverso rispetto a costruire un sistema nuovo da zero.

Le insidie sono diverse. Le tecniche sono diverse. I punti di rischio sono diversi.

Un team che affronta questo tipo di progetto per la prima volta paga una curva di apprendimento. Quella curva di apprendimento si misura in mesi e in errori costosi.

La soluzione non è sostituire il team interno con consulenti esterni. È affiancare il team interno con chi ha già navigato quelle acque.

L'affiancamento trasferisce competenza. Alla fine del progetto il team sa fare da solo. Non ci sono dipendenze dai consulenti.

Errore 4: la riscrittura camuffata da modernizzazione incrementale

Questo è l'errore più sottile e il più difficile da riconoscere dall'interno.

Il progetto nasce con le intenzioni giuste: modernizzazione incrementale, un modulo alla volta.

Ma poi succede qualcosa. Si inizia a "ottimizzare" il primo modulo. Poi si decide di riscrivere anche la struttura dati. Poi si aggiunge un'interfaccia completamente nuova.

Dopo sei mesi ci si ritrova a riscrivere tutto da zero, ma con il nome del "modulo prioritario" ancora in cima al documento di progetto.

Il segnale di allarme è questo: se dopo tre mesi di progetto non hai ancora nulla in produzione, non stai facendo modernizzazione incrementale.

Il metodo incrementale produce risultati in produzione entro novanta giorni. Sempre.

Se non è così, fermati. Rivedi il metodo. Non aspettare altri sei mesi sperando che la situazione cambi.

Errore 5: non formare il team sul sistema nuovo durante la migrazione

La migrazione tecnologica è anche una migrazione di competenze.

Se il team ha lavorato per anni su .NET Framework e WebForms, non può passare immediatamente a .NET 10, ASP.NET Core MVC ed Entity Framework Core senza un percorso strutturato.

La tentazione è di fare la migrazione velocemente e formare il team dopo. Questo è un errore.

Il team che non capisce il sistema nuovo non sa manutenerlo dopo la migrazione. Torna a dipendere da consulenti esterni. Oppure introduce nel sistema nuovo gli stessi problemi che aveva il sistema vecchio.

La formazione deve avvenire in parallelo alla migrazione, non dopo. Il team deve imparare mentre costruisce, con affiancamento su casi reali.

È l'unico modo per garantire che alla fine del progetto tu abbia sia un sistema moderno che un team in grado di mantenerlo autonomamente.

La curva di apprendimento che paghi in ritardi e errori

Ogni progetto di migrazione ha le sue insidie specifiche. Ma le insidie comuni sono sempre le stesse.

Chi le ha già incontrate su altri progetti le riconosce subito e le gestisce prima che diventino problemi.

Chi le incontra per la prima volta le riconosce solo dopo che hanno già causato danni: settimane perse, moduli da rifare, dati da riconciliare.

Ho calcolato, analizzando tre progetti di migrazione fatti internamente senza affiancamento, che la curva di apprendimento ha allungato i progetti del sessanta percento rispetto alle stime iniziali.

Non erano team incompetenti. Erano team competenti che affrontavano per la prima volta un tipo specifico di problema.

La differenza non è la competenza: è l'esperienza specifica.

Chi sono e cosa ho già fatto

Lavoro su sistemi .NET reali da venticinque anni, dalle prime versioni del framework fino a .NET 10.

Ho fondato e ceduto più software house, tra cui LegalDesk, ceduta a SEAC SpA dopo anni di sviluppo su sistemi di grandi dimensioni in produzione.

Ho lavorato con NATO, con FIAT e con GlaxoSmithKline. So cosa significa costruire e modernizzare sistemi che non possono permettersi di fermarsi.

Oggi affianco aziende manifatturiere italiane con team di sviluppo interni. Non sostituisco il team: lo guido mentre modernizza il proprio sistema.

In un progetto con un'azienda manifatturiera del Veneto abbiamo modernizzato un sistema da 180.000 righe di codice in diciotto mesi senza un singolo giorno di fermo produzione.

Il segreto non era la tecnologia. Era la disciplina nel seguire il metodo e l'esperienza nel riconoscere i problemi prima che si manifestassero.

Cosa porta concretamente un consulente esperto nel tuo progetto

Il valore che porto non è la tecnologia nuova: è non perdere dati, non fermare la produzione e non sprecare budget in una riscrittura abbandonata a metà.

• Valutazione tecnica completa in trenta giorni invece di novanta: so esattamente dove guardare e cosa cercare. Non parto da zero su ogni sistema.
• Piano d'intervento basato sul rischio reale, non su ipotesi teoriche. La lista dei moduli ordinata per priorità tiene conto sia del rischio tecnico che del valore operativo per il tuo business specifico.
• Affiancamento del team interno: non lavoro in isolamento. Lavoro con il tuo team, trasferendo il metodo. Alla fine del progetto il team sa gestire e mantenere il sistema nuovo senza dipendere da consulenti.
• Riconoscimento precoce delle insidie: ho già visto le trappole più comuni. Le riconosco prima che diventino problemi. Questo risparmia settimane di rifacimento.
• Zero fermo produzione: non è una promessa di marketing. È un metodo con venticinque anni di prove sul campo e un record che posso documentare.

La domanda giusta da porsi prima di decidere

La domanda giusta non è "quanto costa affidarsi a un consulente esperto?".

È "quanto costa sbagliare la migrazione da soli?"

Un progetto di migrazione fallito non significa solo soldi persi. Significa mesi di lavoro del team buttati. Significa il vecchio sistema ancora in produzione, con tutti i suoi rischi, dopo un anno di lavoro.

Significa tornare al punto di partenza con meno budget e un team demotivato.

Il costo dell'errore in questo tipo di progetto è alto. Il costo di fare le cose bene dall'inizio è molto più contenuto.

Chi chiama una volta chiama di nuovo. Non perché il contratto lo vincoli, ma perché il metodo funziona e i risultati sono misurabili.