Modernizzazione del software legacy: la guida per le PMI che non possono fermarsi
La modernizzazione del software legacy è il lavoro con cui si sostituisce o si rinnova un programma datato che l’azienda usa ancora ogni giorno. Per una PMI, il modo più prudente di farla è procedere un pezzo alla volta: il nuovo cresce accanto al vecchio e nulla viene spento finché la sua sostituzione non è in uso e collaudata.
Se dirigi un’azienda, probabilmente non ti interessa la tecnologia in sé. Ti interessa sapere tre cose: se il programma su cui lavori da anni è un rischio, quanto costa cambiarlo e se puoi farlo senza bloccare ordini, magazzino e fatture. Questa guida risponde in quest’ordine, e dice anche quando conviene non fare nulla.
Quando un software diventa legacy
Un software è legacy quando continua a funzionare, ma è diventato difficile o rischioso cambiarlo. L’età conta poco: un programma di vent’anni con un tecnico che lo conosce e aggiornamenti regolari può essere sano, mentre uno di dieci anni senza documentazione e senza più nessuno che ci metta le mani può già essere un problema.
I casi che incontriamo più spesso nelle PMI sono questi:
- programmi desktop scritti in Delphi, Visual Basic 6 o FoxPro, installati PC per PC;
- piccoli gestionali costruiti in Access o su Excel con macro, nati per un’urgenza e diventati il cuore dell’azienda;
- applicazioni web in ASP classico o ASP.NET WebForms, lente e scomode da telefono;
- gestionali chiusi che non comunicano con e-commerce, CRM o altri programmi;
- database come Firebird o SQL Server ospitati su un server in ufficio.
Se vuoi una verifica più precisa, abbiamo raccolto i segnali in cos’è il software legacy e quando diventa un rischio. Per alcune tecnologie trovi una guida dedicata: Delphi, ASP.NET WebForms e ASP classico, FoxPro e Firebird.
Perché è difficile accorgersi del problema
Il software legacy non si rompe di colpo. Funziona, e proprio per questo la decisione viene rimandata di anno in anno. Il conto però cresce in modi poco visibili:
- Dipendenza dalle persone. Spesso una sola persona, interna o esterna, sa davvero come è fatto il programma. Se smette di lavorarci, il problema diventa urgente da un giorno all’altro. Ecco come proteggerti quando il software dipende da una sola persona.
- Sicurezza. Un sistema che non riceve più aggiornamenti resta esposto. Microsoft, per esempio, ha terminato il supporto di Windows 10 il 14 ottobre 2025 e quello di SQL Server 2016 il 14 luglio 2026. Il programma continua a girare, ma ciò che ha intorno invecchia. Se stai cambiando i PC, leggi cosa fare se un programma vecchio non funziona su Windows 11; per il database, le scelte quando SQL Server è fuori supporto.
- Lavoro manuale. Dati copiati a mano tra programmi diversi, fogli Excel paralleli, controlli fatti a occhio. Sono ore che nessuno mette in bilancio come costo del software.
- Progetti bloccati. Vuoi aprire un e-commerce, dare un’app agli agenti o vedere i dati in tempo reale, e scopri che il sistema attuale non lo permette.
Non serve che ci siano tutti. Ne basta uno serio per giustificare almeno una valutazione. Gli sviluppatori chiamano una parte di questo costo debito tecnico: sono gli interessi che paghi a ogni modifica.
Quando conviene non fare nulla
Lo diciamo anche se è il nostro mestiere: non tutto il software datato va toccato. Se il programma fa bene un compito limitato, non contiene dati critici, gira isolato e c’è ancora chi sa mantenerlo, sostituirlo può essere una spesa senza ritorno.
In altri casi basta poco. Se il problema è solo che “non parla” con l’e-commerce, spesso è sufficiente un collegamento e il gestionale può restare dov’è. Se il tuo processo è standard e sul mercato esiste un prodotto che lo copre bene, comprarlo può costare meno che farlo su misura: ne parliamo in gestionale su misura o standard.
La modernizzazione ha senso quando il rischio di restare fermi supera il costo di muoversi. Il punto è misurarlo, non indovinarlo.
Le strade possibili
Sotto i nomi tecnici, le opzioni sono poche. Questa tabella le riassume dal punto di vista di chi deve decidere.
| Strada | In pratica | Quando ha senso | Limite principale |
|---|---|---|---|
| Spostare così com’è | Il programma resta uguale, cambia dove gira | Il problema è solo il server in ufficio | Restano tutti i limiti del programma |
| Collegare | Si costruisce un accesso ai dati sopra il sistema esistente | I programmi non si parlano | Il vecchio resta e va comunque mantenuto |
| Sostituire a pezzi | I moduli nuovi entrano uno alla volta, accanto al vecchio | Il sistema è critico e non può fermarsi | Per un periodo convivono due sistemi |
| Riscrivere tutto insieme | Si costruisce il nuovo e a una certa data si cambia | Programma piccolo e poco critico | Rischio concentrato in un solo passaggio |
| Comprare un prodotto pronto | Si adotta un software standard | Processi comuni, nessuna esigenza particolare | Devi adattarti tu al prodotto, e migrare comunque i dati |
La scelta tra riscrivere e sostituire a pezzi è quella che pesa di più. L’abbiamo approfondita in riscrivere il software da zero o sostituirlo un pezzo alla volta. Le opzioni si possono anche combinare: spesso si parte da un collegamento e poi si sostituisce un modulo alla volta. Se il tuo tema è la macchina in ufficio, leggi migrare il server aziendale in cloud. Se pensi a un prodotto pronto, trovi i passaggi in cambiare gestionale senza perdere dati.
Come si cambia senza fermare il lavoro
La continuità non è una promessa: è il risultato di un metodo preciso. L’idea è nota tra gli sviluppatori. Martin Fowler la descrive con l’immagine del fico strangolatore, una pianta che cresce attorno a un albero fino a sostituirlo. Nel suo articolo osserva che il piano apparentemente semplice di rifare tutto e cambiare in un colpo solo fallisce nella maggior parte dei casi, e che il rischio di componenti piccoli introdotti gradualmente è molto minore.
Noi lo applichiamo in quattro fasi.
1. Audit: capire cosa c’è davvero
Si mappano codice, database, flussi di lavoro e persone coinvolte. Ne esce un piano con rischi, priorità, tempi e costi. Trovi cosa guardare nella guida all’audit del software aziendale.
2. Ponte: vecchio e nuovo usano gli stessi dati
Sopra il sistema attuale si costruisce un collegamento, in modo che le parti nuove lavorino sugli stessi dati del vecchio. Il sistema attuale non viene modificato e continua a funzionare come prima.
3. Sostituzione: un modulo alla volta
Si parte da dove il problema è più grave: per esempio gli ordini, poi il magazzino, poi i clienti. Ogni modulo entra in funzione affiancato al vecchio, finché non è collaudato.
4. Spegnimento: il vecchio va in pensione
Solo quando tutto è sostituito si archivia il vecchio software. I dati storici restano consultabili.
E se qualcosa va storto?
Nessun serio professionista può promettere che un rilascio non avrà mai problemi. Quello che il metodo cambia è la conseguenza del problema. Finché vecchio e nuovo non hanno gli stessi dati, in azienda si usa solo il vecchio, quindi un errore del nuovo non tocca il lavoro. Dopo funzionano insieme, quindi se il nuovo ha un problema lo si corregge mentre l’azienda continua a lavorare.
Da dove partire, in base al sintomo
Il punto di partenza dipende da dove fa più male, non dalla tecnologia. Ecco i percorsi più comuni.
“Il programma funziona solo in ufficio”
Di solito è un software desktop da trasformare in un’applicazione web, utilizzabile da browser senza installazioni. Se il tuo è scritto in Visual Basic 6, leggi cosa fare con un programma VB6. È un caso che abbiamo seguito direttamente: un vecchio software VB6 è diventato una webapp. Trovi i pro e i contro in applicazione web o desktop, e la soluzione più rapida in come usare il gestionale da remoto. Se il problema è la velocità, parti da gestionale lento: come trovare la causa.
“I dati sono sparsi tra Excel e vecchi database”
Qui il primo passo è mettere i dati in un unico posto. Abbiamo portato su una webapp cloud un’azienda che lavorava su un Excel condiviso in una cartella di rete, e la guida su quando sostituire Excel in azienda nasce da lavori come quello. Se il dato è in Access, parti da come migrare un database Access al cloud. Se il cuore del file sono le macro, leggi come sostituire le macro Excel VBA.
“I programmi non si parlano”
Spesso il gestionale può restare dov’è. In un nostro progetto abbiamo collegato un vecchio gestionale su misura a un CRM nuovo, senza sostituirlo. Le opzioni sono spiegate in come collegare un gestionale senza API a e-commerce e CRM. Trovi gli approfondimenti su integrazione tra CRM e gestionale e sul portale clienti B2B.
“Chi è fuori sede non vede il gestionale”
Agenti, tecnici e magazzinieri possono lavorare da un’app collegata al sistema esistente. In un altro progetto siamo partiti da una semplice cartella di rete e siamo arrivati a un insieme di app e webapp che lavorano sugli stessi dati. Trovi i dettagli in app per agenti e tecnici collegata al gestionale.
“Il fornitore è sparito”
Qui la priorità è mettere al sicuro dati e programma, prima ancora di scegliere la strada. Trovi le prime cose da fare in il fornitore del software ha chiuso.
“Perdiamo ore in attività ripetitive”
Non sempre serve sostituire qualcosa. In alcuni casi si possono migliorare procedure e compiti ripetitivi anche con l’AI, ma funziona bene solo se i dati sono ordinati e raggiungibili. Per questo, di solito, questo passo arriva dopo aver messo in sicurezza i dati. Il metodo è spiegato in come automatizzare i processi aziendali con l’AI.
Quanto costa e quanto dura
Una cifra valida per tutti non esiste, e diffida di chi te la dà senza aver guardato il sistema. Il costo dipende soprattutto dalla quantità di funzioni da conservare, dalla qualità dei dati, dalla presenza di documentazione e dal numero di collegamenti con altri programmi. Ne parliamo in dettaglio in quanto costa rifare un gestionale.
La durata dipende dagli stessi fattori. Procedere a pezzi ha però un vantaggio pratico: l’investimento non è concentrato in un unico salto. Ogni modulo in produzione porta un beneficio subito, e puoi rivalutare il piano dopo ogni passaggio.
Una cosa la puoi pretendere da qualsiasi fornitore: perimetro e costo chiari prima di firmare. Noi lavoriamo a prezzo fisso, definito dopo l’audit. Considera anche cosa succede dopo il rilascio: ne parliamo in contratto di manutenzione software.
Cosa cambia per le persone
La parte tecnica è solo metà del lavoro. Un programma nuovo che nessuno vuole usare resta un costo, e le persone tornano a Excel in pochi giorni. Tre abitudini riducono molto questo rischio.
- Coinvolgere subito chi lavora ogni giorno. Non per cortesia: sono loro a conoscere le eccezioni che fanno saltare i progetti.
- Nominare un referente interno. Serve una persona che risponda alle domande, decida sui dubbi e collaudi ogni modulo. Va messo in conto il suo tempo, anche se non compare in nessuna fattura.
- Formare a piccole dosi. Procedendo per moduli, ognuno impara solo la parte che gli serve, nel momento in cui entra in funzione. È molto più semplice che imparare tutto in un giorno.
Come scegliere a chi affidarti
Il rischio più grande spesso non sta nella tecnologia, ma nel contratto. Ecco cosa chiedere a qualsiasi fornitore, noi compresi.
| Domanda | Una buona risposta | Un segnale di allarme |
|---|---|---|
| Come fate il preventivo? | Dopo aver analizzato sistema e dati | Una cifra senza aver visto nulla |
| Il prezzo può cambiare? | Spiega cosa è incluso e come si gestiscono le modifiche | “Vediamo strada facendo” |
| Quando dovremo fermarci? | Descrive quando e per quanto, con un piano | “Mai”, senza spiegare come |
| Se un rilascio va male? | Descrive un meccanismo preciso | “Non succederà” |
| Di chi sono codice e dati? | Tuoi, con documentazione e accessi completi | Licenza d’uso o accessi solo tramite loro |
| Chi lavora al progetto? | Può parlare direttamente con chi sviluppa | Solo intermediari commerciali |
Chiedi anche esempi di lavori simili al tuo, per tecnologia di partenza e non solo per settore. Migrare un programma VB6 e gestire un foglio Excel con macro sono problemi diversi, anche nella stessa azienda. L’elenco completo è in come scegliere una software house per il gestionale.
Cosa preparare prima di parlare con qualcuno
Non serve un documento tecnico. Bastano poche informazioni per rendere molto più utile il primo incontro:
- l’elenco dei programmi in uso e chi li usa;
- il processo che oggi crea più problemi e cosa costa, anche a spanne;
- il nome di chi conosce il sistema e dove si trova il codice sorgente;
- i contratti in corso con i fornitori attuali, con le relative scadenze;
- i periodi dell’anno in cui l’azienda non può permettersi imprevisti;
- ciò che vorresti fare e che oggi il sistema ti impedisce.
L’ultimo punto conta più di quanto sembri. Il motivo per cui si modernizza raramente è la tecnologia: è poter fare qualcosa che oggi non si può.
Gli errori che vediamo più spesso
- Partire dalla tecnologia. “Dobbiamo passare al cloud” non è un obiettivo. “Gli agenti devono vedere le giacenze dal telefono” lo è.
- Copiare il vecchio programma pari pari. Molte funzioni non le usa più nessuno. Sostituirle tutte significa pagare per ricostruire ciò che andrebbe eliminato.
- Ignorare i dati. I problemi peggiori emergono spesso nei dati: duplicati, campi usati in modo creativo, regole mai scritte. Vanno controllati prima, non durante il passaggio finale.
- Non coinvolgere chi usa il programma. Le regole vere dell’azienda sono spesso nella testa di chi lavora ogni giorno, non nella documentazione.
- Restare legati al nuovo fornitore. Assicurati di ricevere codice sorgente, documentazione e accesso completo all’infrastruttura. Altrimenti cambi software, ma non cambi il problema.
Domande frequenti
Devo fermare il lavoro durante la migrazione?
Con un approccio graduale, no. Il sistema attuale resta attivo finché ogni parte nuova non è collaudata. Il passaggio finale dei dati si pianifica nei momenti di minor carico.
Il mio gestionale è chiuso: si può modernizzare comunque?
Quasi sempre sì. Si può lavorare sul database sottostante, su esportazioni programmate o sulle interfacce disponibili. Va però verificato caso per caso, anche dal punto di vista contrattuale.
Meglio un software su misura o un prodotto pronto?
Se il tuo processo è comune, valuta prima un prodotto pronto. Il su misura conviene quando il modo in cui lavori è parte del tuo vantaggio o quando i prodotti standard ti costringerebbero a troppi compromessi.
Da dove si comincia, concretamente?
Da un inventario di ciò che esiste e da un’analisi dei rischi. Senza quello, ogni preventivo è una stima al buio. Da noi questo passo è l’audit, che è gratuito e dura una settimana.