Flusso di lavoro consigliato per una migrazione dei dati complessa

Questo articolo suggerisce un processo dettagliato per la migrazione di grandi quantità di dati. Quando si trasferiscono dati da un crm potente basato sul cloud, è importante pianificare attentamente a causa della relativa configurazione complessa, ad esempio oggetti personalizzati, collegamenti tra dati e ID record univoci. È necessario considerare sia i passaggi tecnici che il funzionamento della migrazione in pratica.

• Approccio tecnico: illustra i passaggi di migrazione chiave, ovvero l'estrazione, la trasformazione e il caricamento dei dati in Dataverse, garantendo al tempo stesso l'integrità, mantenendo le relazioni e ottimizzando le prestazioni tramite la convalida e la gestione degli errori.
• Approccio funzionale: illustra le attività di migrazione funzionale, ad esempio la segmentazione e l'archiviazione dei dati, evidenziando la necessità di coinvolgere gli stakeholder aziendali per garantire che i dati soddisfino le proprie esigenze.

Approccio tecnico per la migrazione dei dati

Assicurarsi una migrazione senza problemi seguendo un approccio strutturato, ovvero estrarre, trasformare e caricare i dati mantenendo l'integrità e riducendo al minimo le interruzioni.

I sei passaggi principali del flusso di lavoro di migrazione dei dati sono: 1. Preparare le tabelle degli errori, esiti positivi e di destinazione. 2. Caricare i dati nella tabella di destinazione. 3. Eseguire trasformazioni, ad esempio set di opzioni e taglio del testo. 4. Precaricare i GUID di ricerca nella tabella di destinazione. 5. Caricare dati in Dataverse. 6. Carica i GUID dei record riusciti nella tabella di destinazione.

Estrarre dati dalla sorgente al database di staging

Per le migrazioni di dati complesse, è consigliabile eseguire lo staging dei dati in un database separato, ad esempio SQL Server. Questa area di gestione temporanea acquisisce uno snapshot del sistema di origine senza interrompere le operazioni aziendali in corso.

Considerazioni chiave:

• Caricamento completo e differenziale: organizzare i dati come carichi completi o incrementali (differenziali). Usare i timestamp generati automaticamente per tenere traccia dell'arrivo dei dati e identificare le modifiche per i carichi futuri.
• Gestione del failover: progetta il processo per ignorare i record non riusciti (ad esempio, a causa della lunghezza del campo, ricerche non valide) senza interrompere la migrazione. Registrare e risolvere i problemi prima della rielaborazione.
• Mappatura dei campi: convertire i valori di origine per corrispondere ai formati di destinazione nel livello di staging e agli intervalli di valori nel database di staging, prima di migrare i dati in Dataverse per migliorare l'efficienza.
• Convalide dei dati: eseguire controlli di integrità per rilevare problemi come i riferimenti mancanti. Poiché l'estrazione dei dati può durare ore o giorni, usare il livello di gestione temporanea per filtrare i record incompleti e garantire la coerenza.
• Visualizzazione dei dati: usare il database di staging per controllare e analizzare i dati, ad esempio conteggiare i record o sommare i campi finanziari, prima della migrazione finale.

Trasformare i dati in un database di staging di destinazione

Dopo aver estratto i dati dal sistema di origine, trasformarli in un database di staging di destinazione che rispecchia lo schema dataverse e contiene valori pronti per l'inserimento diretto o l'aggiornamento.

Passaggi di trasformazione chiave:

• Mapping dei campi: Mappare le colonne di origine a quelle di destinazione di Dataverse. Usare gli script per collegare e combinare tabelle, se necessario.

• Conversione del set di opzioni: Convertire i valori del set di opzioni basato su testo in numeri interi di Dataverse usando una tabella di mappatura (ad esempio OptionSetMapping) e le query di aggiornamento bulk. Creare una tabella per standardizzare e automatizzare la trasformazione dei valori del set di opzioni dai sistemi di origine a quello di destinazione.

  Tabella: OptionSetMapping

  Nome della colonna	Tipo di dati
  Nome della tabella di origine	string
  Nome tabella di destinazione	string
  Testo di origine	string
  Testo di destinazione	string
  Valore target	string

  Usare la tabella OptionSetMapping per trasformare e aggiornare in modo efficiente i valori del set di opzioni in blocco. Ad esempio, per aggiornare tutti i valori del set di opzioni nella tabella Contact in base ai valori di testo corrispondenti:

  Update C.\<OptionsetValue\> = M.\<TargetValue\> 
  FROM Contact C 
  JOIN OptionsetMapping M 
    ON C.OptionsetText = M.TargetText 
    AND M.TargetTableName = 'Contact'
  

• Evitare GUID personalizzati: Consentire a Dataverse di generare GUID per evitare problemi di frammentazione e prestazioni.

• Controlli di lunghezza stringa: Verificare che i valori stringa siano adatti ai limiti di Dataverse. Tagliare o regolare in base alle esigenze.

• Campi calcolati: Aggiungere campi derivati (ad esempio, Nome per le ricerche) se mancanti nell'origine.

• Altre considerazioni: quando si progettano tabelle in modo che corrispondano allo schema Dataverse, prendere in considerazione le colonne chiave e le tabelle di supporto seguenti.

  • DataMigration_CreatedDateTime: timestamp popolato automaticamente per tenere traccia dei batch di caricamento dei dati.
  • Flag azione: indica l'Inserimento (I), l'Aggiornamento (U) o l'Eliminazione (D).
  • Flag di elaborazione: tiene traccia dello stato - Elaborato (P), Non elaborato (U), Errore (E) o Esito positivo (S).
  • Colonna univoca: usare un ID univoco, ad esempio l'ID univoco del sistema di origine, per eseguire il mapping dei record.
  • Tabelle di esito positivo/errore: gestire tabelle separate (ad esempio, Contact_Success, Contact_Error) per registrare i risultati e supportare i tentativi.

Tabelle di sequenza e ricerche precaricate

Dopo le trasformazioni statiche, ordinare le tabelle per ridurre le dipendenze cicliche, ovvero i casi in cui le tabelle fanno riferimento l'una all'altra, rendendo impossibili le importazioni isolate. Usare questo approccio:

• Elencare tutte le tabelle idonee per la migrazione.
• Conteggio delle ricerche univoche per tabella (ignorare i campi predefiniti come Created By e altre ricerche nelle tabelle se non si esegue la migrazione).
• Ordinare le tabelle in ordine crescente in base al numero di ricerche.
• Includere le tabelle delle relazioni N:N, conteggiando entrambi i campi di ricerca.
• Escludi le ricerche su più tabelle (ad esempio, i campi "per quanto riguarda").

Questo approccio definisce la sequenza di caricamento della migrazione dei dati e funziona correttamente nella maggior parte degli scenari. Per casi più complessi:

• Usare un identificatore univoco( ad esempio importsequencenumber) per trovare una corrispondenza tra i record di staging e Dataverse quando i GUID vengono generati durante l'inserimento.
• Separare i log di esito positivo e di errore per evitare problemi di blocco e migliorare le prestazioni.
• Precarica i GUID di ricerca dalle tabelle già migrate per risolvere i riferimenti durante l'inserimento.
• Gestire le dipendenze cicliche in base a:
  • Inserimento di record senza ricerche dipendenti.
  • Aggiornamento di tali ricerche dopo il caricamento dei record correlati.

Caricamento dei dati in Dataverse

Il passaggio successivo consiste nel determinare e implementare l'approccio per caricare i dati in Dataverse.

1. Strumenti: selezionare uno strumento in base alle dimensioni dei dati e alla complessità:

   • Strumento di migrazione della configurazione dell'SDK
   • Azure Data Factory
   • KingswaySoft
   • Scribe
   • Data Transporter di XrmToolBox

2. Considerazioni chiave (indipendente dallo strumento):Key considerations (tool-agnostic):

   • Gestire le dipendenze cicliche: Caricare le tabelle in sequenza per minimizzare le ricerche circolari. Inserisci record senza ricerche dipendenti, quindi aggiornali in un secondo momento.

   • Tenere traccia degli ID record: acquisire GUID di dataverse in una tabella riuscita, quindi aggiornare la tabella principale usando un identificatore univoco, ad esempio importsequencenumber.

   • Ottimizzare le dimensioni del batch e il numero di thread: esaminare le linee guida per ottimizzare le prestazioni per le operazioni bulk. L'applicazione usata deve gestire gli errori di protezione del servizio che si verificano quando vengono inviati numeri straordinari di richieste a Dataverse. Se scrivi codice personalizzato e utilizzi l'API Web di Dataverse, assicurati di ripetere gli errori 429, come descritto in Limiti dell'API di protezione dei servizi. Se si usa Dataverse SDK, questi errori vengono gestiti automaticamente.

     Per ottenere prestazioni ottimali, ottimizzare le dimensioni del batch e il numero di thread in base alla complessità delle tabelle:

     • Tabelle pronte all'uso (OOB), ad esempio Contatto, Account, Lead: queste tabelle sono più lente a causa di plug-in e attività integrate. Consigliato: dimensione batch da 200 a 300, fino a 30 thread (se ≤10 ricerche e 50–70 colonne).
     • Tabelle semplici (poche o nessuna ricerca): scelta consigliata: dimensioni batch ≤10, fino a 50 thread.
     • Tabelle personalizzate moderatamente complesse (alcune ricerche): scelta consigliata: dimensioni batch ≤100, fino a 30 thread.
     • Tabelle complesse di grandi dimensioni (>100 colonne, >20 ricerche): scelta consigliata: dimensioni batch da 10 a 20, fino a 10-20 thread per ridurre gli errori.

3. Suggerimenti sull'infrastruttura: per ottimizzare le prestazioni di migrazione dei dati, eseguire la migrazione da una macchina virtuale (VM) che si trova nella stessa area dell'ambiente Dataverse. Questo approccio riduce significativamente la latenza e accelera l'intero processo. Informazioni su come determinare l'area dell'ambiente Dataverse.

4. Gestione degli errori: non ignorare gli errori, risolverli per evitare errori a catena. Usa le impostazioni predefinite, ad esempio ricerche vuote, valori predefiniti del set di opzioni, per inserire record segnaposto e acquisire GUID.

5. Aggiornamenti dello stato: imposta lo stato attivo solo durante l'inserimento iniziale dei record. Per i record inattivi o i codici di stato personalizzati, aggiornarli dopo la convalida dei dati. Per la maggior parte delle tabelle personalizzate, gli aggiornamenti dello stato possono essere seguiti immediatamente dopo l'inserimento. Tuttavia, per tabelle speciali come Case, Opportunity o Lead, posticipare gli aggiornamenti di stato fino alla fine della migrazione. Una volta chiusi questi record, non possono essere modificati a meno che non vengano riaperti, ovvero un processo dispendioso in termini di tempo che rischia l'integrità dei dati.

6. Proprietà e sicurezza: impostare il proprietario del record corretto durante l'inserimento dei dati, in quanto la sicurezza a livello di utente e business unit in Dataverse è associata alla business unit del proprietario. Assegnare la business unit corretta al momento della creazione. L'aggiornamento in seguito rimuove tutti i ruoli di sicurezza.

   • Utilizzare gli utenti stub:
     • Dataverse supporta gli utenti stub (senza licenza), utili per migrazioni di grandi dimensioni o cronologiche. Agli utenti Stub viene assegnato automaticamente il ruolo di sicurezza Salesperson, non rinominare o modificare questo ruolo. Gli utenti Stub possono possedere record se hanno accesso in lettura a livello di utente alle tabelle pertinenti.
   • Raccomandazioni:
     • Creare tutti gli utenti non licenziati durante la migrazione con la corretta business unit impostata al momento dell'inserimento.
     • Non modificare la business unit dopo la creazione, poiché ciò rimuove tutti i ruoli, incluso Venditore.
     • Verifica che il ruolo di Venditore abbia accesso in lettura a tutte le tabelle idonee alla migrazione.
     • Anche gli utenti disabilitati nell'ambiente Dataverse con questo ruolo possono possedere record.

7. Gestione delle valute: impostare i tassi di cambio durante l'inserimento usando un plug-in prevalidation, perché Dataverse non supporta i tassi cronologici.

Pubblicare il caricamento dei dati in Dataverse

Dopo il caricamento dei dati in Dataverse, seguire questa procedura per garantire l'integrità dei dati e ridurre al minimo i problemi downstream:

1. Aggiornare la tabella principale con GUID:

   • Dopo un caricamento riuscito, copiare i GUID del record Dataverse dalla tabella Successo nella tabella principale usando un identificatore univoco, ad esempio importsequencenumber.
   • Aggiornare l'indicatore di elaborazione per contrassegnare i record come:
     • P - Elaborato
     • E - Errore
     • U: non elaborato Questa strategia consente riesecuzioni efficienti ignorando record già elaborati e supporta la risoluzione di ricerca nei carichi successivi.

2. Ripetere i record non riusciti: per ridurre le rielaborazioni e mantenere l'integrità referenziale, prendere in considerazione queste azioni:

   • Taglia i valori delle stringhe se superano le lunghezze consentite.
   • Applicare i valori predefiniti del set di opzioni quando mancano i mapping.
   • Assegna un proprietario di fallback se il proprietario originale non è disponibile (anche nel caso di un utente temporaneo).
   • Usare valori vuoti o predefiniti per le ricerche non risolte.
   • Anche i record segnaposto consentono di generare GUID necessari per le ricerche nelle tabelle correlate.

Uso di tabelle elastici per la migrazione dei dati

Le tabelle elastiche sono progettate per gestire volumi elevati di dati in tempo reale. Con le tabelle elastiche puoi importare, archiviare e analizzare grandi volumi di dati senza problemi di scalabilità, latenza o prestazioni.

Le tabelle elastiche offrono funzionalità esclusive per lo schema flessibile, il ridimensionamento orizzontale e la rimozione automatica dei dati dopo un periodo di tempo specifico.

Le tabelle elastiche vengono archiviate in Azure Cosmos DB e supportano:

• Dati senza schema tramite colonne JSON
• Scalabilità orizzontale automatica
• Durata di vita (TTL) per l'eliminazione automatica di dati obsoleti
• Partizionamento per l'ottimizzazione delle prestazioni

Le tabelle elastiche sono più adatte per le importazioni bulk con schema variabile.

Tipi di dati consigliati per le tabelle elastici durante la migrazione dei dati

Le tabelle elastiche sono ideali per tipi di dati specifici.

Tipo di dati	Description
Dati di ingestione grezzi	Log di origini, feed di sensori o esportazioni di massa da sistemi legacy. Ad esempio, i log di interazione dei clienti da un ERP legacy, i vecchi thread di posta elettronica e i ticket di supporto del sistema precedente.
Record semistrutturati	Dati con campi facoltativi o in continua evoluzione che non rientrano in uno schema rigido. Ad esempio, moduli di feedback dei clienti con campi facoltativi o moduli di registrazione eventi con note o tag personalizzati.
Predisposizione dei dati per la convalida	Una zona di mantenimento temporanea prima di sincronizzare i dati con le tabelle relazionali. Ad esempio, i dati dei contatti importati in attesa della deduplicazione e della convalida prima di essere aggiunti alla tabella principale dei contatti.
Dati sensibili al tempo o alla scadenza	Usare il TTL (Time-to-Live) per l'eliminazione automatica dei record CRM temporanei. Ad esempio, i codici sconto promozionali associati a una campagna, i collegamenti di accesso monouso per i sondaggi dei clienti o i portali di onboarding e le risposte temporanee ai sondaggi.
Dati in blocco partizionati	Partizionare i dati in base all'ID o alla categoria per migliorare le prestazioni e la scalabilità. Ad esempio, partizionare per ID dell'account o ID della regione durante la migrazione dei dati in blocco o segmentare i registri delle attività dei clienti basati sull'ID della campagna per analisi.

Tipi di dati non adatti alle tabelle elastiche

Le tabelle elastiche sono ottimizzate per scenari flessibili e su larga scala, ma non per tutti i tipi di dati. Questa sezione illustra i modelli di dati CRM comuni archiviati altrove per garantire prestazioni, efficienza dei costi e gestibilità. Altre informazioni sulle funzionalità attualmente non supportate con le tabelle elastiche

Tipo di dati	Motivo
Dati altamente relazionali	Le tabelle elastiche non supportano join o ricerche
Registri critici aziendali	Nessun supporto per l'integrità transazionale o il plug-in
Dati che richiedono una convalida complessa	Gestito meglio nelle tabelle standard con regole aziendali

Segmentazione dei dati funzionali e framework di archiviazione

Una pianificazione tecnica efficace include la selezione degli strumenti e dell'infrastruttura corretti, l'allineamento dei volumi di dati di origine e di destinazione e la configurazione dei processi di controllo e riconciliazione. Molte migrazioni diventano complesse a causa di una mancanza di analisi iniziale, soprattutto per quanto riguarda i dati da spostare e dove appartengono. In questa sezione vengono descritti i principi fondamentali dell'analisi dei dati per supportare una migrazione riuscita.

Segmentazione dei dati

La segmentazione dei dati è un passaggio fondamentale per la migrazione da un sistema CRM a Dataverse. Organizzare le tabelle dei dati in base alla funzione aziendale, ad esempio vendite, servizi o marketing, per semplificare la pianificazione e l'esecuzione della migrazione.

Segmentazione delle tabelle

Per iniziare, elencare tutte le tabelle idonee per la migrazione, raggruppate in base all'area aziendale (ad esempio, vendite, marketing, servizio). Quindi:

• Documentare lo schema in Excel o uno strumento simile.
• Eseguire query di base nel sistema di origine per controllare l'utilizzo delle colonne.
• Contrassegna le colonne a basso utilizzo. Se meno di 5% di record contengono valori, rivolgersi agli stakeholder aziendali per decidere se conservarli o eliminarli.

Questa semplice analisi può ridurre significativamente l'ambito di migrazione. Nei sistemi CRM a esecuzione prolungata, è comune eliminare 30-40% di colonne e fino a 20% di tabelle, semplificando il processo e migliorando le prestazioni.

Pertinenza delle colonne

Alcune colonne di sistema di origine vengono mappate direttamente su Dataverse, mentre altre diventano campi calcolati. Separare queste colonne e consultare gli stakeholder aziendali per decidere se sono necessari incarichi di migrazione.

Ignorare le colonne rilevanti solo nel sistema di origine o non significative nella destinazione. Sono inclusi molti campi predefiniti, come Creato da, Modificato da o Numero di versione della riga, a meno che non abbiano uno scopo specifico nella migrazione.

Dati del tipo di file

Se il sistema di origine include dati di tipo file, contrassegna questi campi in anticipo e pianifica una strategia di migrazione separata. Considerare i tipi di file seguenti:

• Documenti di Office ,ad esempio Word, Excel, PowerPoint: per un massimo di 20.000 file, eseguire la migrazione a una piattaforma collaborativa come SharePoint per abilitare l'accesso multiutente.
• File multimediali ,ad esempio immagini, video: scegliere una piattaforma che supporti la riproduzione. Le opzioni includono SharePoint, servizi di streaming o altre soluzioni di archiviazione adatte ai contenuti multimediali.
• Volumi o file di grandi dimensioni: se il costo di archiviazione è un problema, utilizzare Azure Blob Storage o la colonna file nativa in Dataverse, che usa Blob di Azure in background.
• Protezione antimalware: eseguire i file tramite uno strumento di rilevamento malware (ad esempio, Azure Advanced Threat Protection) prima della migrazione per garantire la sicurezza.

Dopo aver esaminato la pertinenza dei file, spesso si nota che il volume totale dei dati diminuisce significativamente, soprattutto nei sistemi CRM a esecuzione prolungata, rendendo la migrazione più efficiente.

Strategie di archiviazione dei dati

Alcuni dati, come i vecchi messaggi di posta elettronica, i casi chiusi o i lead non qualificati, rimangono importanti, ma raramente sono accessibili. Per ridurre il volume di migrazione senza interrompere le operazioni aziendali, sviluppare una strategia di archiviazione intelligente.

Passaggio 1: Identificare i dati archiviabili

I candidati comuni includono:

• Messaggi di posta elettronica precedenti a tre anni
• Casi chiusi
• Opportunità perse
• Lead non qualificati
• Messaggi di posta elettronica di marketing, post e log di controllo

Esaminare il sistema per identificare altre tabelle che è possibile archiviare.

Passaggio 2: Scegliere un approccio di archiviazione

• Mantenere i dati nel sistema di origine. Conservare alcune licenze di amministratore per l'accesso durante la disattivazione di altri utenti per ridurre i costi.
• Passare all'archiviazione esterna. Usare database locali, Azure Blob Storage o Tabelle di Azure per memorizzare i record archiviati. Questo approccio riduce i costi di archiviazione e migrazione, ma richiede una strategia di migrazione separata.
• Usare un ambiente Dataverse separato. Questa opzione è meno comune, ma è utile se si vogliono isolare i dati archiviati. Puoi ritirare questo ambiente in un secondo momento per semplificare la pianificazione del cutover.

Infrastruttura di migrazione dei dati consigliata

Per garantire una migrazione dei dati veloce e affidabile in Dataverse:

• Usare una macchina virtuale (VM) nella stessa area dell'ambiente Dataverse per ridurre la latenza e migliorare la velocità di migrazione.
• Scegliere una macchina virtuale a prestazioni elevate. Usare almeno una macchina virtuale D4 con otto core, 28 GB di RAM e 500 GB di spazio di archiviazione per gestire in modo efficiente volumi di dati di grandi dimensioni.
• Preferisce un database locale nella macchina virtuale. Evitare connessioni remote durante la migrazione. Se si usa Azure Data Factory, distribuirlo nella stessa area dell'ambiente Dataverse per ottenere prestazioni ottimali.

Passo successivo

Segui Power Platform Well-Architected per l'eccellenza architettonica