Software legacy: rifarlo, modernizzarlo o migrarlo

Rifare, modernizzare o migrare: che differenza c'è?

Rifare vuol dire riscrivere il software da zero; modernizzare vuol dire cambiarlo a pezzi mentre resta in uso; migrare vuol dire spostare dati e lavoro su un altro sistema, nuovo o già pronto. Un software legacy è un software ancora in uso che è diventato difficile da cambiare, perché la tecnologia è superata o perché chi lo conosceva non c'è più. Questa guida parla soprattutto del gestionale, il software che tocca più processi: quasi una PMI su due con almeno 10 addetti usa un gestionale ERP, il 48,8% nel 2025 secondo l'ISTAT.

In pratica le strade sono sei, e spesso si combinano.

Un'API è il punto da cui un software scambia dati con un altro senza che una persona li copi. Collegare e rifare l'interfaccia sono le strade più leggere: in una dashboard di assistenza sul campo e in una di telesoccorso il backend esistente è rimasto dov'era e l'interfaccia nuova gli parla attraverso le sue API. Le altre strade, e come si collegano fra loro, sono nella pagina sull'integrazione con l'ERP.

Rifarlo in blocco costa come un software nuovo: da circa 15.000 € in 2-3 mesi per un gestionale essenziale, da 45.000 € e da 4 mesi per una piattaforma, più la migrazione dei dati.

Molte guide, anche in italiano, chiamano le strade con nomi inglesi che cominciano per R. Tenerlo è retain; spostarlo così com'è su un altro server o sul cloud è rehost, e spostarlo con pochi ritocchi, per esempio passando a un database gestito dal fornitore del cloud, è replatform. Ripulire il codice senza cambiare quello che fa è refactor, riprogettarne la struttura è rearchitect, rifarlo in blocco è rebuild, passare a un prodotto pronto è replace. Collegarlo via API è encapsulate, e sostituirlo un modulo alla volta è il metodo strangler fig, descritto più avanti.

Lo studio di fattibilità dura da 1 a 2 settimane e costa fino a 2.500 €, scalati dal primo intervento se firmi. Si leggono il codice e il database, si misura quanto lavoro a mano costa oggi il sistema e si sceglie la strada. Le sei strade non si escludono: la soluzione più comune è un prodotto pronto per la contabilità, moduli su misura per il lavoro che ti distingue e il sistema vecchio collegato via API finché serve.

Fra prodotto pronto e su misura decide una domanda: quella parte del lavoro è uguale a quella di tutti, o è il modo in cui ti distingui dai concorrenti? Nel primo caso un prodotto pronto costa meno, gli aggiornamenti per le regole nuove li fa il produttore e il processo si adatta al prodotto. Nel secondo, piegare il processo al prodotto ti toglie proprio quello che ti distingue. Nelle risposte degli assistenti AI si trova anche una soglia: su misura quando le personalizzazioni superano il 30% delle funzioni usate. Fra le pagine che abbiamo letto per questa guida la dà una sola, senza fonte, e la domanda che decide resta l'altra: conta che cosa personalizzi, non quanto.

Quando va cambiato davvero?

Quando tenerlo ti costa più che cambiarlo, o quando smette di essere sicuro. L'età da sola non è un motivo: un gestionale di vent'anni che fa il suo lavoro, riceve aggiornamenti di sicurezza e si collega a quello che serve si tiene.

Il segnale più netto è la fine del supporto. Quando il sistema operativo, il database o l'ambiente in cui il software è scritto non ricevono più aggiornamenti di sicurezza, ogni difetto scoperto da quel giorno resta aperto. Ecco tre componenti che si trovano spesso sotto i gestionali delle PMI.

Gli altri segnali si misurano in ore e in occasioni perse. I dati passano a mano da un sistema all'altro, e ogni passaggio è un errore possibile. Solo una persona sa come funziona il software, ed è la persona che sta per andare in pensione o il fornitore che ha chiuso. Ogni modifica costa più della precedente e richiede più tempo. Il software non va sui tablet e sui telefoni che le tue persone usano già, oppure una regola nuova, come è stata la fatturazione elettronica, diventa un progetto invece di un aggiornamento.

Un segnale da solo non basta per decidere, ma due o tre insieme dicono che è ora di fare i conti.

Quanto costa tenerlo, e quanto cambiarlo?

Cambiarlo un modulo alla volta parte da 10.000 € per il primo modulo; rifare in blocco un gestionale essenziale parte da circa 15.000 €, più la migrazione dei dati. Tenerlo costa la manutenzione che paghi oggi, più il lavoro a mano e il rischio: per decidere si confrontano tre anni di costi reali, voce per voce, non una percentuale. Nelle risposte automatiche dei motori di ricerca si trova una soglia: cambiare quando la manutenzione supera il 30-40% del costo di un rifacimento. Nessuna delle pagine che abbiamo letto per questa guida ne indica la fonte, e un rapporto fra due costi lascia fuori le voci che pesano di più: il lavoro a mano e il rischio.

Il lavoro a mano è la voce che nel bilancio non compare, perché sta negli stipendi: si misura contando le ore di una settimana tipica. Nello studio di fattibilità il confronto lo facciamo con le tue cifre, e se tenere il sistema conviene, lo scriviamo. Come si forma il prezzo di un software su misura, e perché la manutenzione non si calcola in percentuale, è nella guida quanto costa un software su misura.

Quando conviene rifarlo da zero?

Più di rado di quanto si pensi. Riscrivere tutto cancella anni di correzioni sui casi limite, che nel codice vecchio ci sono anche se nessuno le ha documentate. Conviene in tre casi: la tecnologia non è più mantenuta, è rimasta così indietro rispetto a quella attuale che ogni modifica costa più di riscriverla, oppure il modello dei dati impedisce quello che serve all'azienda. Succede, per esempio, quando servono più sedi o più società e il sistema ne prevede una sola.

Il caso più citato è quello di Netscape, raccontato da Joel Spolsky nel 2000: l'azienda decise di riscrivere il browser da zero, e non ci fu mai una versione 5.0. Quando la 6.0 entrò nella prima beta pubblica la 4.0 era uscita da quasi tre anni, mentre la quota di mercato crollava. Spolsky lo chiamò l'errore strategico peggiore che un'azienda di software possa fare, e spiegò perché: le righe del codice vecchio che sembrano inutili sono, in gran parte, correzioni di bug.

Martin Fowler, che ha dato il nome alla sostituzione graduale, scrive che il piano di rifare lo stesso sistema con una tecnologia nuova fallisce nella maggior parte dei casi. Sostituire un sistema serio richiede molto tempo, spiega, e nel frattempo chi lo usa non può aspettare le funzioni nuove. Per questo anche quando si riscrive, si rilascia per parti, e ogni parte va in produzione appena è pronta.

Come si cambia senza fermare il lavoro?

Un pezzo alla volta, con il sistema vecchio acceso finché il nuovo non ha dimostrato di fare lo stesso lavoro. Il metodo si chiama strangler fig, dal fico che cresce intorno a un albero fino a prenderne il posto. Davanti al sistema vecchio si mette un punto di passaggio che manda ogni richiesta al vecchio o al nuovo, e a ogni modulo pronto la quota del nuovo cresce. Nella descrizione di Microsoft, chi usa il sistema continua a lavorare con la stessa interfaccia e non si accorge che la migrazione è in corso.

Riconciliare vuol dire controllare che i conti tornino: non che i dati siano stati copiati, ma che dicano le stesse cose. La migrazione dei dati si prova prima del passaggio, non durante. Come colleghiamo due sistemi senza fermarli, dalla mappa dei dati ai contratti delle API, è descritto nella pagina sull'integrazione.

Il metodo non va bene sempre. Secondo Microsoft non conviene quando le richieste al sistema vecchio non si possono intercettare, o quando non hai accesso al codice e non c'è un altro punto da cui collegarsi, per esempio il database. Lo stesso vale, per Microsoft, quando il sistema è piccolo e sostituirlo tutto è semplice, e quando la parte vecchia va dismessa in fretta. In questi casi si rifà in blocco o si sceglie un prodotto pronto, con le stesse prove sui dati.

Un prodotto pronto non toglie il rischio del passaggio. Gartner prevede che entro il 2027 oltre il 70% delle iniziative ERP implementate di recente non raggiungerà del tutto gli obiettivi di business per cui era partita. Come causa indica gli approcci centrati sulla tecnologia, che non coinvolgono le persone interessate. Chi userà il sistema nuovo entra nel progetto dall'inizio, non il giorno del passaggio.

Che cosa succede ai dati storici?

Non si buttano. La legge chiede di conservarne una parte per anni, e il GDPR chiede di non tenere i dati personali più del necessario. Per ogni tipo di dato si decide se migrarlo, archiviarlo in sola lettura o cancellarlo.

L'articolo 2220 del codice civile chiede di conservare le scritture contabili per dieci anni dalla data dell'ultima registrazione, e per lo stesso periodo le fatture e la corrispondenza ricevute e le copie di quelle spedite. Si possono conservare in forma digitale, se si possono rendere leggibili in qualsiasi momento. Se hai aderito al servizio gratuito di conservazione dell'Agenzia delle Entrate, le fatture elettroniche passate dal Sistema di Interscambio restano conservate lì per 15 anni, anche se chiudi la partita IVA. Per i dati personali vale la limitazione della conservazione dell'articolo 5 del GDPR: si tengono in una forma che permette di identificare le persone solo per il tempo necessario allo scopo per cui sono stati raccolti.

Il tuo commercialista ti dice se per alcuni anni valgono termini più lunghi. Come le altre guide, questa è un contributo tecnico, non un parere legale.

E se il fornitore non c'è più?

Si riparte dal codice, se ce l'hai, altrimenti dal database e da quello che il software fa. La legge sul diritto d'autore dà al datore di lavoro, salvo patto contrario, i diritti economici sul software scritto dai suoi dipendenti (articolo 12-bis della legge 633 del 1941). Quando il software lo scrive un fornitore, invece, che cosa passa a te lo stabilisce il contratto: prima di tutto si rilegge quel contratto.

Se il codice ce l'hai, un team nuovo lo legge, ricostruisce le regole che contiene e sceglie la strada. Se non ce l'hai, si lavora sul database e su quello che il software fa, osservato con chi lo usa ogni giorno. Senza codice e senza un altro punto da cui collegarsi, la sostituzione un modulo alla volta non si può fare, e si passa a rifarlo o a un prodotto pronto.

Con noi il problema non si pone: ogni milestone pagata ti trasferisce la proprietà della parte di progetto che copre, e la cessione è scritta nel contratto. Se un giorno cambi fornitore, il codice è già tuo.

Con un prodotto pronto in cloud il codice resta del produttore, e quello che conta è poter riprendere i dati. Il regolamento europeo sui dati, il Data Act, obbliga chi offre software come servizio a esportarli in un formato di uso comune e leggibile da una macchina, e a togliere gli ostacoli al passaggio a un altro fornitore. Secondo la Commissione europea, dal 12 gennaio 2027 il fornitore non potrà più farti pagare né il passaggio né l'uscita dei dati.

E se chi lo conosce va in pensione?

Prima di scegliere la strada si mette in sicurezza il sistema, finché quella persona c'è ancora. Si recuperano il codice sorgente, con il contratto che dice di chi è, e le credenziali di server, database e servizi collegati. Si fa una copia completa e si prova a ripristinarla su un'altra macchina: un backup che nessuno ha mai ripristinato non dimostra che i dati si possono recuperare. Poi chi conosce il sistema mostra, a chi dovrà prenderlo in mano, le operazioni che nessun altro sa fare: la chiusura di fine mese, l'aggiornamento dei listini, gli errori che sa già come aggirare. La messa in sicurezza parte da 5.000 €.

Fatto questo, la scelta non ha più fretta, e lo studio di fattibilità parte da una base sicura: il codice, il database e quello che finora sapeva una persona sola.

L'AI aiuta a modernizzare un software vecchio?

Sì, a leggerlo e a provarlo, non a decidere. Gli assistenti al codice leggono codice senza documentazione e descrivono che cosa fa una funzione, trovano le parti che nessuno chiama più e scrivono i test che fissano il comportamento attuale prima di cambiarlo. Quello che dicono va verificato: le prove sui dati veri e una persona che risponde del risultato restano il criterio.

Anche prima dei modelli linguistici, su sistemi grandi l'analisi si fa con strumenti automatici. Per un'azienda dell'automotive abbiamo analizzato la qualità del codice di un paio di applicativi che contavano decine di migliaia di file: a mano sarebbe stato troppo lungo e troppo costoso. Come si misura e si gestisce il debito accumulato in un sistema lo racconta l'articolo sul debito tecnico. L'AI ci rende più veloci, e le ore risparmiate non te le fatturiamo.

Un esempio illustrativo: il gestionale di un distributore

L'esempio è illustrativo: l'azienda è inventata, le durate e le cifre sono quelle del nostro listino.

Un distributore di ricambi con venti persone usa un gestionale scritto in Visual Basic 6 da un fornitore che ha chiuso, su un server Windows con SQL Server 2016. Il codice ce l'ha, perché il contratto lo prevedeva. Gli agenti prendono gli ordini su carta e li dettano al telefono, e la contabilità sta in un prodotto commerciale che funziona bene.

Nello studio si contano anche le ore di lavoro fatte a mano e si scrive il piano per i dati storici. Nel primo modulo gli ordini passano al gestionale vecchio attraverso il suo database, e il resto del lavoro non cambia.

La contabilità resta nel prodotto che l'azienda usa già, collegata via API: rifarla non darebbe niente in più. Ogni modulo va in produzione da solo, e se dopo il primo l'azienda decide di fermarsi, ha comunque gli ordini da tablet e il gestionale di prima.

Come confronti due proposte di modernizzazione?

Fai a ogni fornitore le stesse domande, per iscritto: quale strada e perché, che cosa va in produzione per primo, che cosa succede ai dati storici e come si torna indietro. Poi quanto dura il periodo in parallelo, se il lavoro si ferma, chi forma le persone, quanto costa in tre anni, chi documenta le regole trovate nel codice e quando il codice passa a te. Una proposta che salta il piano per i dati o il ritorno indietro rimanda il rischio al giorno del passaggio.

Per il resto del preventivo valgono le voci della guida sui costi.

Fonti e approfondimenti

• «Strangler Fig pattern», Azure Architecture Centerlearn.microsoft.com, consultato il 22 ottobre 2026
• Martin Fowler, «Strangler Fig», 22 agosto 2024martinfowler.com, consultato il 22 ottobre 2026
• Joel Spolsky, «Things You Should Never Do, Part I», 6 aprile 2000joelonsoftware.com, consultato il 22 ottobre 2026
• «Windows 10 Home and Pro», ciclo di vita del prodottolearn.microsoft.com, consultato il 22 ottobre 2026
• «SQL Server 2016», ciclo di vita del prodottolearn.microsoft.com, consultato il 22 ottobre 2026
• «Support Statement for Visual Basic 6.0»learn.microsoft.com, consultato il 22 ottobre 2026
• Codice civile, articolo 2220, conservazione delle scritture contabilinormattiva.it, consultato il 22 ottobre 2026
• Agenzia delle Entrate, «Registrazione e conservazione delle fatture», risposte alle domande più frequenti sulla fattura elettronicaagenziaentrate.gov.it, consultato il 22 ottobre 2026
• Regolamento (UE) 2016/679 sulla protezione dei dati (GDPR), articolo 5eur-lex.europa.eu, consultato il 22 ottobre 2026
• ISTAT, «Imprese e ICT, anno 2025», 15 dicembre 2025istat.it, consultato il 22 ottobre 2026
• Gartner, «What IT Leaders Must Do to Avoid Disappointing ERP Initiatives», analista Denis Toriigartner.com, consultato il 22 ottobre 2026
• Commissione europea, «Legge sui dati spiegata», capo VI sul passaggio fra servizi di trattamento dei datidigital-strategy.ec.europa.eu, consultato il 22 ottobre 2026