Torna al blog Business Apps

Checklist per l’importazione dei dati CRM: come testare un CRM self-hosted prima di spostare i record

Un caricamento CSV riuscito non dimostra che una migrazione CRM sia sicura. Usa questa checklist per testare la mappatura dei campi, le regole sui duplicati, la proprietà, le relazioni, la gestione degli errori, le reimportazioni, i permessi e le evidenze di rollback prima di spostare i record di produzione.

Responsabile operativo che esamina i risultati dei test di migrazione CRM, le mappature dei campi di origine e una checklist per l’importazione dei dati

Perché la qualità dell’importazione conta più del successo del primo caricamento

Un pulsante di importazione non è un piano di migrazione. Un primo caricamento può sembrare riuscito mentre crea silenziosamente contatti duplicati, assegna record al team sbagliato, collega una trattativa all’organizzazione errata oppure scarta righe che non superano la convalida.

Valuta la capacità di importazione come un sistema di controllo. Devi sapere cosa l’applicazione crea, aggiorna, rifiuta e segnala; se puoi correggere gli errori; e se una nuova esecuzione è sicura. La domanda pertinente non è “Può importare file CSV?”, ma “Possiamo produrre record affidabili dai nostri dati sorgente reali, in modo ripetibile?”

I diversi CRM implementano questi controlli in modi diversi. Per esempio, EspoCRM documenta le modalità di importazione Solo creazione, Crea e aggiorna e Solo aggiornamento. Le modalità che consentono l’aggiornamento richiedono all’operatore di scegliere i campi che identificano un record esistente. Questa scelta è una decisione di governance dei dati, non un’impostazione tecnica predefinita. Consulta la [documentazione sull’importazione di EspoCRM](https://docs.espocrm.com/administration/import/).

  • Non approvare un CRM basandoti soltanto su un file demo privo di errori.
  • Testa con gli stessi tipi di dati, le stesse incoerenze e le stesse relazioni presenti nell’esportazione di produzione.
  • Registra ogni decisione di configurazione usata in ciascuna esecuzione di test.
  • Definisci il successo come record accurati e utilizzabili, con eccezioni spiegabili.
Perché la qualità dell’importazione conta più del successo del primo caricamento

Inizia con un inventario dei dati sorgente

Crea un inventario prima di mappare una sola colonna. I fogli di calcolo e i CRM in uscita spesso conservano informazioni correlate in schede, moduli, note in testo libero e archivi di file distinti. Se l’inventario conta solo i contatti, la migrazione può apparire completa pur perdendo il contesto commerciale, la proprietà dei record o la cronologia operativa.

Per ogni tabella o esportazione sorgente, identifica lo scopo aziendale, il numero di record, l’identificatore primario, il proprietario attuale, il responsabile dei dati, l’entità di destinazione e le dipendenze relazionali. Indica quali dati sono essenziali dal primo giorno e quali possono essere rimandati o archiviati fuori dal CRM.

Includi le attività solo dopo aver confermato che il modello di destinazione supporta i record e i pannelli pertinenti. In EspoCRM, per esempio, i pannelli Attività, Cronologia e Attività pianificate disponibili dipendono dal tipo di entità configurato. Non presumere che ogni entità personalizzata esponga le stesse informazioni correlate di un record persona o organizzazione. Consulta la [documentazione di EspoCRM Entity Manager](https://docs.espocrm.com/administration/entity-manager/).

  • Record principali: persone, organizzazioni, lead, trattative o entità equivalenti.
  • Relazioni: contatto-organizzazione, trattativa-contatto, record padre-figlio e qualsiasi collegamento molti-a-molti.
  • Contesto operativo: note, chiamate, riunioni, attività, e-mail e cronologia, ove necessario.
  • File: allegati, documenti, percorsi dei file e collegamenti a repository esterni.
  • Dati di configurazione: campi personalizzati, valori enumerati, tag, team, proprietari e stati.
  • Identificatori sorgente: ID dal foglio di calcolo o dal sistema precedente per ogni entità.
Inizia con un inventario dei dati sorgente

Definisci il modello dati di destinazione prima di mappare i campi

La mappatura dei campi deve seguire un modello di destinazione deliberatamente concordato, non il desiderio di conservare ogni colonna sorgente. Decidi quali entità di destinazione esisteranno, quali campi sono obbligatori, quali sono personalizzati, quali valori sono elenchi controllati e quali informazioni devono rimanere fuori dal CRM.

Per ogni campo sorgente, seleziona un esito: mappare direttamente, trasformare, suddividere, combinare, inserire in un campo personalizzato controllato, conservare in un archivio oppure escludere. Documenta la motivazione. Una colonna “stato” in testo libero, per esempio, non dovrebbe essere mappata in un campo stato con valori limitati finché i suoi diversi valori sorgente non siano stati esaminati e normalizzati.

Verifica l’idoneità all’importazione a livello di campo. La documentazione di Studio di SuiteCRM descrive la configurazione di campi e relazioni, incluso se i campi sono consentiti, non consentiti o obbligatori per le importazioni guidate da Import Wizard. Identifica inoltre il tipo di campo, l’auditing e le impostazioni di unione dei duplicati come proprietà del campo. I controlli esatti variano per CRM, quindi convalida l’applicazione di destinazione invece di dedurli da un altro prodotto. Consulta la [documentazione di SuiteCRM Studio](https://pre-release.docs.suitecrm.com/admin/administration-panel/studio/).

  • Entità e nome del campo di destinazione.
  • Tabella, colonna e tipo di dati sorgente.
  • Regola di trasformazione e valori consentiti.
  • Stato obbligatorio, facoltativo, sensibile o di sola lettura.
  • Idoneità all’importazione e comportamento predefinito.
  • Responsabile della decisione di mappatura e del risultato del test.

Crea un’importazione di test rappresentativa invece di usare un campione ripulito

Un campione curato dimostra soltanto che i dati curati possono essere importati. Crea un piccolo set di dati di test rappresentativo a partire da copie di record reali, proteggendo i valori sensibili secondo necessità. Conserva i problemi effettivamente presenti nei dati di produzione affinché il test mostri come si comporta l’importatore.

Includi sia record ordinari sia casi limite deliberati. Testa valori obbligatori vuoti, valori incompatibili con gli elenchi controllati, nomi duplicati, indirizzi e-mail duplicati, ID sorgente ripetuti, formati telefonici incoerenti, campi multivalore, punteggiatura, caratteri non ASCII e date scritte in più di un formato.

Gli errori di convalida sono evidenze preziose. EspoCRM documenta che una riga che non supera la convalida non crea un record, citando tra gli esempi valori enum incompatibili e valori vuoti per un enum non vuoto. Il test deve confermare il comportamento equivalente nel CRM che stai valutando, incluso ciò che accade ai campi validi in una riga parzialmente non valida. Consulta la [documentazione sull’importazione di EspoCRM](https://docs.espocrm.com/administration/import/).

  • Usa un numero noto di record per ogni file di test.
  • Etichetta i record di test affinché possano essere trovati e ispezionati in seguito.
  • Conserva una copia non modificata dell’estratto di test originale.
  • Includi righe certamente valide, certamente non valide e intenzionalmente ambigue.
  • Non sostituire i valori di produzione con segnaposto irrealisticamente uniformi.

Testa le decisioni che creano dati CRM errati: duplicati, valori mancanti, formattazione e proprietà

Il controllo dei duplicati parte da una policy di corrispondenza esplicita. Decidi quali identificatori sorgente sono autorevoli, se l’e-mail è sufficientemente univoca per il tuo caso d’uso e come il CRM deve trattare una corrispondenza su un campo ma non su un altro. Registra gli esatti campi di corrispondenza selezionati per ogni esecuzione.

Gli identificatori sorgente stabili sono particolarmente importanti per i cicli di correzione. Odoo documenta che External ID coerenti possono supportare importazioni ripetute senza creare duplicati, mentre la modifica o la rimozione di un External ID può produrre un nuovo record anziché un aggiornamento. Che il CRM scelto usi External ID o un altro meccanismo di identificazione, verifica che il suo identificatore sopravviva alla reimportazione esattamente come previsto. Consulta la [documentazione di Odoo su esportazione e importazione](https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html).

Non fidarti del rilevamento automatico delle date. Odoo osserva che i formati data possono essere riconosciuti erroneamente, incluse le inversioni giorno-mese, e raccomanda di verificare o impostare un formato ISO 8601. Inserisci date ambigue come 03/04/2024 nel file di test e ispeziona il valore salvato, non soltanto l’anteprima dell’importazione.

La proprietà richiede lo stesso livello di attenzione. EspoCRM può applicare valori predefiniti, inclusi Utente assegnato e Team, ai record nuovi e aggiornati durante l’importazione. Testa se il proprietario sorgente viene mantenuto, tradotto, sostituito da un valore predefinito o lasciato non impostato. Quindi decidi quale comportamento è accettabile per ogni entità. Consulta la [documentazione sull’importazione di EspoCRM](https://docs.espocrm.com/administration/import/).

  • Crea un record con un ID sorgente esistente e dati non chiave modificati; testa il percorso di aggiornamento previsto.
  • Crea due record con nomi simili ma ID diversi; assicurati che non vengano uniti accidentalmente.
  • Testa campi vuoti in un file di aggiornamento per capire se cancellano valori esistenti, vengono ignorati o non superano la convalida.
  • Testa formati di data, numero, valuta, telefono e selezione multipla.
  • Testa un record il cui proprietario originale non esiste più nella destinazione.
  • Ispeziona i valori di proprietario e team dopo esecuzioni sia di creazione sia di aggiornamento.

Verifica relazioni e cronologia: contatti, organizzazioni, trattative, note, attività e allegati

L’accuratezza delle relazioni è spesso ciò che distingue un CRM utile da un elenco di record scollegati. Crea casi di test in cui un’organizzazione ha più contatti, una trattativa ha più persone correlate e i record condividono nomi visualizzati simili o identici. Controlla ogni relazione da entrambi i lati nell’interfaccia di destinazione.

Importa le entità padre prima delle entità figlie quando la relazione dipende da record importati in precedenza. SuiteCRM indica di importare gli Account prima dei Contatti correlati affinché la relazione possa essere stabilita. Analogamente, Odoo documenta l’importazione prima degli oggetti correlati quando le relazioni vengono ricreate tramite External ID. Consulta la [documentazione di SuiteCRM sulla gestione dei record](https://docs.suitecrm.com/8.x/user/core-concepts/record-management/) e la [documentazione di Odoo su esportazione e importazione](https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html).

Evita di basarti sui nomi per la corrispondenza delle relazioni quando è possibile un’ambiguità. Odoo avverte che, quando più record correlati hanno lo stesso nome, i dati possono collegarsi al primo record corrispondente. Usa identificatori stabili per i campi relazionali quando la destinazione li supporta, e dimostra il risultato con record di test intenzionalmente ambigui.

Gli allegati e la cronologia delle attività meritano test di accettazione separati. Conferma se i file vengono importati, collegati, ignorati oppure richiedono una procedura separata specifica del prodotto. Non presumere che l’importatore CSV usato per i record principali importi anche allegati, note, attività o cronologia. Per ogni procedura supportata, conferma che date, autori, record padre e permessi siano appropriati.

  • Importa organizzazioni o account prima dei contatti correlati.
  • Importa trattative o casi padre prima delle note e attività dipendenti, quando il modello lo richiede.
  • Usa ID sorgente per collegare i record invece dei nomi visualizzati, ove possibile.
  • Ispeziona il numero di relazioni e i singoli collegamenti nell’applicazione.
  • Apri allegati di esempio e verifica l’associazione al record prevista.
  • Controlla date, creatori, assegnatari e visibilità delle attività.

Controlla come l’applicazione segnala i record rifiutati o modificati

Un importatore che segnala soltanto un totale finale è difficile da usare in sicurezza. Richiedi evidenze per ogni riga rifiutata: la riga sorgente o il suo identificatore, il motivo dell’errore e i valori forniti. Richiedi inoltre un modo per distinguere i record appena creati da aggiornamenti e righe ignorate.

EspoCRM fornisce un pannello Errori che include il motivo dell’errore, l’indice della riga e i valori della riga, e può esportare in CSV le righe non riuscite per la correzione e la reimportazione. La documentazione di SuiteCRM descrive analogamente una scheda Errori per la revisione e la correzione prima di rieseguire un’importazione. Considerali esempi utili delle evidenze da cercare, non come presupposto che ogni CRM esponga report identici. Consulta la [documentazione sull’importazione di EspoCRM](https://docs.espocrm.com/administration/import/) e la [documentazione di SuiteCRM sulla gestione dei record](https://docs.suitecrm.com/8.x/user/core-concepts/record-management/).

Esegui un test contenente record validi, record non validi e candidati all’aggiornamento. Riconcilia il conteggio sorgente con gli esiti di creazione, aggiornamento, rifiuto e salto. Qualsiasi differenza non spiegata rappresenta un criterio di accettazione non superato.

  • Puoi esportare le righe non riuscite per correggerle?
  • Ogni errore identifica una riga sorgente o un ID sorgente stabile?
  • Il report spiega l’errore in termini operativi?
  • Puoi distinguere creazioni, aggiornamenti, rifiuti e salti?
  • Puoi salvare le impostazioni di mappatura e controllo dei duplicati per un’esecuzione ripetibile?
  • Puoi ispezionare i record risultanti direttamente dal report di importazione?

Testa correzione e reimportazione senza moltiplicare i record né sovrascrivere involontariamente dati affidabili

Il test di importazione più importante è di solito il secondo. Correggi un insieme limitato di righe rifiutate, quindi reimporta il file corretto usando la modalità di aggiornamento e le regole di corrispondenza previste. Conferma che i record corretti siano creati o aggiornati una sola volta, che i record già importati con successo non siano duplicati e che i campi non correlati rimangano affidabili.

Separa il comportamento di creazione da quello di aggiornamento nei criteri di accettazione. In EspoCRM, Solo creazione crea record, mentre Crea e aggiorna e Solo aggiornamento usano i campi di corrispondenza selezionati per trovare record da aggiornare. Un team di produzione deve sapere quale modalità userà per il caricamento iniziale, la correzione degli errori e i successivi aggiornamenti incrementali. Consulta la [documentazione sull’importazione di EspoCRM](https://docs.espocrm.com/administration/import/).

Testa con attenzione i valori vuoti e modificati. Una reimportazione può sovrascrivere le informazioni modificate dopo la prima importazione, a seconda della modalità e delle mappature selezionate. Stabilisci una finestra di cutover, identifica il sistema di riferimento per ogni campo durante la migrazione e definisci se le modifiche successive all’importazione sono protette, sovrascritte o riconciliate manualmente.

Conserva l’ID sorgente stabile in ogni file di correzione. Non modificarlo semplicemente per far sparire un errore: ciò può trasformare un aggiornamento previsto in un nuovo record. Odoo documenta questo rischio per gli External ID. Consulta la [documentazione di Odoo su esportazione e importazione](https://www.odoo.com/documentation/18.0/applications/essentials/export_import_data.html).

  • Esegui un’importazione iniziale e registra gli ID creati e gli ID sorgente.
  • Correggi soltanto le righe non riuscite e conserva i loro identificatori originali.
  • Reimporta e confronta il numero di record prima e dopo.
  • Testa deliberatamente un valore modificato su un record esistente.
  • Testa deliberatamente un valore vuoto su un record esistente.
  • Verifica se i campi modificati nel CRM dopo il primo caricamento vengono mantenuti o sovrascritti come previsto.

Domande frequenti

Qual è il test minimo sicuro per un’importazione di dati CRM?

Usa un sottoinsieme rappresentativo che includa tipi di entità reali, relazioni, campi personalizzati, candidati duplicati, valori mancanti, valori non validi negli elenchi controllati, formati data diversi, casi di proprietà e righe di errore corrette. Quindi riconcilia le righe sorgente con creazioni, aggiornamenti, rifiuti e salti.

Devo importare i contatti prima delle organizzazioni o degli account?

In genere importa prima l’entità padre quando i contatti devono esservi collegati durante l’importazione. La documentazione di SuiteCRM cita gli Account prima dei Contatti correlati come esempio. Testa l’ordine delle dipendenze richiesto dal CRM scelto e dal relativo modello di relazioni.

Come posso prevenire i duplicati quando reimporto dati CRM corretti?

Conserva un identificatore sorgente stabile per ogni entità e usa una regola di corrispondenza documentata. Testa l’esatta modalità di aggiornamento e i campi di corrispondenza usati dal CRM di destinazione. Non modificare né rimuovere l’identificatore nei file di correzione, perché ciò può trasformare un aggiornamento previsto in un nuovo record.

Un rollback dell’importazione può sostituire un backup completo?

No. Le funzioni di ripristino a livello di importazione potrebbero non annullare gli aggiornamenti apportati ai record esistenti. EspoCRM, per esempio, documenta che Revert Import rimuove i record importati ma non annulla gli aggiornamenti causati dall’importazione. Esegui e verifica un backup completo prima della migrazione di produzione, ed esercitati nel ripristino prima di farvi affidamento. Per EspoCRM, un backup completo include sia i file dell’applicazione sia un dump del database; consulta la [documentazione su backup e ripristino](https://docs.espocrm.com/administration/backup-and-restore/).

Perché testare le importazioni con un account non amministratore?

L’operatore di produzione potrebbe avere diritti di accesso diversi da quelli di un amministratore. In EspoCRM, gli utenti regolari richiedono l’accesso Import e sono soggetti ai permessi del ruolo, mentre gli amministratori hanno accesso completo al sistema. Testa l’importazione, la riassegnazione della proprietà e la visibilità dei campi sensibili usando il ruolo effettivamente previsto. Consulta la [documentazione sull’importazione di EspoCRM](https://docs.espocrm.com/administration/import/) e la [documentazione sulla gestione dei ruoli](https://docs.espocrm.com/administration/roles-management/).

Fonti e approfondimenti

  1. Import — EspoCRM Documentation
  2. Backup and Restore — EspoCRM Documentation
  3. Role Management — EspoCRM Documentation
  4. Entity Manager — EspoCRM Documentation
  5. Export and import data — Odoo Documentation
  6. Record Management — SuiteCRM Documentation
  7. Studio — SuiteCRM Documentation
  8. Volumes — Docker Docs