Quanto ti costa davvero il software legacy: i costi nascosti che nessuno calcola e come costruire il business case per la modernizzazione

Il costo del software legacy si decide in una riunione di venti minuti, e quasi sempre su numeri sbagliati.

Il direttore finanziario di un'azienda manifatturiera lombarda chiede al CTO quanto costa l'IT l'anno prossimo.

Risposta: "il gestionale che usiamo dal 2005 ci costa 200.000 euro l'anno di manutenzione".

Il CFO annota, confronta con i 400.000 euro stimati per un sistema nuovo, e chiude: "meglio tenere quello che abbiamo, è già ammortizzato".

Due anni dopo quel gestionale viene colpito da un ransomware (software malevolo che blocca o cifra i dati e chiede un riscatto) che sfrutta una vulnerabilità per cui non esiste una correzione.

Conto dell'incidente: 380.000 euro tra ripristino, fermo produzione e consulenti.

Più i 400.000 euro di manutenzione che nel frattempo sono stati pagati regolarmente, ogni mese, senza che nessuno li rimettesse in discussione.

Nessuno in quella stanza era distratto o incompetente.

Mancava una cosa sola: un metodo per calcolare il costo vero.

Quello che il CFO vede a budget è la punta dell'iceberg, e non è la punta a fare affondare una nave: è tutto quello che resta nascosto sotto la superficie.

Il costo del software legacy non è la voce "manutenzione IT" nel budget. È la somma di manutenzione, inefficienze, opportunità perse, rischi di sicurezza e di conformità, e costo del ricambio delle persone.

Qui dentro trovi un caso reale con i conti aperti, i costi che appaiono a budget e quelli che non ci arrivano mai, la formula per calcolare il tuo numero, il costo del rischio normativo, il confronto tra modernizzare e sostituire, e la struttura del business case da portare in consiglio.

Un'azienda che spende 200.000 euro l'anno su un software del 2005: il caso reale

Azienda manifatturiera, 180 dipendenti, 35 milioni di fatturato.

Il gestionale è stato sviluppato su misura nel 2005 in ASP.NET WebForms su SQL Server 2008, e governa ordini, produzione, magazzino e fatturazione.

Non c'è un ERP di riserva: quel software è il sistema operativo dell'azienda.

Il costo reale di quel gestionale non è 200.000 euro l'anno: è circa 507.000.

La differenza non sta in una voce dimenticata, sta in due categorie di costo che nessuno aveva mai messo su un foglio.

I costi diretti tornano, e sono esattamente quelli dichiarati: 145.000 euro di manutenzione del software, 28.000 di licenze SQL Server e Windows Server, 15.000 di gestione dei server nella sala macchine, 12.000 di backup e ripristino, con una soluzione datata che nessuno ha mai provato davvero a usare.

Totale 200.000 euro.

Fin qui la contabilità e la percezione coincidono, ed è per questo che la discussione di solito finisce qui.

Poi si va a guardare cosa fanno le persone tutto il giorno.

Ogni utente perde in media 45 minuti al giorno in operazioni manuali necessarie per aggirare i limiti del gestionale: esportazioni manuali in Excel, dati inseriti due volte in due posti diversi, attese davanti a elaborazioni lente.

Sono 40 utenti a un costo aziendale medio di 30 euro l'ora.

Quaranta per tre quarti d'ora per 230 giorni lavorativi per 30 euro fa 207.000 euro l'anno.

Da sola, questa voce supera l'intero budget IT dichiarato, e non compare in nessun bilancio perché quelle ore vengono già pagate come stipendi.

Manca l'ultima categoria, quella che il CEO capisce al volo.

Il sistema non si integra con l'e-commerce che il commerciale chiede da tre anni, non parla con il portale fornitori che vuole l'ufficio acquisti, non alimenta in tempo reale la reportistica che serve alla direzione.

Il valore di queste tre cose bloccate, stimato in modo prudente, sta tra 80.000 e 120.000 euro l'anno di fatturato che non arriva.

Duecentomila di costi diretti, 207.000 di inefficienze, 100.000 di occasioni mancate: 507.000 euro l'anno.

Contro una modernizzazione da 400.000 euro che si ripaga in meno di dodici mesi.

Il numero che ha fatto prendere la decisione sbagliata non era falso: era solo il più piccolo dei tre.

I costi visibili del software legacy: quello che appare nel budget IT

Prima di scendere sott'acqua conviene guardare bene la parte emersa, perché anche lì i conti sono quasi sempre più alti di come appaiono.

I costi visibili del software legacy sono quattro, e tendono a essere sottostimati non perché qualcuno menta, ma perché sono sparsi su voci di budget diverse che nessuno somma mai insieme: manutenzione, licenze, infrastruttura fisica e supporto agli utenti.

Manutenzione correttiva ed evolutiva

È la voce principale, ed è quella che cresce da sola.

Cresce per due motivi che si sommano.

Il primo è il sistema.

Ogni anno accumula correzioni rapide, aggiramenti e modifiche non documentate, e ogni strato rende il successivo più difficile.

Quello che nel 2015 era un intervento da tre giorni, nel 2025 richiede due settimane per fare la stessa identica cosa.

Nessuno se ne accorge nel singolo intervento: si vede solo confrontando due preventivi a dieci anni di distanza.

Il secondo è il mercato.

Chi conosce bene WebForms del 2005 non costa come uno sviluppatore .NET moderno, perché è raro e lo sa.

Il caso da cui siamo partiti lo mostra con i numeri in chiaro: la sola manutenzione del software vale 145.000 dei 200.000 euro di costi diretti, cioè il 72%, e il resto se lo prendono licenze, server e ripristini.

Per fare cose nuove non avanza niente.

Sulle aziende con sistemi molto datati la proporzione è peggiore, e la conseguenza è che l'innovazione non viene rimandata per scelta: non c'è proprio il budget.

Licenze software e infrastruttura

I sistemi legacy sono ancorati a versioni precise: Windows Server 2012 o 2016 perché le più recenti potrebbero non essere compatibili, SQL Server in versioni superate, componenti commerciali di terze parti che continuano a chiedere il rinnovo annuale anche se il fornitore li ha abbandonati.

C'è un dettaglio che vale la pena guardare in faccia: questi costi salgono, non scendono.

Chi vende manutenzione su prodotti legacy sa benissimo che il cliente non può andarsene, e i listini lo riflettono.

Hardware e infrastruttura fisica

I sistemi datati chiedono spesso hardware specifico: server nella sala macchine con caratteristiche particolari, schede di controllo, sistemi di backup dedicati.

Spazio, energia, raffreddamento e manutenzione fisica hanno un costo che quasi mai finisce sotto la voce "software legacy" del budget, pur essendone parte del costo.

E c'è un conto che arriva tutto insieme: quando quell'hardware raggiunge la fine vita, sostituirlo per far girare software che sulle macchine moderne non gira è una spesa importante che nessuno aveva previsto.

Supporto e formazione

Assistere gli utenti di un sistema legacy costa più che assisterli su uno moderno, per due ragioni semplici: l'interfaccia è stata progettata secondo gli standard di quindici anni fa, e la documentazione è incompleta o superata.

Su sistemi con più di cinquanta utenti, tra assistenza interna e formazione dei nuovi arrivati si arriva facilmente tra i 20.000 e i 40.000 euro l'anno.

Sommati, questi quattro costi restituiscono un numero che sembra alto.

Il problema è che è ancora quello sbagliato, perché è il totale della parte che si vede.

Duecentomila euro di costi diretti sembravano già un numero onesto, prima di scoprire che le inefficienze degli utenti pesano quasi altrettanto e che le occasioni perse triplicano il conto reale.

Vederlo scritto in un articolo è un conto, ricalcolarlo sul proprio sistema con i propri numeri è un altro esercizio, e quasi nessuno lo fa bene da solo la prima volta.

Nel percorso lavoriamo anche su questo: leggere un sistema esistente e trasformare quei numeri in una decisione che regge in consiglio.

I costi invisibili che nessuno calcola: il vero peso del software legacy

Un CFO mi ha detto una frase che riassume tutto: "se non è su una fattura, per me non esiste".

È un criterio ragionevole in contabilità e disastroso qui, perché i costi che affondano le aziende non hanno mai una fattura.

I costi invisibili del software legacy sono quattro e nessuno di loro compare a budget: il tempo che gli utenti perdono, le occasioni di business che il sistema non permette di cogliere, il ricambio delle persone tecniche e gli interessi che il debito tecnico matura ogni mese.

Il costo del tempo perso dagli utenti

È quasi sempre il più grande, ed è quello che sorprende di più il management la prima volta che qualcuno lo calcola davvero.

Il meccanismo è banale.

Il commerciale esporta i dati in Excel per fare un'analisi che il sistema non fa.

Il responsabile di magazzino inserisce lo stesso dato in due sistemi perché non parlano tra loro.

Il controller aspetta venti minuti un report che su un sistema moderno esce in trenta secondi.

Nessuna di queste persone si lamenta, perché fanno così da otto anni e hanno smesso di considerarlo un problema: è semplicemente "come si lavora qui".

Il metodo per misurarlo è alla portata di chiunque.

Prendi i dieci utenti che usano di più il sistema e chiedi loro di annotare per una settimana ogni aggiramento, ogni attesa, ogni passaggio manuale.

Poi moltiplichi il tempo medio giornaliero per il numero totale di utenti, per il costo orario aziendale medio, per i giorni lavorativi dell'anno.

Il risultato, quasi sempre, non entra in una slide senza far cambiare espressione a chi la guarda.

Il costo delle opportunità di business non catturate

Ogni richiesta che il sistema non riesce a supportare è un costo, anche se nessuno lo scrive.

È il più difficile da quantificare con precisione, e anche il più facile da elencare: basta chiedere.

Impossibile integrarsi con le piattaforme e-commerce moderne, e il canale digitale resta chiuso.

Impossibile fornire dati in tempo reale ai clienti, e si perdono i contratti con chi chiede visibilità sulla filiera.

Impossibile reggere i picchi stagionali, e nei periodi di alta domanda si vende meno di quanto il mercato chiederebbe.

Impossibile alimentare strumenti di analisi seri, e le decisioni si prendono su dati parziali.

Il costo del ricambio nel team tecnico

Gli sviluppatori non vogliono lavorare su sistemi legacy, e non è capriccio: è una scelta razionale di carriera.

Chi passa tre anni su WebForms del 2005 non sta costruendo competenze che il mercato paga, e lo sa benissimo.

Il risultato è un ricambio più alto della media, e ogni persona che se ne va porta via conoscenza che non è scritta da nessuna parte.

Sostituire uno sviluppatore esperto, contando ricerca, inserimento e tempo per arrivare alla piena produttività, costa tra i 30.000 e i 60.000 euro: è una delle voci che fanno salire il costo del team di sviluppo.

Se il team che mantiene il sistema è di cinque persone e ne perde due l'anno, sono 60.000-120.000 euro annui, senza contare il rischio peggiore: non trovare nessuno che sappia fare quel lavoro.

Il costo del debito tecnico accumulato

Il debito tecnico paga interessi, esattamente come quello finanziario, e la differenza è che nessuno ti manda l'estratto conto.

Ogni modo alternativo, ogni correzione rapida non documentata, ogni componente non aggiornato aumenta la complessità e riduce la velocità con cui il team può cambiare qualcosa.

L'effetto non è lineare: un sistema con debito tecnico medio richiede il doppio del tempo per le stesse modifiche rispetto a uno moderno equivalente, uno con debito alto arriva al triplo e oltre.

Qui il punto è un altro: quanto pesa sul conto annuale il debito tecnico finché resta dov'è, non come si misura o come si rientra.

È un costo che paghi ogni singolo giorno, sotto forma di funzionalità che arrivano tardi.

Quattro voci senza fattura.

La buona notizia è che si possono calcolare tutte e quattro, e il calcolo sta in mezza giornata di lavoro.

Come calcolare il costo reale del tuo software legacy: la formula pratica

Il numero che serve non è una stima da consulente: è una somma di quattro addendi che puoi mettere insieme tu, con i dati che hai già in azienda.

Il costo totale annuo del software legacy si calcola sommando quattro componenti: costi diretti, inefficienze degli utenti, opportunità non catturate e costo del rischio.

La difficoltà non è nella matematica, è nell'onestà con cui si raccolgono i dati.

Componente 1: Costi diretti annui (CD)

Sono la somma di: costo del personale dedicato alla manutenzione, cioè ore annue per costo orario, consulenti esterni compresi; licenze annue di tutto il software necessario a farlo funzionare; infrastruttura, quindi hardware, hosting, energia e backup; supporto del fornitore, dove esiste ancora.

Oppure, in forma più compatta:

C₍diretto₎ = (H × Cₕ) + Cₑ + L + I + S

dove:

• H = ore annue dedicate alla manutenzione
• Cₕ = costo orario del personale
• Cₑ = costo annuo dei consulenti esterni
• L = licenze annue
• I = infrastruttura annua: hardware, hosting, energia, backup
• S = supporto annuo del fornitore

I dati stanno nella contabilità IT, nei contratti di licenza e nelle fatture di consulenza.

È il pezzo più facile, ed è anche l'unico che oggi qualcuno guarda.

Componente 2: Costo delle inefficienze utente (CI)

La formula è: numero di utenti per ore perse al giorno per giorni lavorativi per costo orario medio.

Cᵢ = U × H × G × Cₕ

dove:

• Cᵢ = costo annuo delle inefficienze
• U = numero di utenti
• H = ore perse al giorno
• G = giorni lavorativi annui
• Cₕ = costo orario medio

L'unico dato da raccogliere è quello delle ore perse, e il modo più affidabile è un questionario strutturato che chieda agli utenti di stimare quanto tempo dedicano ogni giorno a fare a mano cose che il sistema non fa, ad aspettare elaborazioni lente, a riconciliare dati tra sistemi diversi, a sistemare i risultati del sistema per renderli utilizzabili.

Su sistemi legacy datati, una stima onesta si posiziona quasi sempre tra i 30 minuti e le 2 ore al giorno per persona.

Componente 3: Costo delle opportunità non catturate (CO)

È il dato più difficile da quantificare e quello con l'impatto maggiore; quindi, vale la pena spendere mezz'ora a farlo bene.

Chiedi al management di elencare le prime tre cose che il business ha chiesto negli ultimi due anni e che il sistema non ha potuto supportare.

Per ognuna, stima il valore: fatturato aggiuntivo, costi operativi risparmiati, clienti che non se ne sarebbero andati.

Poi prendi il valore più basso tra quelli stimati, perché un numero conservativo che nessuno può contestare vale più di un numero ottimista che qualcuno demolisce in riunione.

Puoi tradurlo così:

Cₒ = min(V₁, V₂, V₃)

dove:

• Cₒ = costo annuo delle opportunità perse
• V₁, V₂, V₃ = valore economico stimato delle tre principali opportunità che il sistema legacy non ha permesso di realizzare

Ciascun valore V può comprendere, a seconda del caso:

V = fatturato aggiuntivo + costi operativi evitati + valore dei clienti trattenuti

Componente 4: Costo del rischio (CR)

La formula è: probabilità annua di incidente per costo medio dell'incidente, più probabilità di sanzione per sanzione media attesa.

Ossia:

Cᵣ = (Pᵢ × Cᵢ) + (Pₛ × Sₘ)

dove:

• Cᵣ = costo annuo atteso del rischio
• Pᵢ = probabilità annua di incidente
• Cᵢ = costo medio dell'incidente
• Pₛ = probabilità di sanzione
• Sₘ = sanzione media attesa

Per stimare la probabilità di un incidente di sicurezza guarda tre cose verificabili: l'età delle dipendenze, la presenza di CVE note per cui non esiste correzione, la frequenza degli aggiornamenti di sicurezza applicati negli ultimi tre anni.

Una probabilità pubblica calcolata sull'età delle dipendenze non esiste: il Rapporto Clusit conta gli incidenti rilevati, non lo stato del software di chi li subisce.

Quello che il Clusit 2025 dice, e che alla tua stima serve, è che in Italia lo sfruttamento di vulnerabilità ha toccato il massimo storico, con un aumento del 90% tra il 2023 e il 2024, e che il manifatturiero è il secondo settore più colpito.

Sui sistemi che ho visto, con dipendenze anteriori al 2015 e senza aggiornamenti di sicurezza recenti, uso una probabilità annua tra il 15% e il 25%.

È una stima mia e va presentata come tale: in consiglio una stima dichiarata regge, una fonte sbagliata no.

Il costo totale e il confronto con la modernizzazione

Il costo totale annuo è la somma dei quattro componenti (Cₜ = C_d + C_i + C_o + C_r)

Prima di sommarli, conviene vederli affiancati, perché ognuno si prende da una fonte diversa:

Va confrontato con il costo della modernizzazione annualizzato: una modernizzazione da 300.000 euro su due anni vale 150.000 euro l'anno.

Se il costo totale del legacy supera quei 150.000 euro, la modernizzazione si ripaga già nel primo anno.

Se è inferiore, si ripaga comunque in due o tre anni grazie ai costi che spariscono dopo.

La cosa interessante è un'altra: quando ho visto fare questo calcolo, il management non si è convinto perché il numero era grande.

Si è convinto perché era la prima volta che qualcuno gli mostrava il numero intero.

E c'è un addendo, il quarto, che merita di essere aperto da solo, perché nel 2026 è cambiato di natura.

Il costo del rischio: sicurezza, conformità e GDPR

È la voce che il management ignora più volentieri, e per una ragione psicologica comprensibile: non è ancora successo niente.

Finché non succede, sembra teoria.

Il rischio di un sistema legacy non è un'ipotesi ma una funzione del tempo: cresce ogni mese da solo, senza che nessuno faccia niente, perché ogni nuova vulnerabilità scoperta su una dipendenza abbandonata resta aperta per sempre.

Vulnerabilità di sicurezza che nessuno correggerà

Quando una libreria, un framework o un sistema operativo esce dal supporto, le vulnerabilità scoperte dopo quella data non verranno mai corrette.

Non è una questione di priorità del fornitore: nessuno le correggerà mai.

Nel database CVE ci sono vulnerabilità documentate per .NET Framework 3.5, SQL Server 2008, Windows Server 2008 e IIS 7, tutte tecnologie ancora vive in parecchi sistemi italiani.

Chi le cerca le trova, ed è un lavoro che richiede meno competenza di quanta ne serva per usare quei sistemi.

Le conseguenze hanno prezzi noti.

Un ransomware con fermo operativo completo costa a una PMI italiana tra i 50.000 e i 300.000 euro di recupero.

Una fuga di dati porta l'obbligo di notifica al Garante e la possibilità di una sanzione.

Il danno reputazionale non ha un listino, ma i clienti che se ne accorgono sì.

Il costo di un incidente grave supera quasi sempre il costo della modernizzazione che lo avrebbe evitato.

Rischi GDPR specifici del software legacy

Il GDPR chiede quattro capacità che i sistemi del 2008-2012 quasi mai hanno: cancellare tutti i dati di una persona su richiesta, in modo completo e dimostrabile; esportarli in un formato standard; tracciare in modo granulare a cosa quella persona ha acconsentito, quando e con quale versione dell'informativa; e registrare chi ha acceduto a quali dati, quando e perché.

Un sistema che non fa queste quattro cose non è soltanto vecchio: è potenzialmente non conforme, con sanzioni che per un'azienda media arrivano a centinaia di migliaia di euro.

Il Garante Privacy italiano negli ultimi anni ha aumentato l'attività ispettiva, e le sanzioni sono arrivate anche alle PMI.

Rischi NIS2: la direttiva che molte PMI non hanno ancora considerato

Qui c'è la novità che cambia la conversazione, ed è quella che nel 2026 mette in agitazione le riunioni sbagliate.

La direttiva NIS2, in vigore dal 2024, allarga i requisiti di sicurezza informatica a un numero di aziende molto maggiore rispetto al passato, comprendendo manifatturiero, distribuzione alimentare e servizi digitali.

Chi rientra deve dimostrare di avere misure tecniche e organizzative adeguate sui propri sistemi, legacy compresi.

Un sistema con vulnerabilità note e non correggibili è, per definizione, non conforme.

Le sanzioni possono arrivare al 2% del fatturato globale annuo per le entità importanti e fino a 10 milioni di euro nei casi più gravi.

Ma il punto che sposta davvero le decisioni è un altro, e conviene dirlo in riunione con calma: la direttiva prevede la responsabilità personale dei vertici aziendali per le carenze di sicurezza documentate.

Non è più l'IT che chiede budget: è l'amministratore delegato che firma.

La responsabilità personale dei vertici introdotta dalla NIS2 cambia la conversazione, perché non è più solo un problema che l'IT può rimandare al prossimo budget.

Sapere se il proprio sistema rientra davvero in quel rischio richiede una lettura tecnica competente, non solo la lista dei segnali d'allarme.

È il tipo di valutazione che affrontiamo insieme a chi segue il percorso, applicata al sistema reale che porta in aula.

Quando il software legacy blocca la crescita aziendale

Fin qui abbiamo parlato di soldi che escono.

C'è una categoria di costo che il CEO capisce più in fretta di qualsiasi altra, ed è quella dei soldi che non entrano.

Il software legacy smette di essere un problema di manutenzione e diventa un limite strategico quando impedisce all'azienda di fare tre cose: integrarsi con gli altri, crescere di volume e decidere in fretta.

La trappola dell'integrazione impossibile

Il mercato del 2026 è fatto di integrazioni.

Vendere su un marketplace richiede che il gestionale parli con le sue API.

Usare strumenti di analisi seri richiede che i dati operativi escano in tempo reale.

Aprire un portale ai clienti richiede API che il sistema legacy non ha mai esposto.

I sistemi costruiti tra il 2005 e il 2012 non erano pensati per questo mondo.

Espongono i dati con stored procedure SQL, file CSV o interfacce proprietarie, e ogni integrazione richiede un adattamento costoso e fragile che aggiunge uno strato di complessità, rendendo più cara anche l'integrazione successiva.

Il risultato si misura in settimane.

Un concorrente che ha modernizzato implementa una nuova integrazione in due-quattro settimane.

La stessa integrazione, sul sistema legacy, richiede tre-sei mesi e costa tre-cinque volte tanto.

Ripetuto per cinque integrazioni in tre anni, questo divario diventa un ritardo strategico che costa molto più della modernizzazione.

Il blocco della scalabilità

I sistemi legacy non sono progettati per crescere.

Quando aumentano transazioni, utenti e complessità dei processi, la risposta del sistema è degradare.

E le contromosse abituali sono tutte cure sintomatiche: hardware più potente, che costa e rende sempre meno; ottimizzazioni del database, che funzionano per qualche mese; funzionalità disattivate per alleggerire il carico, che è il momento in cui l'azienda comincia a lavorare peggio per far respirare il software.

Nessuna delle tre tocca il problema, che è architetturale.

Il costo della lentezza decisionale

I dati escono in formati difficili da analizzare e arrivano in ritardo.

Il responsabile vendite che vuole sapere quali clienti hanno ridotto gli ordini nell'ultimo trimestre deve aspettare che qualcuno esporti, pulisca in Excel e componga un report: ore o giorni, non secondi.

Ogni decisione che dipende da quei dati ha un ritardo incorporato.

In un mercato dove la velocità di risposta è un vantaggio competitivo, quel ritardo è un costo, anche se non lo vedrai mai su una fattura.

Modernizzazione vs sostituzione: quale approccio conviene

Stabilito che il sistema va affrontato, arriva la domanda su cui si spaccano i consigli di amministrazione: lo modernizziamo o lo buttiamo e ne compriamo uno?

Non esiste una risposta universale, ma esiste un criterio che funziona quasi sempre: si modernizza quando la logica di business è specifica e vale, si sostituisce quando è standard e il debito tecnico è ormai fuori controllo.

Quando modernizzare conviene

Modernizzare significa tenere la logica di business e cambiare la tecnologia sotto.

Conviene quando il sistema implementa processi complessi e specifici che nessun prodotto commerciale copre.

Se il tuo software gestisce una logica di produzione, di prezzo o di filiera che è unica del tuo settore o del tuo modo di lavorare, quella logica ha un valore reale, spesso costruito in vent'anni di aggiustamenti fatti da persone che non ci sono più.

Riscriverla da zero è caro e rischioso, perché dentro c'è una conoscenza che nessuno ha mai scritto in un documento.

Modernizzare conviene anche quando il budget non regge una sostituzione in un colpo solo: l'approccio incrementale, il famoso strangler fig, tra i pattern di modernizzazione del software legacy, permette di migrare pezzo per pezzo tenendo il sistema in produzione e distribuendo la spesa nel tempo.

Quando la sostituzione conviene

Sostituire con un prodotto commerciale, ERP, CRM o piattaforma verticale, conviene quando il sistema fa cose standard che il prodotto copre bene, quando il debito tecnico è tale da rendere la modernizzazione più cara della sostituzione, e quando il prodotto offre funzionalità che il legacy non potrà mai avere.

C'è però un dato che conviene guardare prima di firmare, e che i venditori di ERP non mettono nella presentazione: i progetti di implementazione ERP sfondano budget o tempi nel 60-70% dei casi, secondo il Panorama Consulting ERP Report 2025.

Adattare i processi aziendali al prodotto, migrare i dati e formare gli utenti costa quasi sempre più di quanto scritto nel preventivo.

La valutazione pratica: tre domande per decidere

Tre domande, in quest'ordine, orientano la scelta senza bisogno di un consulente.

1. La logica di business è standard o specifica? Se è standard, un prodotto commerciale la copre.
2. Qual è il debito tecnico reale? Una valutazione tecnica esterna dice se conviene salvare o ripartire.
3. Il budget regge una sostituzione completa o serve procedere per gradi? Se è limitato, la modernizzazione incrementale è quasi sempre la scelta prudente.

Deciso il come, resta la parte in cui i progetti muoiono prima di nascere: convincere chi firma.

Il business case per il management: come presentarlo

Ho visto analisi impeccabili morire in dodici minuti.

Non per i numeri: per il linguaggio.

"Dobbiamo aggiornare la tecnologia" non è un business case, è una richiesta di fiducia.

Il caso da cui siamo partiti si presenta in tre righe: un gestionale in ASP.NET WebForms su SQL Server 2008 che costa 507.000 euro l'anno tutto compreso, 400.000 euro una tantum per portarlo su .NET 10 con interfaccia web, rientro prima dei dodici mesi.

Il consiglio non deve capire una tecnologia: deve confrontare due numeri e una data.

È lo stesso salto che separa chi tratta il software come un asset da chi lo tratta come un costo, e in consiglio cambia chi fa le domande.

Cinque sezioni, in quest'ordine.

Struttura del business case vincente

La prima sezione è il costo attuale del problema, con i quattro componenti calcolati e messi uno sotto l'altro.

È il momento più forte di tutta la presentazione, perché il management vede per la prima volta la differenza tra la voce di budget e il costo vero.

Non serve enfasi: serve la somma.

La seconda è la proiezione senza intervento, ed è quella che sposta le decisioni.

La manutenzione cresce del 5-10% l'anno perché gli sviluppatori diventano più rari, le dipendenze più vecchie e l'hardware va sostituito.

Il rischio di sicurezza sale.

Le occasioni bloccate si accumulano.

Proietta il costo cumulato a cinque anni e lascia parlare il grafico.

La terza è il costo del progetto, e qui si vince o si perde la credibilità.

Metodologia chiara su come sono stati calcolati i numeri, un margine di imprevisti del 20% dichiarato apertamente, tempi realistici con tappe verificabili e un piano di gestione del rischio.

Non presentare mai la stima ottimistica: il management che scopre uno sfondamento a metà progetto non perde fiducia nel progetto, la perde in te.

La quarta è il ritorno anno per anno nei cinque successivi al completamento: manutenzione ridotta, inefficienze ridotte, occasioni sbloccate, rischio valorizzato come costo evitato.

Con dentro il numero che tutti aspettano, cioè il momento in cui l'investimento è rientrato.

Nella maggior parte dei casi reali su sistemi datati, il rientro sta tra i 18 e i 36 mesi.

La quinta è il rischio di non fare niente, ed è quella che va maneggiata con più cura di tutte, perché basta una parola di troppo per farla sembrare allarmismo.

Presentala con i dati: casi documentati di aziende simili, anche senza nomi ma con numeri veri; stima della probabilità di incidente nei prossimi tre anni basata su fattori verificabili; conseguenze concrete in ore di fermo, costo di ripristino e sanzioni possibili.

I segnali che il tuo software legacy ha raggiunto il punto critico

Non tutti i sistemi datati sono urgenti, e conviene dirlo, perché chi tratta ogni sistema vecchio come un'emergenza perde credibilità quando l'emergenza c'è davvero.

Il punto critico si riconosce da tre famiglie di segnali di gravità decrescente: quelli di rischio, che chiedono di intervenire adesso; quelli operativi, che dicono che il sistema ti sta costando più di quanto rende; e quelli strategici, che dicono che stai perdendo terreno.

Segnali di rischio urgente

Sono quattro e ne basta uno per far diventare il tema una priorità di quest'anno.

Il sistema ha dipendenze con CVE note e nessuna correzione disponibile, perché chi le produceva ha chiuso quel prodotto.

Il sistema non è conforme a requisiti normativi in vigore, GDPR o NIS2, e l'esposizione a sanzioni è concreta.

Il sistema ha avuto almeno un incidente di sicurezza negli ultimi ventiquattro mesi, anche piccolo, e un incidente piccolo è il miglior indicatore di uno grande.

Il fornitore o il team che l'ha costruito non è più disponibile per il supporto.

Segnali di rischio operativo

Questi non ti mettono fuori legge, ti mangiano il margine.

Il costo di manutenzione annuo supera il 20% del costo originale di sviluppo.

Il tempo di rilascio di una nuova funzionalità è cresciuto di oltre il 50% negli ultimi tre anni.

Il team che mantiene il sistema ha avuto un ricambio superiore al 40% nell'ultimo anno.

Il sistema non regge più il volume operativo attuale, tra prestazioni degradate, errori frequenti e manutenzioni straordinarie che sono diventate ordinarie.

Il business ha rinunciato ad almeno tre funzionalità richieste negli ultimi diciotto mesi.

Segnali di blocco strategico

L'ultima famiglia è la più silenziosa e la più cara.

L'azienda non riesce a integrare il sistema con le piattaforme che la strategia richiede.

I concorrenti che hanno sistemi moderni stanno rilasciando cose che tu non puoi rilasciare, e la distanza cresce ogni trimestre.

Il sistema non può reggere la crescita prevista nei prossimi tre anni senza investimenti sproporzionati in infrastruttura.

Due segnali di rischio o tre operativi e la modernizzazione è urgente.

Se durante questa lista hai già riconosciuto due o tre segnali nel tuo sistema, non è un caso: la maggior parte delle aziende italiane con software legacy ne accumula più di quanti pensasse all'inizio.

La parte difficile non è riconoscerli, è capire quale affrontare per primo e con quale approccio.

È ciò che facciamo caso per caso nel percorso, partendo dal sistema di chi lo segue.

Quanto costa davvero la modernizzazione (e perché costa meno di aspettare)

A questo punto della riunione arriva sempre la stessa domanda, e va risposta con un numero, non con un "dipende".

La modernizzazione di un sistema legacy costa tra 150.000 e oltre 2 milioni di euro a seconda della dimensione, ma il numero che decide non è quello: è il confronto tra quella cifra e il costo cumulato di cinque anni di attesa.

Ordini di grandezza per la modernizzazione

Su progetti italiani, gli ordini di grandezza verificati sono tre.

Un sistema piccolo, 20-30 schermate, pochi utenti, logica relativamente semplice, sta tra 150.000 e 300.000 euro in sei-dodici mesi.

Sono le applicazioni di reparto o i sistemi secondari.

Un sistema medio, 50-100 schermate, 30-100 utenti, logica moderatamente complessa, sta tra 300.000 e 700.000 euro in dodici-ventiquattro mesi.

È il caso più frequente nel manifatturiero italiano.

Un sistema grande, oltre cento schermate e oltre cento utenti, con logica critica, va da 700.000 a oltre 2 milioni di euro su ventiquattro-quarantotto mesi.

Qui parliamo di piattaforme che sono il cuore del business.

A queste cifre si aggiungono sempre tre voci: un 20% di margine per gli imprevisti, il costo della migrazione dei dati, che su sistemi con storico complesso vale dal 10% al 20% del totale ed è la voce più sottostimata in assoluto, e il costo del periodo in cui i due sistemi girano in parallelo per verificare che si comportino allo stesso modo.

Se il sistema da migrare è in .NET, e nel manifatturiero italiano quasi sempre lo è, il conto per schermata e i tempi per tipologia di applicazione stanno nella guida alla migrazione a Blazor per sistemi .NET legacy.

Il confronto che cambia la decisione

Prendi una modernizzazione da 400.000 euro per un sistema medio e distribuiscila su cinque anni: 80.000 euro l'anno.

Confrontala con il costo totale del legacy calcolato prima: se è 300.000 euro l'anno, cosa comune su sistemi medi con più di cinquanta utenti, l'intervento rientra in meno di due anni e nei tre successivi produce un risparmio netto di 220.000 euro l'anno.

Su un orizzonte di cinque anni dopo la modernizzazione, sono 1.100.000 euro di risparmio contro 400.000 di investimento.

Ed è questa la frase da portare in riunione, non l'altra: non "la modernizzazione costa 400.000 euro", ma "non modernizzare costa 1.100.000 euro in più nei prossimi cinque anni".

Il costo reale dell'attesa

Ogni anno di rinvio aggiunge tre costi.

Il costo operativo del legacy, che continua identico.

L'aumento del costo della modernizzazione futura, perché il sistema diventa ogni anno più difficile e più caro da migrare.

E l'aumento della probabilità di incidente, che cresce con l'età delle dipendenze.

Su quasi tutti i sistemi datati, il costo di aspettare un anno supera il costo di cominciare adesso.

La differenza è che il primo lo paghi comunque, e il secondo almeno decide qualcosa.

Il costo del software legacy che non vedi è quello che ti affonda

La manutenzione che vedi a budget è reale, ma è la parte che emerge.

Sotto ci sono le ore che i tuoi utenti perdono ogni giorno senza lamentarsi, i contratti che non hai preso perché il sistema non esponeva un'API, le persone brave che se ne sono andate e il rischio che cresce da solo mentre leggi.

Il metodo per calcolarlo non richiede strumenti sofisticati.

Richiede disciplina nel raccogliere i dati, un questionario agli utenti, una revisione delle licenze, una valutazione tecnica delle dipendenze; onestà nel valorizzare le voci che di solito si ignorano; e il coraggio di portare al management il quadro intero, senza smussarlo per non spaventare nessuno.

La modernizzazione del software legacy non è una spesa IT: è un investimento con un ROI misurabile e spesso superiore alla maggior parte degli investimenti alternativi disponibili. Il management che lo capisce prende decisioni migliori.

C'è però una cosa che il calcolo non ti dà, ed è il motivo per cui alcune modernizzazioni riescono e altre diventano il secondo disastro dopo il legacy.

Servono persone capaci di leggere un sistema vecchio e capire quali regole di business ci sono nascoste dentro, di scegliere cosa salvare e cosa buttare, di dire di no quando qualcuno propone la scorciatoia che costerà sei mesi più avanti.

Quelle competenze non si comprano con il progetto: si costruiscono prima, e in azienda o ci sono o vanno formate.

Quindi la domanda con cui chiudere non è se modernizzare.

È una più scomoda: sai davvero quanto ti costa il tuo software legacy?

Non la voce di budget, il costo intero.

Se la risposta è no, hai già in mano la prima cosa da fare questa settimana, e ti costa mezza giornata di lavoro.

Se la risposta è sì, allora la conversazione con il tuo management può finalmente avvenire sui numeri e non sulle sensazioni.

I nostri esperti di modernizzazione possono guidarti in una valutazione completa del costo del tuo sistema e nella costruzione di un business case concreto, con numeri reali e un percorso praticabile: non una presentazione generica, ma un'analisi del tuo sistema, del tuo team e del tuo contesto.

Il direttore finanziario di quella riunione iniziale non aveva sbagliato i calcoli: aveva semplicemente calcolato la cosa sbagliata, perché nessuno gli aveva mai mostrato il numero intero.

Tu, a differenza sua, adesso sai dove guardare: nei costi diretti, nelle ore perse, nelle occasioni bloccate e nel rischio che cresce da solo ogni mese che passa.

La parte che manca è la stessa che mancava a lui, cioè qualcuno che sappia leggere un sistema legacy specifico e aiutarti a trasformarlo in una decisione difendibile, prima che sia un ransomware o un'ispezione NIS2 a deciderla al posto tuo.

Nel Corso Architetto Software Ai lavoriamo esattamente su sistemi come questo, con chi deve decidere se modernizzare, come farlo e come portarlo in consiglio con numeri che reggono.

Tra un anno, chi avrà fatto questo lavoro sarà chi ha già ridotto quel conto da 507.000 euro.

Chi avrà aspettato lo starà ancora pagando.