Le 5 trappole più frequenti nelle migrazioni di sistemi legacy

Le migrazioni di sistemi legacy sono progetti tecnici, finanziari e organizzativi insieme. Falliscono raramente per ragioni puramente tecniche (la tecnologia di destinazione esiste, gli sviluppatori capaci si trovano). Falliscono per cinque pattern di errore organizzativo-decisionale che si ripetono con costanza inquietante: sottostima del domain knowledge nascosto nel codice, dati legacy sporchi non puliti per tempo, big-bang senza fallback, rigetto degli utenti finali, fornitori non specializzati. Vediamoli uno per uno con il dovuto livello di dettaglio, perché conoscerli prima vale 50-150k euro di errori non commessi.

TL;DR

• Trappola 1: il domain knowledge nel codice legacy è sempre 3-5 volte maggiore di quello documentato. Stimare per linee di codice è sbagliato; va stimato per regole business da disambiguare.
• Trappola 2: i dati storici legacy sono sempre sporchi (duplicati, codifiche miste, vuoti significativi). Migrarli “così come sono” propaga i problemi nel nuovo sistema. Data cleansing va fatto prima della migrazione, non dopo.
• Trappola 3: spegnere il vecchio sistema il giorno del go-live senza fallback documentato e testato è la singola decisione più rischiosa. Il parallel running per 4-12 settimane è quasi sempre più economico del recovery dopo un go-live fallito.
• Trappola 4: il rigetto degli utenti finali affossa migrazioni tecnicamente perfette. Senza change management serio (40-80 ore di training per power user, champion users dal mese 4) il software nuovo viene aggirato con Excel paralleli.
• Trappola 5: i fornitori che vendono il “pacchetto modernizzazione” standard senza adattamento al vostro contesto sono il singolo predittore di fallimento più affidabile.

Perché queste trappole esistono ancora nel 2026

Non sono trappole sconosciute. Sono documentate in letteratura tecnica e post-mortem di progetti pubblici da almeno 15 anni. Eppure si ripetono con tasso costante. Tre ragioni strutturali:

Primo, la rotazione del personale tecnico. I responsabili IT che hanno vissuto il fallimento del 2008-2012 sono spesso in pensione o cambiati ruolo. Le nuove generazioni di CIO incontrano gli stessi problemi per la prima volta, senza accesso alla memoria istituzionale del proprio settore.

Secondo, l’asimmetria informativa fornitore-cliente. Le software house che vivono di migrazioni hanno interesse a sottostimare le complessità per chiudere il contratto. Il cliente che non ha mai fatto una migrazione non sa cosa chiedere per smascherare la sottostima.

Terzo, la pressione del go-live. Quando il progetto si dilata, la pressione politica per “andare in produzione comunque” spinge a saltare proprio i passaggi (testing dati, parallel running, training utenti) che proteggono dalle trappole. Si paga dopo.

Le organizzazioni che evitano queste trappole non lo fanno per fortuna: lo fanno perché qualcuno nel team ha vissuto il fallimento precedente o ne ha studiato i casi.

Trappola 1: sottostimare il domain knowledge nel codice

Cosa è

Il codice legacy contiene non solo logica esplicita (algoritmi), ma decisioni implicite: regole business contrattate verbalmente, eccezioni storiche, workaround per casi limite. Questa conoscenza implicita è il vero patrimonio del legacy e quello che bisogna recuperare con la migrazione.

Come si manifesta

Un esempio reale tipico: un codice RPG di vent’anni fa calcola la commissione agente come provvigione = valore_ordine * 0.05 per default, ma con tre eccezioni: per il cliente “MILANO-001” (storico, contratto verbale del 2003) la percentuale è 0.067; per i prodotti della categoria “FUORI-CATALOGO” è 0.03; per gli ordini del Sud Italia oltre i 5.000 euro c’è una maggiorazione del 0.01 (introdotta nel 2007 da un direttore commerciale poi licenziato, nessuno ricorda perché).

Queste regole non sono in nessun documento. Esistono nel codice come IF annidati con commenti spesso datati. Chi migra vede gli IF ma non capisce perché ci siano. Decide di non riportarli (rumore?), o li riporta letteralmente (preservando regole non più valide).

Perché si verifica

Tre cause principali. (1) Stima del progetto per linee di codice: 50.000 LOC × X euro/LOC = stima. Ignora che le 50.000 LOC contengono 800-1.500 regole business implicite. (2) Riluttanza a investire nel reverse-engineering serio: si dà al consulente “il codice” e si aspetta che produca il “nuovo codice”, senza budget per la fase di intervista degli stakeholder. (3) Stakeholder critici già fuori dall’azienda: chi conosceva le regole è in pensione, non disponibile, o costoso da reingaggiare.

Cosa fare per evitarla

Audit del codice prima del preventivo. Investire 3-6 settimane in un audit serio del codebase legacy con strumenti moderni (analisi statica, AI come copilota di lettura RPG/COBOL). Output: lista delle 200-500 regole business implicite identificate, ognuna con: descrizione, quando si attiva, decisione richiesta (preservare/rivedere/eliminare).

Stakeholder workshop. Per ogni regola identificata in audit, decidere con uno stakeholder competente (responsabile commerciale, fiscale, amministrativo) se è ancora valida, modificata o eliminabile. Tempo richiesto: 30-60 ore di workshop distribuite su 8-12 settimane.

Buffer 30% nella stima. Aggiungere al preventivo iniziale un contingency del 25-35% per scoperte di regole business implicite in fase di sviluppo. È quasi sempre necessario; meglio prevederlo.

AI come copilota di analisi. Usare un LLM moderno (Claude, GPT, Gemini in modalità code) per leggere blocchi di RPG/COBOL e produrre spiegazione + lista di assunzioni. Non è automazione, è acceleratore della comprensione umana. Riduce il tempo di reverse-engineering del 30-40% senza sostituire l’expert review.

Trappola 2: dati legacy sporchi non puliti per tempo

Cosa è

I dati storici dei sistemi legacy contengono errori, duplicati, codifiche obsolete, campi vuoti con significato implicito. Migrarli “as-is” nel nuovo sistema propaga i problemi, e in molti casi li peggiora perché il nuovo sistema ha constraint di consistenza più stretti che fanno emergere errori prima silenziosi.

Come si manifesta

Esempi tipici da sistemi italiani anni 2000:

• Anagrafica clienti con duplicati: stesso cliente registrato 3-5 volte con varianti (con/senza partita IVA, con maiuscole diverse, con indirizzi obsoleti vs aggiornati). Nel legacy convivono pacificamente. Nel nuovo sistema (con unique constraint su P.IVA) la migrazione fallisce o produce un’anagrafica “stranamente piccola”.
• Codifiche miste: codici prodotto che mescolano sistemi vecchi e nuovi (es. “100-AB” dal 1998 vs “PROD-2019-001” dal 2019), con tabelle di cross-reference tenute manualmente in Excel.
• Campi vuoti con significato: il campo “data ultima attività” vuoto significa “cliente attivo” in alcune anagrafiche storiche; significa “cliente mai contattato” in altre. Il nuovo sistema interpreta entrambi come null e perde l’informazione semantica.
• Date in formati incompatibili: alcune date come “DDMMYYYY”, altre come “YYMMDD”, altre come stringa libera (“Gennaio 2003”). Il nuovo sistema vuole timestamp ISO 8601.
• Encoding mistici: file di testo in UTF-8, alcuni in CP1252, alcuni in ISO-8859-1, con accenti italiani che diventano ? o à se interpretati male.

Perché si verifica

Tre cause. (1) Sottovalutazione del problema in fase preventivo (i preventivi dicono “data migration” come voce unica senza dettaglio). (2) Mancanza di un data engineer nel team di progetto (figura specifica, non un developer generico). (3) Rinvio della pulizia “a dopo il go-live” che diventa “mai”.

Cosa fare per evitarla

Pilot di migrazione dati nelle prime 4-6 settimane. Migrare un campione del 5-10% dei dati (le anagrafiche più attive, gli ordini degli ultimi 12 mesi) nel nuovo sistema in ambiente di test. Misurare: quanti record passano senza modifiche, quanti richiedono correzione manuale, quanti sono irrecuperabili. È la singola metrica che meglio predice il costo reale della data migration.

Data quality assessment come deliverable formale. Output di 15-30 pagine: inventario tabelle, conteggio anomalie per tipo, stima del lavoro di cleansing per tipo, decisioni su cosa scartare/correggere/migrare con caveat. Approvato da business owner prima di procedere.

Budget cleansing del 15-25% del progetto totale. Per migrazioni serie su dati storici di 10-50M di record, il data cleansing costa tipicamente il 15-25% del progetto totale. Sottostimarlo è la fonte numero uno di sforamento di budget.

Aspettative chiare su perdita di dati. Non tutti i dati storici sono recuperabili. Alcuni sono irrecuperabilmente sporchi (es. anagrafiche del 1998 con campi liberi non strutturati). Decidere consapevolmente cosa migrare, cosa scartare, cosa archiviare in long-term storage sola lettura.

Trappola 3: big-bang senza fallback

Cosa è

Big-bang = spegnimento del vecchio sistema il giorno in cui parte il nuovo. Senza fallback = senza un piano testato di ritorno al vecchio se il nuovo non regge.

Come si manifesta

Il pattern tragico ricorrente: domenica notte si fa il cut-over. Lunedì mattina il nuovo sistema gira ma con bug critici scoperti solo in produzione (es. la stampa fatture non funziona, le commesse non si chiudono, gli ordini si bloccano in stato indefinito). Le operazioni aziendali si fermano parzialmente. Si scopre che il piano di rollback al vecchio sistema “esiste come documento” ma non è mai stato testato. Quando si tenta di attuarlo, emergono incompatibilità (i dati sono stati nel frattempo migrati, alcuni record nuovi non hanno equivalente nel vecchio).

L’azienda si trova in un limbo: il vecchio sistema spento, il nuovo non operativo, il personale a casa. Si chiamano consulenti emergenza a 200-400 euro/ora. Si lavora notte e giorno per 3-7 giorni. Costi diretti dell’emergenza tipici: 50-200k euro. Costi indiretti (mancate vendite, contestazioni clienti, perdita fiducia interna): incommensurabili.

Perché si verifica

Quattro cause. (1) Pressione del go-live: la data è stata annunciata, gli stakeholder l’aspettano, “rimandare è imbarazzante”. (2) Sottovalutazione della differenza fra ambiente di test e produzione (il test ha visto i casi normali, non quelli edge). (3) Rifiuto di investire nel parallel running (costa il 15-25% del progetto, “non è necessario”). (4) Riluttanza a investire nella scrittura e test di un piano di rollback (sembra un’ammissione che il go-live possa fallire).

Cosa fare per evitarla

Parallel running di 4-12 settimane. Entrambi i sistemi attivi in parallelo, con i dati che si sincronizzano. Costoso (licenze doppie, doppio inserimento, riconciliazione) ma dà tempo di scoprire i problemi in produzione mantenendo l’operatività. Per business mission-critical è quasi sempre indispensabile.

Piano di rollback documentato e testato. Non basta scriverlo: va testato. Almeno una settimana prima del go-live, simulare un rollback in ambiente di test e cronometrare i tempi. Se il rollback richiede 8+ ore, non è un piano: è un’illusione di piano.

Strangler pattern dove possibile. Migrazione modulo per modulo invece che totale. Cut-over di modulo singolo è reversibile in poche ore se necessario; cut-over totale del sistema è irreversibile dopo poche ore.

Go-live in fascia operativa fredda. Mai durante picchi di business (chiusura mese, chiusura semestre, alta stagione). Sempre in fascia bassa (Ferragosto, settimana fra Natale e Capodanno, weekend lunghi). Dà respiro per gestire imprevisti senza pressione operativa.

Trappola 4: rigetto degli utenti finali

Cosa è

Anche il software nuovo tecnicamente perfetto non funziona se gli utenti finali (operatori, fatturisti, magazzinieri, addetti commerciali) lo rifiutano o lo aggirano. Si torna a Excel paralleli, file condivisi, processi fuori sistema.

Come si manifesta

Pattern tipico: si va in produzione con il nuovo sistema. Il personale lo usa per qualche settimana, lamentandosi che “il vecchio era più veloce”, “non trovo il pulsante per X”, “questo cambia tutto e non capiamo perché”. Lentamente, alcuni operatori senior iniziano a usare di nuovo il loro Excel personale del 2018 “perché funziona meglio per quello che faccio io”. Dopo 6 mesi, il 30% delle operazioni avviene fuori dal nuovo sistema. Dopo 12 mesi, l’azienda ha due sistemi paralleli: il nuovo ufficiale, lo storico de facto. I dati divergono. La direzione non capisce perché il KPI del nuovo sistema mostra cifre diverse dalla realtà operativa.

Perché si verifica

Quattro cause. (1) Training insufficiente: 4-8 ore vs le 40-80 necessarie per power user. (2) Mancata comunicazione del perché della migrazione: gli utenti percepiscono il cambiamento come imposto, non come miglioramento. (3) UI/UX del nuovo sistema oggettivamente peggiore in alcuni flow rispetto al legacy ottimizzato in 20 anni di iterazioni. (4) Assenza di champion users interni che diventino punti di riferimento positivi.

Cosa fare per evitarla

Training stratificato. Power user (5-10% del personale): 40-80 ore di training distribuito su 6-8 settimane. User standard (resto del personale): 8-16 ore di training mirato al loro flow specifico. Refresh trimestrale post-go-live per i primi 12 mesi.

Champion users dal mese 4-6 di progetto. Identificare 3-5 persone rispettate nei team operativi e coinvolgerle nello sviluppo come consulenti interni. Vedono il sistema crescere, fanno feedback, diventano ambasciatori naturali quando si va in produzione.

UX review fatta da utenti reali. Non bastano i requirement document approvati dal manager. I flow del nuovo sistema vanno provati da chi effettivamente li userà, in sessioni di 60-90 minuti con osservazione. Trovate sempre cose che i manager non avrebbero mai immaginato (es. il magazziniere che ha bisogno di vedere lo stato di un ordine senza dover fare login completo).

Comunicazione del perché, non solo del come. Gli utenti accettano il cambiamento se capiscono perché si sta facendo. Una serie di brevi all-hands meeting (15-20 minuti) spiega il contesto: pressione normativa, costi crescenti del legacy, scarsità di sviluppatori, opportunità di lavoro più moderno. Senza questo framing, il cambiamento è percepito come capriccio della direzione.

Trappola 5: fornitori non specializzati

Cosa è

La modernizzazione legacy è una specialità. Non tutti i bravi sviluppatori sanno fare migrazione. Affidarsi a un fornitore “generalista” che fa “un po’ di tutto” e ha venduto a voi il pacchetto modernizzazione è il singolo predittore di fallimento più affidabile.

Come si manifesta

Si firma con un fornitore noto, magari grosso, che ha un case study o due di “modernizzazione” sul sito. Si scopre dopo l’inizio che: (a) il team assegnato al progetto è junior, perché i senior sono su clienti più redditizi; (b) la metodologia è quella dei progetti green-field (sviluppo nuovo software, non migrazione), inadatta al contesto; (c) il project manager non ha mai gestito una migrazione legacy prima; (d) per ogni decisione tecnica importante serve l’escalation a un consulente esterno (al vostro costo) che ha l’esperienza specifica.

Il progetto si dilata. Il fornitore fa promesse per non perdere il contratto, ma le promesse non si mantengono. Si arriva al 60% del budget speso con il 30% del lavoro fatto. Da lì si va: a un partner change (costoso, perde tempo), oppure a far finire il progetto in modo subottimale per chiudere comunque.

Perché si verifica

Quattro cause. (1) Selezione fornitore basata su brand (logo conosciuto) invece che su case study specifici dello stesso tipo di migrazione. (2) Mancanza di domande tecniche al fornitore in fase di selezione: si chiede cosa fanno, non come. (3) Riluttanza a investire in due diligence tecnica del fornitore (controllare references, chiedere portafoglio specifico, intervistare il project lead prima della firma). (4) Bias verso fornitori grossi per ragioni di percezione di sicurezza (“sono grandi, non possono sbagliare”), anche se la track record specifica è debole.

Cosa fare per evitarla

Selezione fornitore con due diligence tecnica. Almeno 3 fornitori in short list. Per ciascuno: 3-5 case study di migrazioni simili alla vostra (tecnologia legacy + dimensione + settore), interviste con clienti precedenti (non solo testimonial del sito, ma chiamate dirette), incontro con il project lead proposto (non solo il sales).

Domande tecniche specifiche al fornitore:

• Come gestite la fase di reverse-engineering del codice RPG/COBOL?
• Quale è la vostra metodologia di data cleansing?
• Come pianificate il parallel running e il rollback plan?
• Quante migrazioni di questo tipo specifico avete completato negli ultimi 36 mesi?
• Chi sono le persone specifiche assegnate al nostro progetto? Posso parlarci?

Risposte vaghe o generiche = red flag.

Contratto con milestone e gate economici. Non forfait opaco. Suddividere il progetto in 4-6 milestone con deliverable specifici e gate economici (es. milestone 1 = 20%, milestone 2 = 25%, ecc.). Se una milestone non viene raggiunta, il pagamento si blocca finché non si trova soluzione.

Diritto di audit e di partner change. Il contratto deve prevedere il diritto del cliente di fare audit tecnico in qualunque momento (con consulente terzo a propria spesa) e di rescindere/cambiare fornitore se l’audit identifica problemi gravi. Senza queste clausole il cliente è ostaggio del fornitore.

Come strutturare un progetto per evitare le 5 trappole

Quattro principi operativi che, applicati insieme, riducono drasticamente il rischio di incappare nelle trappole sopra.

1. Assessment serio prima del preventivo. 4-8 settimane di assessment indipendente (anche da consulente terzo, non solo dal fornitore proposto) prima di firmare contratti pluriennali. Output: piano di migrazione documentato, stima costi a banda ±20%, lista rischi specifici.

2. Pilot prima di tutto-in-once. Migrare un modulo, una sede, una linea di prodotto prima di estendere a tutto. Validare l’approccio su scala ridotta. Iterare prima di scalare.

3. Governance settimanale. Steering committee settimanale con sponsor esecutivo, project manager, tech lead, business owner. Decisioni rapide. Escalation chiara. Niente attese mensili per decidere.

4. Buffer di rischio del 30%. Sul tempo, sul budget, sulle risorse. Le migrazioni hanno unknowns che emergono solo durante l’esecuzione. Un buffer del 30% è realistico; meno è ottimistico; di più è disorganizzato.

FAQ

È meglio fare tutto internamente o esternalizzare?

Quasi sempre esternalizzare la stesura tecnica della migrazione, perché richiede competenze specialistiche poco sostenibili come team permanente interno. Internamente vanno mantenuti: lo sponsor esecutivo, 1-2 referenti tecnici interni (conoscitori del legacy), il business owner per ogni dominio, il responsabile change management. Mix interno/esterno sani: 30% interno + 70% esterno tipico.

Quanto deve durare l’assessment iniziale?

Per migrazioni di sistemi medi (5-20M di valore di business gestito), tipicamente 4-8 settimane. Sotto è superficiale, sopra è inefficiente. L’assessment include: audit codice, audit dati, interviste stakeholder, definizione strategia, stima costi e tempi.

Come si misura se la migrazione sta andando bene durante l’esecuzione?

Cinque KPI chiave: (1) milestone completion rate (sono ai gate previsti o in ritardo?), (2) defect density in test (sotto controllo o in crescita?), (3) data migration success rate sui pilot (sopra il 95%?), (4) user training coverage (siamo al passo con la roadmap?), (5) budget burn rate vs progress reale.

Quando si decide di fermare un progetto in difficoltà?

Quando emergono due segnali insieme: (a) il budget burn rate eccede del 30%+ il progress rate reale, (b) il fornitore non riesce a produrre un piano credibile di recupero entro 30-60 giorni. Continuare un progetto su un binario sbagliato è il modo più caro di concluderlo.

Le migrazioni AI-assisted riducono queste trappole?

Marginalmente, e solo per la trappola 1 (domain knowledge). L’AI accelera la lettura del codice legacy del 30-40%, ma le altre quattro trappole sono organizzative-decisionali e non vengono affrontate dall’AI. Anzi: aziende che si fanno convincere che “l’AI risolve la migrazione” spesso saltano i passaggi di change management (trappola 4) e due diligence fornitori (trappola 5), e finiscono in trappole peggiori.

Si può prevenire ogni trappola con un buon contratto?

No. Il contratto è uno strumento, non una soluzione. Le migrazioni che funzionano hanno contratti solidi più una governance operativa attiva più un team interno competente più un fornitore specializzato. Solo il contratto è condizione necessaria ma non sufficiente.

Conclusione

Le cinque trappole delle migrazioni legacy non sono inevitabili. Sono prevedibili, conosciute, e si evitano con scelte specifiche prese prima dell’inizio del progetto: audit serio, data cleansing anticipato, parallel running pianificato, change management strutturato, fornitore selezionato per track record specifico. Le aziende che fanno bene questi cinque pezzi spendono il 20-30% in più nelle prime fasi e risparmiano il 40-80% sulla curva totale del progetto.

Se state pianificando una migrazione legacy e volete confrontarvi sui rischi specifici del vostro caso, parliamone. Possiamo fare un assessment di rischio strutturale prima ancora di entrare nello scope tecnico.

Per approfondire: la pagina pilastro modernizzazione legacy, gli articoli correlati guida alla migrazione AS/400 per il quadro strategico complessivo, e quanto costa modernizzare un ERP custom degli anni 2000 per il taglio economico.