La migrazione dei dati è, quasi sempre, la parte che preoccupa di più quando si decide di cambiare gestionale. Nel vecchio sistema ci sono anni di clienti, fornitori, articoli, ordini, movimenti di magazzino, listini, documenti: la paura più comune è semplice, cosa succede se durante il passaggio si perde qualcosa.
Ma la domanda giusta non è solo questa. È anche: cosa dobbiamo davvero portare nel nuovo sistema? Quanto storico serve per lavorare, non solo per sicurezza? Chi controlla che i dati arrivati siano corretti, non solo presenti? Per quanto tempo va tenuto accessibile il vecchio gestionale? Una migrazione fatta bene non consiste nel copiare tutto il vecchio database nel nuovo: consiste nel decidere cosa deve accompagnare l'azienda nel nuovo sistema, in che forma e con quali controlli — ed è proprio questa parte decisionale quella che viene sottovalutata più spesso.
In termini semplici, migrare significa trasferire le informazioni dal vecchio gestionale al nuovo. Ma "trasferire" nasconde più lavoro di quanto sembri: un cliente può avere campi diversi tra i due sistemi, un articolo può portarsi dietro un codice costruito dieci anni fa, un'anagrafica può essere duplicata con nomi leggermente diversi senza che nessuno se ne sia mai accorto.
Prima che un dato possa entrare nel nuovo sistema, va estratto dal vecchio, capito, pulito quando serve, adattato alla struttura del nuovo software, caricato e infine verificato. La parte tecnica è solo metà del lavoro: l'altra metà è sapere cosa dovrebbe esserci, ed è una conoscenza che il fornitore del nuovo gestionale raramente possiede da solo — la possiedono le persone che usano quei dati ogni giorno. Per questo una buona migrazione è quasi sempre un lavoro a due: chi conosce il software e chi conosce davvero i dati.
Va detto che la parte tecnica, negli ultimi anni, è diventata più semplice. Diversi fornitori hanno sviluppato motori di migrazione proprietari pensati per importare dati direttamente dai gestionali più diffusi, riducendo tempi e rischi della fase di estrazione: Gest24, ad esempio, utilizza un motore compatibile con sistemi come Navision, eSolver, Target Cross, Alyante e Ad Hoc, oltre a diversi altri. Strumenti di questo tipo aiutano molto sulla parte meccanica del trasferimento, ma non sostituiscono le decisioni che restano comunque dell'azienda: cosa migrare, quanto storico, e chi verifica che il risultato sia corretto e non solo tecnicamente riuscito.
Dipende da quanto è strutturata l'azienda. In un caso semplice bastano clienti, fornitori, articoli, listini, condizioni commerciali, saldi iniziali e ordini ancora aperti. In un progetto più articolato entrano in gioco anche storico ordini, movimenti di magazzino, lotti, distinte base, cicli di produzione, commesse, cespiti, scadenziari e documenti allegati.
Più categorie di dati vanno trasferite, più aumentano le relazioni da preservare: un ordine non è solo una riga con un importo, è collegato a un cliente, a uno o più articoli, a condizioni commerciali e talvolta alla produzione. La vera difficoltà di una migrazione, più che nel volume dei dati, sta proprio nel mantenere corretti questi collegamenti.
È una delle decisioni più importanti di tutto il progetto, e la risposta di default non dovrebbe essere "tutto". Più storico si trasferisce, più aumenta il lavoro di estrazione, pulizia e verifica — e più cresce il rischio di portare nel nuovo sistema problemi che appartenevano solo al vecchio. Ci sono in pratica tre strade.
Migrare tutto lo storico. Ha senso quando esiste una reale necessità operativa di consultarlo direttamente nel nuovo gestionale. È l'opzione più completa, ma anche quella che richiede più tempo e controlli.
Migrare solo lo storico realmente utile. Nella maggior parte dei casi bastano l'anno corrente, uno o due esercizi precedenti, gli ordini ancora aperti e le partite contabili aperte. Il resto resta disponibile nel vecchio sistema o in un archivio.
Migrare solo l'operativo e tenere il vecchio gestionale in consultazione. Un'opzione spesso sottovalutata: il nuovo sistema contiene ciò che serve per lavorare da una certa data in avanti, il vecchio resta accessibile in sola lettura per lo storico. Evita di trasformare la migrazione in un progetto enorme solo per avere nel nuovo ERP dati che verranno guardati due volte l'anno.
La domanda giusta, quindi, non è "quanto storico possiamo migrare", ma quanto storico serve davvero per lavorare nel nuovo sistema. Per l'impatto che questa scelta ha sui costi, trovi il dettaglio nella guida su quanto costa cambiare gestionale.
Senza entrare nel gergo tecnico, una migrazione ben organizzata attraversa in genere questi passaggi.
Si parte definendo il perimetro: quali anagrafiche, quali documenti, quale storico, cosa invece può restare consultabile solo nel vecchio sistema. Saltare questa decisione significa rischiare di scoprire troppo tardi che quello che il fornitore pensava di migrare non coincide con quello che l'azienda si aspettava.
Segue l'analisi dei dati esistenti, che quasi sempre fa emergere problemi rimasti invisibili nel vecchio gestionale: anagrafiche duplicate, codici incoerenti, clienti non più attivi, informazioni incomplete. Il fatto che un dato esista non significa che meriti di essere portato nel nuovo sistema.
I dati vengono poi adattati alla struttura del nuovo gestionale, che raramente coincide con quella del vecchio: bisogna stabilire una corrispondenza per codici cliente, categorie, unità di misura, condizioni di pagamento e tutti gli altri elementi. A questo punto si esegue una prima migrazione di prova — aspettare il giorno del go-live per scoprire se funziona è quasi sempre un errore — e le persone dell'azienda, non solo il fornitore, verificano i risultati: chi lavora in amministrazione riconosce clienti e saldi, chi lavora in magazzino controlla articoli e quantità. Il fornitore può confermare che 25.000 articoli sono stati importati; solo l'azienda sa se sono quelli giusti.
Solo dopo i test si arriva alla migrazione definitiva, con un momento concordato oltre il quale certi dati non cambiano più nel vecchio sistema. Più questa fase è stata preparata bene, meno dovrebbe essere concitata: una buona migrazione non è quella in cui si lavora fino a tardi per salvare il progetto, è quella in cui la maggior parte dei problemi è stata scoperta settimane prima.
La tecnologia raramente è il problema vero. Gli errori nascono quasi sempre da decisioni prese troppo tardi, o mai prese del tutto.
Il primo è voler migrare tutto senza chiedersi perché: sembra la scelta prudente, ma può moltiplicare la complessità inutilmente, portando nel nuovo sistema storico inutilizzato e anagrafiche obsolete. Il secondo è scoprire la qualità dei dati durante il go-live invece che prima: se il database è pieno di duplicati o codifiche incoerenti, è troppo tardi accorgersene a migrazione avvenuta — la pulizia dei dati va considerata parte del progetto, non un imprevisto.
Il terzo, forse il più insidioso, è confondere "importato" con "corretto": un file può caricarsi senza errori tecnici e contenere comunque informazioni sbagliate, e solo un controllo rispetto alla realtà operativa lo rivela. Il quarto è non stabilire chi controlla cosa — "faremo dei test" non è un piano, ogni gruppo di dati importante dovrebbe avere una persona responsabile della validazione. Il quinto è fare test troppo generici: aprire dieci clienti a caso non basta, i casi che mettono davvero alla prova una migrazione sono le eccezioni — condizioni particolari, ordini parzialmente evasi, lotti, resi.
Il sesto è scegliere male il momento del passaggio, ignorando chiusure contabili, inventari o picchi stagionali: non sempre si può scegliere il momento perfetto, ma quasi sempre si può evitare quello peggiore. Il settimo, forse il più pericoloso, è dare per scontato che il fornitore "si occupi di tutto": un fornitore competente può gestire perfettamente la parte tecnica senza conoscere il significato aziendale di ogni dato. "Migrazione dati inclusa" scritto in un preventivo dice troppo poco: prima di partire vale la pena chiarire chi estrae, chi pulisce, chi valida, quante prove sono previste e cosa succede se la migrazione definitiva non supera i controlli.
L'idea di spegnere il vecchio sistema venerdì sera e trovare tutto perfettamente funzionante lunedì mattina è rassicurante, ma raramente realistica così com'è. L'obiettivo raggiungibile non è sempre zero downtime assoluto: è ridurre il rischio e sapere in anticipo cosa succederà durante il passaggio, attraverso migrazioni di prova nelle settimane precedenti, pulizia anticipata dei dati, una data di cut-off chiara e un monitoraggio intensivo nei primi giorni.
In alcuni progetti vecchio e nuovo gestionale restano temporaneamente entrambi attivi — il cosiddetto doppio binario. Ha un costo, ma può ridurre il rischio, a patto di governarlo bene: se le persone continuano a inserire dati indistintamente in entrambi i sistemi, dopo pochi giorni nessuno saprà più quale dei due contiene l'informazione corretta. Una migrazione senza fermare l'azienda richiede soprattutto regole chiare su dove si lavora, prima, durante e dopo il passaggio.
Il numero totale dei record è solo il primo controllo, il più superficiale. Se nel vecchio sistema ci sono 12.438 clienti e nel nuovo ne trovi altrettanti, hai verificato che sono arrivati, non che sono corretti.
Una verifica solida lavora su più livelli: un controllo quantitativo su totali e quantità, uno qualitativo che apre i dati reali e li confronta con quello che l'azienda sa, un controllo di processo che prova a usare il dato migrato in un flusso reale — un cliente importato correttamente deve poter essere inserito in un ordine, un articolo deve comportarsi bene in magazzino — e infine un controllo mirato sulle eccezioni: una decina di casi noti come "complicati" dice spesso più di centinaia di verifiche casuali.
Dipende soprattutto da quantità, complessità e qualità dei dati di partenza. La copia tecnica può richiedere poche ore; il progetto per prepararla e verificarla richiede molto di più.
| Tipo di migrazione | Tempi indicativi |
|---|---|
| Pochi archivi, dati relativamente puliti | 2-4 settimane |
| PMI con più moduli e storico significativo | 4-8 settimane |
| Più sistemi, produzione, dati complessi o molta bonifica | 2-4 mesi o oltre |
Sono ordini di grandezza, non tempi standard, e non coincidono necessariamente con la durata dell'intero progetto di cambio gestionale — che approfondiamo nella guida su quando cambiare gestionale. La parte che richiede più tempo, quasi sempre, non è il caricamento tecnico ma analisi, bonifica, prove e correzioni: promettere una migrazione "in due giorni" può essere tecnicamente vero e allo stesso tempo fuorviante — i dati possono essere caricati in due giorni, essere certi che siano pronti per l'azienda è un'altra cosa.
I principi restano gli stessi: passare a un software SaaS non elimina la pulizia dei dati, la mappatura, i test o la scelta dello storico. Cambia l'infrastruttura, non il fatto che un'anagrafica duplicata resta duplicata anche nel cloud — anzi, il passaggio da sistemi legacy molto datati può richiedere più attenzione, perché le strutture e i formati usati dal vecchio software possono essere molto diversi da quelli della nuova piattaforma. Cloud o on-premise, la domanda resta la stessa: i dati che arrivano nel nuovo sistema sono corretti, completi e davvero utilizzabili?
Prima di dare il via al progetto, vale la pena avere una risposta a questi punti: quali dati vanno migrati e quale storico serve davvero; cosa resterà solo nel vecchio sistema, e per quanto tempo resterà accessibile; chi si occupa di estrazione, bonifica e corrispondenza tra vecchio e nuovo sistema; quante migrazioni di prova sono previste e chi valida ogni gruppo di dati; quali casi particolari verranno testati; quando avverrà il passaggio definitivo e quanto fermo è previsto; come vengono gestiti gli errori dopo il go-live, ed esiste un piano nel caso la migrazione non superi i controlli; sono chiare, infine, le responsabilità del fornitore rispetto a quelle dell'azienda.
Se molte di queste risposte oggi sono ancora indefinite, non significa che il progetto sia sbagliato: significa solo che è ancora presto per considerare la migrazione una fase chiusa.
Un'ultima cosa vale la pena chiarirla. Prima di chiedersi come migrare tutti i dati, bisogna essere sicuri di aver capito perché si sta cambiando sistema e cosa deve fare quello nuovo. Altrimenti si rischia di investire molta energia per replicare esattamente nel nuovo gestionale il modo in cui si lavorava nel vecchio — problemi compresi.
Il cambio può invece essere l'occasione per chiedersi quali dati servono ancora, quali processi possono essere semplificati, quali codifiche non hanno più senso, quali informazioni dovrebbero finalmente essere condivise tra i reparti. Una migrazione ben fatta non porta semplicemente il passato nel nuovo software: porta nel nuovo sistema soltanto ciò che serve per lavorare meglio in futuro. Se sei ancora nella fase in cui stai valutando se sostituire il sistema attuale, può essere utile partire dalla guida su quando cambiare gestionale.
Come funziona la migrazione dati da un gestionale all'altro? Si decide cosa trasferire, si estraggono i dati dal vecchio sistema, si analizzano, si puliscono quando serve e si adattano alla struttura del nuovo software. Prima della migrazione definitiva è consigliabile fare una o più prove e far verificare i risultati alle persone dell'azienda che conoscono davvero i dati.
Quali dati bisogna migrare? Dipende dai processi aziendali: in genere le anagrafiche principali e i dati necessari per continuare a lavorare — clienti, fornitori, articoli, listini, ordini aperti, saldi. Non è necessario migrare automaticamente tutto lo storico disponibile.
Quanto storico conviene migrare? Non c'è una regola valida per tutte le aziende: il criterio dovrebbe essere l'utilità operativa, non la sicurezza psicologica di "avere tutto". Dati consultati raramente possono restare nel vecchio gestionale o in un archivio, invece di essere trasferiti integralmente.
Quanto tempo serve per migrare i dati di un gestionale? Una migrazione semplice richiede poche settimane di preparazione e test; una PMI con più moduli e storico significativo si colloca tipicamente tra 4 e 8 settimane; scenari complessi con più sistemi possono richiedere diversi mesi. Il caricamento tecnico è quasi sempre la parte più rapida.
È possibile cambiare gestionale senza fermare l'azienda? Spesso è possibile ridurre il fermo a un periodo limitato, con migrazioni di prova, un momento di passaggio scelto con cura e regole chiare su dove si lavora durante la transizione. L'obiettivo realistico è la continuità operativa controllata, non necessariamente zero downtime assoluto.
Come si verifica che i dati siano stati migrati correttamente? Non basta controllare che il numero di record corrisponda: servono un controllo sui totali, uno sui dati reali, uno sull'uso effettivo nei processi e uno mirato sui casi particolari. La validazione dovrebbe coinvolgere le persone dell'azienda, non solo il fornitore.
Chi è responsabile della migrazione dati? Il fornitore si occupa in genere della parte tecnica — estrazione, trasformazione, caricamento — ma l'azienda deve partecipare alla scelta di cosa migrare e alla validazione dei risultati. Vale la pena chiarire queste responsabilità prima di iniziare, non durante.
Quanto costa la migrazione dati di un gestionale? Dipende da quantità, qualità e storico dei dati, oltre che dal numero di sistemi coinvolti. Per non ripetere l'argomento, lo trovi approfondito insieme agli altri costi del progetto nella guida su quanto costa cambiare gestionale.
La migrazione è una delle fasi più delicate di un cambio gestionale, ma non va affrontata come un salto nel buio: definire cosa migrare, provare prima del go-live, verificare i dati con le persone giuste e assegnare responsabilità chiare riduce gran parte del rischio. Se stai ancora valutando se cambiare sistema, l'assessment gratuito può aiutarti a mettere a fuoco la complessità prima di entrare nella fase esecutiva. Se invece hai già superato la fase di valutazione, trovi un approfondimento più operativo nella guida di Gest24 su come affrontare il cambio gestionale.
Si decide cosa trasferire, si estraggono i dati dal vecchio sistema, si analizzano, si puliscono quando serve e si adattano alla struttura del nuovo software. Prima della migrazione definitiva è consigliabile fare una o più prove e far verificare i risultati alle persone dell'azienda che conoscono davvero i dati.
Dipende dai processi aziendali: in genere le anagrafiche principali e i dati necessari per continuare a lavorare — clienti, fornitori, articoli, listini, ordini aperti, saldi. Non è necessario migrare automaticamente tutto lo storico disponibile.
Non c'è una regola valida per tutte le aziende: il criterio dovrebbe essere l'utilità operativa, non la sicurezza psicologica di "avere tutto". Dati consultati raramente possono restare nel vecchio gestionale o in un archivio, invece di essere trasferiti integralmente.
Una migrazione semplice richiede poche settimane di preparazione e test; una PMI con più moduli e storico significativo si colloca tipicamente tra 4 e 8 settimane; scenari complessi con più sistemi possono richiedere diversi mesi. Il caricamento tecnico è quasi sempre la parte più rapida.
Spesso è possibile ridurre il fermo a un periodo limitato, con migrazioni di prova, un momento di passaggio scelto con cura e regole chiare su dove si lavora durante la transizione. L'obiettivo realistico è la continuità operativa controllata, non necessariamente zero downtime assoluto.
Non basta controllare che il numero di record corrisponda: servono un controllo sui totali, uno sui dati reali, uno sull'uso effettivo nei processi e uno mirato sui casi particolari. La validazione dovrebbe coinvolgere le persone dell'azienda, non solo il fornitore.
Il fornitore si occupa in genere della parte tecnica — estrazione, trasformazione, caricamento — ma l'azienda deve partecipare alla scelta di cosa migrare e alla validazione dei risultati. Vale la pena chiarire queste responsabilità prima di iniziare, non durante.
Dipende da quantità, qualità e storico dei dati, oltre che dal numero di sistemi coinvolti. Per non ripetere l'argomento, lo trovi approfondito insieme agli altri costi del progetto nella guida su quanto costa cambiare gestionale.
