--- title: "Come migra i contatti da un altro sistema senza perdere dati senza accorgersene?" blueprint: 005 slug: contact-migration-without-data-loss category: Migrazione dei dati published: 2026-09-23 revised: 2026-09-23 platform: Coevera CRM (formerly Pipeliner CRM) canonical: https://blueprints.coevera.com/it/blueprints/contact-migration-without-data-loss/ language: it translation_of: https://blueprints.coevera.com/blueprints/contact-migration-without-data-loss/ author: Lucia Schmidt publisher: Coevera customer_data: none --- # Come migra i contatti da un altro sistema senza perdere dati senza accorgersene? **Risposta breve.** Gli errori di migrazione sono **silenziosi per impostazione predefinita**. I problemi strutturali — una riga irregolare, un'email malformata — vengono intercettati. Quelli sui valori no: un valore di menu a tendina senza un'opzione corrispondente nella destinazione arriva **vuoto**, senza alcun errore. Secondo il conteggio su un export prima dell'importazione, un solo campo avrebbe svuotato **579 record su 3.432, il 17%**. Due regole fanno gran parte del lavoro. **Faccia l'inventario dell'export completo, mai di un campione** — un campione di 71 righe mostrava 59 colonne vuote dove il file completo ne aveva 26, e un campo che risultava popolato allo 0% lo era in realtà al 100%. E **riconcili l'insieme di valori di ogni menu a tendina con le opzioni della destinazione prima di importare**, non dopo. ## 01 · Il problema di business Un'organizzazione sta trasferendo il proprio database di contatti da un sistema al CRM. A prima vista è un esercizio di mappatura: allineare le colonne, avviare l'importazione, finito entro pranzo. Che cosa deve ottenere in realtà: - **Completezza** — ogni colonna che contiene dati reali finisce da qualche parte, oppure viene scartata per una decisione esplicita e non per caso; - **Attribuzione** — ogni record arriva con il proprietario giusto, perché la proprietà determina la visibilità e la reportistica; - **Integrità dei consensi** — i flag di consenso al marketing e GDPR arrivano intatti, perché sbagliarli ha conseguenze legali, non soltanto fastidiose; - **Idempotenza** — l'importazione può essere eseguita due volte senza produrre due copie di tutto, perché *verrà* eseguita due volte; - **Provenienza** — anche dopo si riesce a capire da dove proviene ogni record e quando è stato creato in origine. L'export di questa implementazione era largo 91 colonne e profondo 3.432 record. Era strutturalmente pulito — nessuna riga irregolare, nessun indirizzo email malformato o vuoto, nessun identificatore di origine duplicato. Ogni problema degno di nota si nascondeva all'interno di dati per il resto validi. ## 02 · Perché l'approccio ovvio non funziona ### Progettare lo schema di destinazione a partire da un export di esempio > **Il campione mente, e mente in entrambe le direzioni.** Un campione di 71 righe dal sistema di > origine mostrava **59 colonne completamente vuote**. L'export completo di 3.432 righe ne > mostrava soltanto **26** davvero vuote. > > Una colonna risultava **popolata allo 0%** nel campione e **popolata al 100%** — tutti i 3.432 > record — nel file completo. Se si costruisce a partire dal campione, quella colonna non ha > alcuna destinazione. La ragione è banale e vale in generale: un campione è di solito una fetta recente, e i record recenti usano campi diversi da quelli storici. Blocchi di indirizzo, campi del programma partner, attribuzione delle campagne e dati di segnalazione erano tutti plausibilmente popolati sui record più vecchi e semplicemente assenti in una finestra di quattro settimane. La stessa trappola ha un risvolto più insidioso. Nel campione ogni indirizzo email era univoco — il che suggeriva l'email come chiave di deduplicazione naturale. Nell'export completo c'erano **indirizzi email duplicati su 10 record**. Una strategia di deduplicazione scelta in base al campione avrebbe unito silenziosamente persone distinte. ### Trattare l'export come un unico elenco omogeneo Lo è raramente. Questo export conteneva diverse coorti distinte di contatti — registrazioni da una proprietà di contenuti, iscrizioni a prove del prodotto, prospect del marketing e una manciata di richieste isolate — e **lo schema di riempimento seguiva la coorte, non il contatto**. Ogni coorte popolava un sottoinsieme diverso di colonne, e ognuna aveva il proprio proprietario. La conseguenza riguarda la progettazione, non i dati: **non costruisca un unico modulo piatto**. Diciotto nuovi campi distribuiti su tre coorti significano che un unico modulo combinato risulta vuoto per circa il 70% su ogni record, a qualunque coorte appartenga. ### Mappare le colonne e premere importa È qui che avviene la perdita silenziosa, e merita una sezione a sé. ## 03 · L'errore silenzioso — i valori dei menu a tendina > **I campi a menu a tendina si importano tramite l'identificatore dell'opzione, non tramite > l'etichetta.** Un valore di origine senza un'opzione corrispondente nella destinazione non > genera errori, non avvisa e non interrompe l'importazione. Il campo arriva **vuoto**. > > **La fonte, e la lacuna che contiene.** Il centro assistenza di Coevera, [Importing data into > Coevera — tips on data > preparation](https://help.coevera.com/en/articles/4190964-importing-data-into-coevera-tips-on-data-preparation), > enuncia il requisito: «non sarà possibile importare record che contengono valori non > corrispondenti a quelli presenti in Coevera», e indica di creare prima le opzioni mancanti. Ciò > che non dice è che cosa accade davvero quando si salta quel passaggio — il record viene > importato, e solo quel campo viene scartato. Quella differenza è l'intero contenuto di questa > sezione. Misurato su questo export, prima di qualsiasi correzione: | Campo | Resterebbe vuoto | Causa | |---|---|---| | Stato del contatto | **579 su 3.432 · 17%** | Cinque valori presenti nell'origine non avevano alcuna opzione creata — tra cui uno stato presente su 335 record e un altro su 128. | | Livello del prodotto | **117 su 418 · 28%** | Per lo più **varianti di maiuscole e minuscole** di opzioni esistenti, più due valori numerici del tutto privi di senso. | | Fascia di dimensione del team | 39 | Un'opzione mancante, più la **corruzione in date da parte del foglio di calcolo**. | | Versione del prodotto | 1 | Un'unica variante di maiuscole e minuscole. | ### Tre cause distinte, tre soluzioni diverse - **Opzioni mai create.** Il caso ovvio, e il più facile da correggere una volta contati i valori distinti presenti nell'origine, anziché dedurre l'insieme dalla documentazione. - **Varianti di maiuscole e minuscole.** Lo stesso valore che arriva sia come `Unlimited` sia come `unlimited`. Non sono nuove opzioni — crearle frammenterebbe la reportistica. Le normalizzi invece al momento dell'importazione. - **Corruzione da foglio di calcolo.** Valori di intervallo come `2-4` e `5-10` erano stati convertiti silenziosamente in date da un software per fogli di calcolo a monte, arrivando come `4-Feb` e `10-May`. Non è colpa del sistema di origine né del CRM; è ciò che accade quando un CSV passa attraverso un foglio di calcolo. Lo si individua contando i valori distinti e leggendo l'elenco con i propri occhi. Tutte e tre sono invisibili a posteriori. Un campo vuoto ha esattamente lo stesso aspetto di un campo che era legittimamente vuoto nell'origine. ## 04 · Configurazione a livello di campo Delle 91 colonne di origine, il risultato è stato: 8 mappate su campi standard esistenti, 18 nuovi campi personalizzati, e le restanti o davvero vuote o scartate esplicitamente. ### Che cosa scartare deliberatamente Alcune colonne popolate non hanno alcun valore, e individuarle fa parte del lavoro: - **Costanti.** Una colonna che contiene lo stesso valore su ogni riga è di solito l'identificatore del tenant del sistema di origine o un discriminatore di tipo implicito nella mappatura. Non porta alcuna informazione sul singolo record. - **Artefatti dell'export.** Una colonna era identica byte per byte all'identificatore del record ovunque fosse popolata, e vuota altrove — un duplicato prodotto dall'export, non un campo che qualcuno manteneva. - **Codici senza tabella di decodifica.** I codici numerici non hanno significato senza la legenda, e spesso la legenda non è esportabile. Meglio scartarli che importare numeri che nessuno sa interpretare. ### La normalizzazione che l'importazione deve fare | Sintomo nell'export | Correzione prima dell'importazione | |---|---| | Booleani esportati come `1.00` / `0.00` | Convertirli in true/false | | Identificatori interi esportati come `104857.00` | Rimuovere il suffisso decimale, altrimenti vengono importati come testo con una coda spuria | | Paese come codici ISO-2 in minuscolo | Espanderli nei nomi che il CRM si aspetta | | Numeri di telefono con spaziature e parentesi incoerenti | Normalizzarli | | Varianti di maiuscole e minuscole nei menu a tendina | Ricondurle all'opzione canonica — non creare una seconda opzione | ### Tag I tag sono un campo multivalore, quindi un contatto conserva tutti i suoi tag di origine — ma il **vocabolario dei tag deve esistere nello spazio prima che i contatti vengano importati**. Tre dettagli di questo export che vale la pena controllare nel suo: verifichi che il delimitatore sia davvero sicuro (qui nessun valore conteneva una virgola non seguita da uno spazio); faccia attenzione agli apostrofi tipografici, che rendono distinti due tag visivamente identici; e si aspetti valori spazzatura — un tag privo di significato compariva su 182 record. ### Presenza nel modulo > **Ogni nuovo campo deve essere inserito nel modulo, non soltanto creato.** Un campo che esiste > nello schema ma è assente dal modulo è inerte in Coevera — veda [Blueprint > 002](https://blueprints.coevera.com/it/blueprints/ai-fields-read-documents/), dove lo stesso > vincolo disattiva silenziosamente i campi IA e i campi calcolati. > > Poiché l'export ha la forma di coorti, suddivida il modulo in sezioni per coorte anziché > elencare diciotto campi in un unico blocco. Tenga presente che le colonne dei moduli di Coevera > devono usare una delle cinque suddivisioni valide in quattro unità — `[4]`, `[2,2]`, `[1,1,2]`, > `[2,1,1]`, `[1,1,1,1]`. ## 05 · La sequenza di importazione L'ordine conta, perché diversi passaggi sono prerequisiti del successivo. 1. **Fare l'inventario dell'export completo**Ogni colonna: conteggio dei valori popolati, conteggio dei valori distinti e i valori distinti effettivi per tutto ciò che diventerà un menu a tendina. Non il campione — l'intero file. 2. **Suddividere in coorti**Raggruppare le righe per schema di riempimento. Questo guida la progettazione del modulo e spesso rivela che un proprietario corrisponde a una coorte. 3. **Decidere esplicitamente il destino di ogni colonna**Campo standard, nuovo campo personalizzato, oppure scartata con una ragione dichiarata. Una colonna senza decisione è una colonna che andrà persa. 4. **Riconciliare le opzioni dei menu a tendina**Per ogni menu a tendina, confrontare i valori distinti dell'origine con le opzioni della destinazione. Creare ciò che manca davvero; normalizzare le varianti di maiuscole e minuscole; correggere la corruzione alla fonte. 5. **Creare il vocabolario dei tag**Prima di importare qualsiasi contatto, altrimenti i tag non vengono associati, senza alcun avviso. 6. **Creare i campi e inserirli nel modulo**Entrambe le cose, nella stessa modifica. 7. **Scrivere un record reale dall'inizio alla fine**Una riga effettiva dell'export, non dati sintetici. Rileggerlo e confrontare ogni campo. Poi eliminarlo. 8. **Importare, poi verificare tramite il tasso di riempimento**Confrontare il tasso di riempimento di ogni campo dopo l'importazione con il conteggio di riempimento dell'origine. Una discrepanza è l'unico segnale disponibile. Il passaggio 7 è quello che si tende a saltare ed è quello che intercetta la maggior parte dei problemi. I dati di test sintetici sono puliti per costruzione; una riga reale porta con sé le varianti di maiuscole e minuscole, i suffissi decimali e gli apostrofi tipografici. ## 06 · Limiti e compromessi ### I campi gestiti dal sistema non possono essere importati La data e ora di creazione del record è impostata dalla piattaforma. Non è possibile importarvi la data di creazione del sistema di origine, quindi per conservare la provenienza serve un **campo data personalizzato separato** — lo decida fin dall'inizio, perché in seguito non è recuperabile senza una nuova importazione. Anche la data dell'ultimo contatto è gestita dal CRM e non è importabile. In questo export quella colonna era popolata su **tutti i 3.432 record**, e senza un quindicesimo campo personalizzato non avrebbe avuto alcuna destinazione. ### I campi URL riscrivono un dominio in scrittura > **Nei valori scritti in un campo di tipo `url` la stringa `pipelinersales.com` viene sostituita > con `coevera.com` al momento del salvataggio.** Verificato in uno spazio in produzione il > 2026-09-03 con un controllo appaiato: lo stesso valore scritto contemporaneamente in un campo > `url` e in un campo di testo con una sola richiesta è tornato riscritto nel primo e alla lettera > nel secondo. > > È una sostituzione di sottostringa applicata in qualunque punto del valore, **anche all'interno > delle query string** — per cui un parametro di tracciamento o di reindirizzamento che fa > riferimento al vecchio dominio viene reindirizzato silenziosamente. Schema, sottodominio e > percorso vengono conservati, e i domini non correlati restano intatti. Nella migrazione > originale questo ha riguardato 28 valori URL su 29. Se i suoi dati di origine contengono URL di > questo tipo e le servono alla lettera, usi un semplice campo di testo anziché un campo `url`. ### Il proprietario è obbligatorio, e i nomi non sono chiavi Ogni record richiede un proprietario valido, quindi gli account utente devono esistere nella destinazione prima che l'importazione venga eseguita. Mappi sull'**indirizzo email dell'utente di origine, non sul suo nome visualizzato** — in questo export il nome di un commerciale corrispondeva a due indirizzi email diversi, 2.432 record sull'uno e 15 sull'altro. Mappare sul nome avrebbe annullato una distinzione reale. ### Scelga deliberatamente la chiave di deduplicazione Importi l'identificatore di record proprio del sistema di origine in un campo personalizzato dedicato. È univoco nell'origine, stabile tra un export e l'altro, e rende idempotente un'importazione ripetuta. L'email è la scelta intuitiva ed è pericolosa — questo database conteneva indirizzi davvero duplicati che un campione non aveva rivelato. ### Che cosa l'export non le dirà - **L'assenza di un valore non è prova di assenza nel sistema di origine.** Ogni stato di consenso in questo export era *Subscribed* — il che quasi certamente significa che l'export era filtrato sugli iscritti, non che nessuno si fosse disiscritto. Importarlo come se fosse il quadro completo avrebbe scartato silenziosamente l'elenco delle disiscrizioni, che è l'unico errore di tutto questo articolo con conseguenze legali. - **I veri problemi di qualità dei dati viaggiano insieme ai dati.** Questo export conteneva record senza nome, senza cognome, o senza entrambi. La migrazione non è il momento di correggerli, ma è il momento di contarli. ## 07 · Verifica La modalità di errore è il silenzio, quindi la verifica non può essere «l'importazione ha segnalato un successo?» — l'ha segnalato. - **Conteggio dei campi prima e dopo.** L'entità Contact è passata da 83 campi a 98. Un semplice conteggio conferma che ogni campo previsto è stato effettivamente creato, e intercetta quello che silenziosamente non lo è stato. - **Ogni opzione dei menu a tendina confermata come presente, con nomi e ordinamento corretti** — prima di importare, non dopo. - **Un record reale scritto dall'inizio alla fine**, usando una riga effettiva dell'export, riletto tramite *entrambe* le API, REST e admin, e confrontato campo per campo. È questo che ha fatto emergere la riscrittura degli URL: ogni altro valore è stato salvato esattamente, e uno no. Il record di test è stato poi eliminato. - **Tasso di riempimento per campo dopo l'importazione, confrontato con il conteggio di riempimento dell'origine.** È il controllo che intercetta su larga scala lo svuotamento silenzioso dei menu a tendina — un campo che dovrebbe avere 3.432 valori popolati e ne mostra 2.853 ha perso 579 record, e nient'altro glielo dirà. - **Univocità della chiave di deduplicazione verificata di nuovo nella destinazione**, non data per scontata a partire dall'origine. - **Associazione dei tag controllata a campione** su contatti che dovrebbero averne diversi, poiché i tag non vengono associati, senza avvisi, se il vocabolario era incompleto. **Che cosa segnalerebbe una regressione:** un campo a menu a tendina il cui conteggio di valori popolati cala dopo una nuova importazione; record duplicati che compaiono a una seconda esecuzione, il che significa che la chiave di deduplicazione non viene abbinata; URL nella destinazione diversi da quelli dell'origine; oppure un flag di consenso con una distribuzione diversa da quella dell'export. ## Blueprint correlati - [Blueprint 003 — Come modella qualcosa per cui il suo CRM non ha un oggetto?](https://blueprints.coevera.com/it/blueprints/where-should-this-data-live/) — quali delle novantuno colonne meritano davvero un campo, deciso prima che una qualsiasi di esse venga mappata. - [Blueprint 013 — Come aggiunge al suo sito un modulo di contatto che scrive direttamente nel suo CRM?](https://blueprints.coevera.com/it/blueprints/website-contact-form-into-crm/) — l'upsert che impedisce a un modulo di ricreare le persone che ha appena migrato. - [Blueprint 002 — Come fa in modo che l'IA legga un documento e compili i campi del CRM in modo affidabile?](https://blueprints.coevera.com/it/blueprints/ai-fields-read-documents/) — i tipi di campo che possono essere compilati automaticamente e quelli che non possono esserlo — lo stesso vincolo dei menu a tendina, visto dall'altra estremità. - [Blueprint 016 — Come concatena sequenze di email in modo che ciò che fa un potenziale cliente decida cosa succede dopo?](https://blueprints.coevera.com/it/blueprints/chaining-email-sequences-on-engagement/) — che cosa fa un elenco non validato al primo contatto. ## Domande frequenti ### Perché le importazioni nel CRM perdono dati senza avvisare invece di fallire? Perché gli errori più comuni riguardano i valori, non la struttura. Un campo a menu a tendina si importa tramite l'identificatore dell'opzione, quindi un valore di origine senza un'opzione corrispondente nella destinazione non genera alcun errore: il campo resta semplicemente vuoto. In una migrazione, un conteggio sull'export prima dell'importazione ha trovato 579 record su 3.432, circa il 17 per cento, che sarebbero stati svuotati su un solo campo di stato. Le cause comprendevano opzioni mai create, varianti di maiuscole e minuscole di opzioni esistenti, valori spazzatura e software per fogli di calcolo che convertiva silenziosamente in date valori di intervallo come 2-4. ### Si può progettare lo schema del CRM di destinazione a partire da un export di esempio? No, ed è l'errore più costoso che si possa commettere. In una migrazione un campione di 71 righe mostrava 59 colonne completamente vuote; l'export completo di 3.432 righe ne mostrava soltanto 26 davvero vuote. Un campo risultava popolato allo zero per cento nel campione e al cento per cento nel file completo. Gli indirizzi email erano univoci nel campione e contenevano duplicati nell'export completo, il che rende inutilizzabile l'email come chiave di deduplicazione. Faccia sempre l'inventario dell'export completo prima di progettare i campi. ### Quali campi del CRM non possono essere popolati da un'importazione? I campi gestiti dal sistema. In Coevera la data e ora di creazione del record è impostata dalla piattaforma e non può essere fornita, quindi per conservare la data di origine dal sistema di provenienza serve un campo data personalizzato separato. Anche la data dell'ultimo contatto è gestita dal CRM e non è importabile: una colonna di origine completamente popolata non ha dove andare, a meno che non aggiunga un campo personalizzato apposito. Li individui prima della mappatura, perché ciascuno di essi è o un nuovo campo personalizzato o una colonna che sta scegliendo di scartare. ### Che cosa si dovrebbe usare come chiave di deduplicazione quando si importano contatti? L'identificatore di record proprio del sistema di origine, importato in un campo personalizzato dedicato. È garantito univoco nell'origine, stabile tra un export e l'altro, e rende idempotente un'importazione ripetuta invece di duplicare tutto. L'indirizzo email è la scelta intuitiva ed è pericolosa: i database di contatti reali contengono indirizzi email duplicati, e un campione potrebbe non rivelarli. Anche l'assegnazione del proprietario dovrebbe essere mappata sull'email dell'utente di origine anziché sul nome visualizzato, perché la corrispondenza tra nome ed email non è affidabilmente uno a uno. --- Pubblicato da Coevera. Ridotto allo schema riutilizzabile: nessun nome di cliente, nessun dato dei clienti, nessun dato personale.