Migrare un Gestionale Senza Perdere i Dati: Pulizia, Mappatura e Controlli
Perché la Migrazione dei Dati è la Parte più Rischiosa
Quando un'azienda decide di cambiare gestionale, l'attenzione si concentra quasi sempre sulle funzionalità del nuovo software: interfaccia, moduli, integrazioni. Eppure il vero rischio di un progetto di questo tipo sta altrove, nei dati.
Un gestionale in uso da anni contiene migliaia di anagrafiche articolo, clienti, fornitori, listini, giacenze e uno storico di movimenti che serve per analisi, obblighi fiscali e confronti con gli anni precedenti. Se questi dati arrivano nel nuovo sistema incompleti o sbagliati, i problemi emergono nei momenti peggiori: un inventario che non torna, un cliente che non si trova, un report di fine anno con numeri diversi da quelli del vecchio sistema.
Vediamo come affrontare una migrazione in modo ordinato, fase per fase.
Fase 1: Inventario dei Dati
Prima di spostare qualsiasi cosa bisogna sapere cosa c'è. Questo significa censire:
- Entità: articoli, varianti (taglie e colori), clienti, fornitori, negozi, magazzini, listini, promozioni.
- Dati transazionali: documenti di vendita, ordini, DDT, movimenti di magazzino, resi.
- Dati derivati: giacenze, saldi, statistiche. Spesso non vanno migrati ma ricalcolati.
- Dati "nascosti": note libere, campi personalizzati usati in modo creativo, fogli Excel paralleli che di fatto fanno parte del sistema.
Per ognuno conviene annotare il volume, la qualità percepita e chi in azienda ne è il "proprietario", cioè la persona che sa dire se un dato è giusto o sbagliato.
Fase 2: Decidere Cosa Migrare (e Cosa No)
Non tutto merita di essere migrato. Una migrazione è l'occasione perfetta per lasciare indietro ciò che non serve più:
- articoli fuori produzione da molti anni senza giacenza;
- clienti inattivi senza dati necessari per obblighi di legge;
- codici duplicati o creati per errore.
Per lo storico dei movimenti la scelta tipica è tra tre opzioni: migrare tutto, migrare solo gli ultimi anni, oppure lasciare lo storico in un archivio consultabile (ad esempio un Data Warehouse) e partire nel nuovo gestionale con i soli saldi iniziali. L'ultima soluzione è spesso la più pulita.
Fase 3: Profilazione e Pulizia
Questa è la fase più lunga, e quella che fa davvero la differenza. Profilare i dati significa analizzarli in modo sistematico per scoprire problemi prima che diventino errori di importazione.
Con Python e pandas bastano poche righe per avere un primo quadro:
import pandas as pd
articoli = pd.read_csv("export_articoli.csv", sep=";", dtype=str)
# Valori mancanti per colonna
print(articoli.isna().mean().sort_values(ascending=False))
# Codici duplicati
dup = articoli[articoli.duplicated("codice_articolo", keep=False)]
print(f"Codici duplicati: {dup['codice_articolo'].nunique()}")
# Valori distinti di un campo che dovrebbe essere una lista chiusa
print(articoli["stagione"].value_counts(dropna=False))
I problemi più comuni che emergono sono sempre gli stessi:
- Spazi e maiuscole: "ROSSO", "Rosso", "rosso " sembrano uguali a un umano, ma per un database sono tre colori diversi.
- Formati incoerenti: date in formati diversi, decimali con virgola o punto, codici con e senza zeri iniziali.
- Liste chiuse "aperte": un campo stagione che dovrebbe contenere pochi valori e invece ne contiene decine, perché nel tempo ognuno ha scritto a modo suo.
- Riferimenti orfani: movimenti che puntano ad articoli o negozi non più presenti in anagrafica.
La regola d'oro della pulizia è che deve essere ripetibile. Correggere a mano un file Excel funziona una volta; quando bisogna rifare l'estrazione (e succede sempre), tutto il lavoro va perso. Meglio scrivere script di trasformazione che si possono rieseguire su un nuovo export in pochi secondi.
Fase 4: Mappatura
La mappatura definisce, campo per campo, come i dati del vecchio sistema diventano dati del nuovo. È un documento (spesso un foglio di calcolo) con colonne come:
| Sistema origine | Campo origine | Sistema destinazione | Campo destinazione | Regola di trasformazione |
|---|---|---|---|---|
| Vecchio gestionale | COD_ART | Nuovo gestionale | codice_articolo | Trim, maiuscolo, padding a 10 caratteri |
| Vecchio gestionale | STAG | Nuovo gestionale | stagione | Tabella di raccordo (es. "PE24" → "SS2024") |
| Vecchio gestionale | PREZZO | Nuovo gestionale | prezzo_listino | Da stringa con virgola a decimale |
Per i valori codificati servono tabelle di raccordo (dette anche tabelle di decodifica): elenchi che dicono esplicitamente come ogni valore vecchio si traduce in un valore nuovo. Devono essere validate da chi conosce il business, non solo da chi scrive il codice.
Fase 5: Prove di Caricamento
Mai fare la prima importazione il giorno del passaggio definitivo. Servono almeno due o tre migrazioni di prova in un ambiente di test, ognuna seguita da una verifica. Ogni prova fa emergere nuovi casi particolari: un articolo con un carattere speciale nel nome, un cliente con un codice fiscale malformato, una taglia non prevista.
Tra una prova e l'altra si aggiornano gli script di pulizia e le tabelle di raccordo. Quando una prova va a buon fine senza correzioni, si è pronti.
Fase 6: Controlli di Quadratura
Come si dimostra che la migrazione è riuscita? Con i controlli di quadratura: confronti numerici tra vecchio e nuovo sistema che devono dare lo stesso risultato.
- Conteggi: numero di articoli, clienti, fornitori attivi.
- Totali: somma delle giacenze per magazzino, valore del magazzino, saldi clienti e fornitori.
- Campioni: una selezione di record controllati a mano, scelti anche tra i casi "strani".
- Report di business: il fatturato di un mese chiuso, calcolato in entrambi i sistemi, deve coincidere.
-- Confronto giacenze per magazzino tra vecchio e nuovo sistema
SELECT
COALESCE(v.magazzino, n.magazzino) AS magazzino,
v.pezzi AS pezzi_vecchio,
n.pezzi AS pezzi_nuovo,
COALESCE(n.pezzi, 0) - COALESCE(v.pezzi, 0) AS differenza
FROM giacenze_vecchio v
FULL OUTER JOIN giacenze_nuovo n USING (magazzino)
WHERE COALESCE(n.pezzi, 0) <> COALESCE(v.pezzi, 0);
Una query come questa dovrebbe restituire zero righe. Ogni riga è una differenza da spiegare prima del passaggio definitivo.
Fase 7: Il Giorno del Passaggio
Il cutover va pianificato come un'operazione con orari precisi: blocco delle operazioni sul vecchio sistema, estrazione finale, esecuzione degli script, caricamento, quadrature, via libera. In un'azienda con negozi conviene sceglierlo in un periodo di bassa attività e preparare un piano di ritorno al vecchio sistema nel caso qualcosa vada storto.
E dopo il passaggio, il vecchio sistema non va spento subito: tenerlo consultabile in sola lettura per qualche mese salva da molte situazioni imbarazzanti.
Il Ruolo del Fornitore
Il fornitore del nuovo gestionale ha di solito strumenti di importazione e tracciati standard, ma raramente conosce i dati dell'azienda. Il lavoro migliore nasce dalla collaborazione: il fornitore conosce il sistema di destinazione, chi lavora in azienda conosce i dati e le loro stranezze. Avere internamente qualcuno capace di estrarre, pulire e verificare i dati in autonomia riduce tempi, costi e dipendenza dal fornitore.
Conclusioni
Una migrazione di gestionale riuscita non si vede: il giorno dopo il passaggio tutto funziona e i numeri tornano. Per arrivarci servono metodo e pazienza: inventario dei dati, pulizia ripetibile, mappature validate dal business, prove di caricamento e controlli di quadratura rigorosi. È un lavoro poco appariscente, ma è quello che separa un nuovo sistema affidabile da mesi di correzioni manuali.