Flux de travail suggéré pour une migration de données complexe

Cet article suggère un processus pas à pas pour migrer de grandes quantités de données. Lors du transfert de données à partir d’un CRM basé sur le cloud puissant, il est important de planifier soigneusement en raison de sa configuration complexe, comme les objets personnalisés, les liens entre les données et les ID d’enregistrement uniques. Vous devez réfléchir à la fois aux étapes techniques et au fonctionnement de la migration dans la pratique.

• Approche technique : couvre les principales étapes de migration ( extraction, transformation et chargement de données dans Dataverse) tout en garantissant l’intégrité, la préservation des relations et l’optimisation des performances par le biais de la validation et de la gestion des erreurs.
• Approche fonctionnelle : couvre les tâches de migration fonctionnelle telles que la segmentation et l’archivage des données, et met en évidence la nécessité d’impliquer les parties prenantes de l’entreprise pour garantir que les données répondent à leurs besoins.

Approche technique pour la migration des données

Assurez-vous d’une migration fluide en suivant une approche structurée : extraire, transformer et charger des données tout en préservant l’intégrité et en réduisant les interruptions.

Extraire des données de la source vers la base de données de mise en scène

Pour les migrations de données complexes, nous vous recommandons de mettre en lots des données dans une base de données distincte (par exemple, SQL Server). Cette zone intermédiaire capture un instantané du système source sans perturber les opérations commerciales en cours.

Considérations clés :

• Charge complète et delta : organisez les données en tant que charges complètes ou incrémentielles (delta). Utilisez des horodatages générés automatiquement pour suivre l’arrivée des données et identifier les modifications pour les chargements futurs.
• Gestion du basculement : concevez le processus pour ignorer les enregistrements échoués (par exemple, en raison de la longueur du champ, des recherches invalides) sans interrompre la migration. Enregistrer et résoudre les problèmes avant le traitement ultérieur.
• Mappage de champs : convertissez les valeurs sources en correspondance avec les formats cibles dans la couche intermédiaire et les plages de valeurs de la base de données intermédiaire avant de migrer les données vers Dataverse pour améliorer l’efficacité.
• Validations des données : exécutez des vérifications d’intégrité pour intercepter des problèmes tels que des références manquantes. Étant donné que l’extraction de données peut s’étendre sur des heures ou des jours, utilisez la couche intermédiaire pour filtrer les enregistrements incomplets et garantir la cohérence.
• Visualisation des données : utilisez la base de données intermédiaire pour auditer et analyser des données( par exemple, compter des enregistrements ou additionner des champs financiers) avant la migration finale.

Transformer des données en base de données intermédiaire cible

Après avoir extrait des données du système source, transformez-la en base de données intermédiaire cible qui reflète le schéma Dataverse et contient des valeurs prêtes à être insérées ou mises à jour directes.

Étapes de transformation clés :

• Mappage de champs : Mappez les colonnes sources aux colonnes Dataverse cibles. Utilisez des scripts pour joindre et fusionner des tables si nécessaire.

• Conversion d’ensemble d’options : Convertissez des valeurs d’ensemble d’options textuels en entiers Dataverse à l’aide d’une table de mappage (par exemple, OptionSetMapping) et de requêtes de mise à jour en bloc. Créez une table pour normaliser et automatiser la transformation des valeurs d’ensemble d’options de la source vers les systèmes cibles.

  Table : OptionSetMapping

  Nom de colonne	Type de données
  Nom de la table source	ficelle
  Nom de la table cible	ficelle
  Texte source	ficelle
  Texte cible	ficelle
  Valeur cible	ficelle

  Utilisez la table OptionSetMapping pour transformer et mettre à jour efficacement les valeurs de l’ensemble d’options en bloc. Par exemple, pour mettre à jour toutes les valeurs d’ensemble d’options dans la table Contact en fonction des valeurs de texte correspondantes :

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

• Évitez les GUID personnalisés : Laissez Dataverse générer des GUID pour éviter les problèmes de fragmentation et de performances.

• Vérifications de longueur de chaîne : Vérifiez que les valeurs de chaîne correspondent aux limites dataverse. Découpez ou ajustez si nécessaire.

• Champs calculés : Ajoutez des champs dérivés (par exemple, Nom des recherches) s’ils sont manquants dans la source.

• Autre considération : lors de la conception de tables pour qu’elles correspondent au schéma Dataverse, tenez compte des colonnes clés suivantes et des tables de prise en charge.

  • DataMigration_CreatedDateTime : horodatage renseigné automatiquement pour le suivi des lots de chargement de données.
  • Indicateur d’action : Indique l’insertion (I), la mise à jour (U) ou la suppression (D).
  • Indicateur de traitement : suivi de l’état : Traité (P), Non traité (U), Erreur (E) ou Réussite (S).
  • Colonne unique : utilisez un ID unique (par exemple, l’ID unique du système source) pour mapper les enregistrements.
  • Tables réussite/erreur : conservez des tables distinctes (par exemple, Contact_Success, Contact_Error) pour consigner les résultats et prendre en charge les nouvelles tentatives.

Tables de séquences et recherches anticipées

Après les transformations statiques, ordonnancez vos tables pour réduire les dépendances cycliques, cas où les tables sont interdépendantes, ce qui rend les importations individuelles impossibles. Utilisez cette approche :

• Répertorier toutes les tables éligibles pour la migration.
• Comptez les recherches uniques par table (ignorez les champs intégrés comme Created By et les autres recherches de table si vous ne procédez pas à la migration).
• Triez les tables dans l’ordre croissant par nombre de choix.
• Incluez les tables de relations N:N, en prenant en compte les deux recherches.
• Excluez les recherches à plusieurs tables (par exemple, les champs « concernant »).

Cette approche définit la séquence de charge de migration de données et fonctionne correctement dans la plupart des scénarios. Pour des cas plus complexes :

• Utilisez un identificateur unique (par exemple, importsequencenumber) pour faire correspondre les enregistrements entre la préproduction et Dataverse lorsque les GUID sont générés pendant l’insertion.
• Séparez les journaux de réussite et d’erreur pour éviter les problèmes de verrouillage et améliorer les performances.
• Préchargez les GUID de recherche à partir de tables déjà migrées pour résoudre les références lors de l’insertion.
• Gérer les dépendances cycliques par :
  • Insertion d’enregistrements sans recherches dépendantes.
  • Mise à jour de ces recherches une fois les enregistrements associés chargés.

Charger des données dans Dataverse

L’étape suivante consiste à déterminer et à implémenter votre approche pour charger des données dans Dataverse.

1. Outils : sélectionnez un outil en fonction de la taille et de la complexité des données :

   • Outil de migration de configuration SDK
   • Azure Data Factory.
   • KingswaySoft
   • Scribe
   • Transporteur de données de XrmToolBox

2. Considérations clés (indépendantes de l’outil) :

   • Gérer les dépendances cycliques : la table de séquence se charge pour réduire les recherches circulaires. Insérez des enregistrements sans recherches dépendantes, puis mettez-les à jour ultérieurement.

   • Suivre les ID d’enregistrement : capturez les GUID Dataverse dans une table de succès, puis mettez à jour la table principale à l’aide d’un identificateur unique (par exemple, importsequencenumber).

   • Optimiser la taille du lot et le nombre de threads : passez en revue les conseils pour optimiser les performances des opérations en bloc. L’application que vous utilisez doit gérer les erreurs de protection des services qui se produisent lorsque des nombres extraordinaires de requêtes sont envoyés à Dataverse. Si vous écrivez votre propre code et utilisez l’API Web Dataverse, veillez à réessayer 429 erreurs comme décrit dans les limites de l’API de protection des services. Si vous utilisez le Kit de développement logiciel (SDK) Dataverse, il gère ces erreurs pour vous.

     Pour obtenir des performances optimales, ajustez la taille du lot et le nombre de threads en fonction de la complexité des tables :

     • Tables OOB (Out-of-the-box) (par exemple, Contact, Compte, Prospect) : ces tables sont plus lentes en raison de plug-ins intégrés et de tâches intégrées. Recommandé : taille de lot de 200 à 300, jusqu'à 30 threads (si ≤10 recherches et 50 à 70 colonnes).
     • Tables simples (peu ou pas de recherche) : recommandé : taille de lot ≤10, jusqu’à 50 threads.
     • Tables personnalisées modérément complexes (certaines recherches) : recommandé : taille de lot ≤100, jusqu’à 30 threads.
     • Tables volumineuses/complexes (>100 colonnes, >20 recherches) : recommandé : taille de lot 10 à 20, jusqu’à 10 à 20 threads pour réduire les erreurs.

3. Conseils d’infrastructure : pour optimiser les performances de migration des données, exécutez votre migration à partir d’une machine virtuelle située dans la même région que votre environnement Dataverse. Cette approche réduit considérablement la latence et accélère l’ensemble du processus. Découvrez comment déterminer la région de votre environnement Dataverse.

4. Gestion des erreurs : ne pas ignorer les erreurs, résolvez-les pour éviter les défaillances en cascade. Utilisez les valeurs par défaut (par exemple, les recherches sans valeur, les valeurs par défaut des ensembles d'options) pour insérer des enregistrements d’espace réservé et capturer des GUID.

5. Mises à jour d’état : définissez uniquement l’état actif lors de l’insertion initiale de l’enregistrement. Pour les enregistrements inactifs ou les codes d’état/état personnalisés, mettez-les à jour après la validation des données. Pour la plupart des tables personnalisées, les mises à jour d’état peuvent suivre immédiatement après l’insertion. Toutefois, pour les tables spéciales telles que Cas, Opportunité ou Lead, attendez la fin de la migration avant de mettre à jour l’état. Une fois ces enregistrements fermés, ils ne peuvent pas être modifiés, sauf s’ils sont rouverts, un processus fastidieux qui risque l’intégrité des données.

6. Propriété et sécurité : Définissez le propriétaire d’enregistrement approprié lors de l’insertion des données, car la sécurité au niveau utilisateur et la sécurité de l’unité commerciale dans Dataverse sont liées à l’unité commerciale du propriétaire. Attribuez la bonne unité commerciale lors de la création : la mise à jour ultérieurement supprime tous les rôles de sécurité.

   • Utilisez des utilisateurs fictifs :
     • Dataverse prend en charge les utilisateurs stub (non licences), qui sont utiles pour les migrations volumineuses ou historiques. Les utilisateurs stub reçoivent automatiquement le rôle de sécurité de Vendeur : ne renommez ni ne modifiez ce rôle. Les utilisateurs de stub peuvent posséder des enregistrements s’ils disposent d’un accès en lecture au niveau de l’utilisateur aux tables appropriées.
   • Recommandations :
     • Créez tous les utilisateurs sans licence lors de la migration avec l'unité commerciale correcte définie au moment de l'insertion.
     • Ne modifiez pas l’unité commerciale après la création, ce qui supprime tous les rôles, y compris l’vendeur.
     • Vérifiez que le rôle Vendeur dispose d’un accès en lecture à toutes les tables éligibles à la migration.
     • Même les utilisateurs désactivés dans l’environnement Dataverse avec ce rôle peuvent posséder des enregistrements.

7. Gestion des devises : définissez les taux de change lors de l’insertion à l’aide d’un plug-in de prévalidation, car Dataverse ne prend pas en charge les taux historiques.

Publier le chargement des données dans Dataverse

Après avoir chargé des données dans Dataverse, procédez comme suit pour garantir l’intégrité des données et réduire les problèmes en aval :

1. Mettez à jour la table principale avec des GUID :

   • Après une charge réussie, copiez les GUID d’enregistrement Dataverse de la table des réussites dans la table principale en utilisant un identifiant unique tel que importsequencenumber.
   • Mettez à jour l’indicateur de traitement pour marquer les enregistrements comme suit :
     • P – Traitement effectué
     • E – Erreur
     • U : Cette stratégie non traitée permet une réexécution efficace en ignorant les enregistrements déjà traités et en prenant en charge la résolution de recherche dans les chargements suivants.

2. Relance des enregistrements échoués : pour réduire le travail et maintenir l’intégrité référentielle, tenez compte des actions suivantes :

   • Supprimez les valeurs de chaîne si elles dépassent les longueurs autorisées.
   • Appliquez des valeurs d'ensemble d'options par défaut lorsque les mappages sont manquants.
   • Attribuez un propriétaire suppléant si le propriétaire d’origine n’est pas disponible (même en tant qu’utilisateur de substitution).
   • Utilisez des valeurs vides ou par défaut pour les recherches non résolues.
   • Même les enregistrements d’espace réservé peuvent aider à générer des GUID nécessaires pour les recherches dans les tables associées.

Utilisation de tables élastiques pour la migration de données

Les tables élastiques sont conçues pour gérer de grands volumes de données en temps réel. Avec les tables élastiques, vous pouvez importer, stocker et analyser de gros volumes de données sans problèmes d’évolutivité, de latence ou de performances.

Les tables élastiques offrent des fonctionnalités uniques pour le schéma flexible, la mise à l’échelle horizontale et la suppression automatique des données après une période spécifique.

Les tables élastiques sont stockées dans Azure Cosmos DB et prennent en charge :

• Données sans schéma via des colonnes JSON
• Mise à l’échelle horizontale automatique
• Durée de vie (TTL) pour la suppression automatique des données obsolètes
• Partitionnement pour l’optimisation des performances

Les tables élastiques conviennent mieux aux importations en bloc avec un schéma variable.

Types de données recommandés pour les tables élastiques pendant la migration des données

Les tables élastiques sont idéales pour des types de données spécifiques.

Types de données inappropriés pour les tables élastiques

Les tables élastiques sont optimisées pour des scénarios flexibles et à grande échelle — cependant, tous les types de données ne conviennent pas. Cette section met en évidence les modèles de données CRM courants qui sont mieux stockés ailleurs pour garantir les performances, l’efficacité et la maintenance. En savoir plus sur les fonctionnalités actuellement non prises en charge avec les tables élastiques

Infrastructure d’archivage et de segmentation des données fonctionnelles

Une planification technique efficace comprend la sélection des outils et de l’infrastructure appropriés, l’alignement des volumes de données source et cible et la configuration des processus d’audit et de rapprochement. De nombreuses migrations deviennent complexes en raison d’un manque d’analyse initiale, en particulier autour de ce que les données doivent déplacer et où elles appartiennent. Cette section décrit les principes fondamentaux de l’analyse des données pour prendre en charge une migration réussie.

Segmentation des données

La segmentation des données est une étape clé de la migration d’un système CRM vers Dataverse. Organisez les tables de données par fonction métier, comme les ventes, le service ou le marketing, pour simplifier la planification et l’exécution de la migration.

Segmentation des tables

Commencez par répertorier toutes les tables éligibles à la migration, regroupées par secteur d’activité (par exemple, ventes, marketing, service). Ensuite :

• Documentez le schéma dans Excel ou un outil similaire.
• Exécutez des requêtes de base dans le système source pour vérifier l’utilisation des colonnes.
• Marquer les colonnes à faible utilisation. Si moins de 5% d’enregistrements contiennent des valeurs, consultez les parties prenantes de l’entreprise pour décider s’il faut les conserver ou les ignorer.

Cette analyse simple peut réduire considérablement l’étendue de la migration. Dans les systèmes CRM de longue durée, il est courant d’éliminer 30 à 40% de colonnes et jusqu’à 20% de tables, de simplifier le processus et d’améliorer les performances.

Pertinence des colonnes

Certaines colonnes système sources sont mappées directement à Dataverse, tandis que d’autres deviennent des champs calculés. Séparez ces colonnes et consultez les parties prenantes de l’entreprise pour déterminer si des travaux de migration sont nécessaires.

Ignorez les colonnes qui ne sont pertinentes que dans le système source ou qui ne sont pas significatives dans la cible. Cela inclut de nombreux champs prêts à l’emploi, tels que Créé par, Modifié par ou Numéro de version de ligne, sauf s’ils servent un objectif spécifique dans votre migration.

Données de type de fichier

Si votre système source inclut des données de type de fichier, signalez ces champs au début et planifiez une stratégie de migration distincte. Tenez compte des types de fichiers suivants :

• Documents Office (par exemple, Word, Excel, PowerPoint) : pour un maximum de 20 000 fichiers, migrez vers une plateforme collaborative telle que SharePoint pour activer l’accès multi-utilisateur.
• Fichiers multimédias (par exemple, images, vidéos) : choisissez une plateforme prenant en charge la lecture. Les options incluent SharePoint, les services de diffusion en continu ou d’autres solutions de stockage compatibles avec les médias.
• Grands volumes ou fichiers volumineux : si le coût de stockage est un problème, utilisez Azure Blob Storage ou la colonne de fichier native dans Dataverse, qui utilise Azure Blob en coulisse.
• Protection contre les programmes malveillants : exécutez des fichiers via un outil de détection de programmes malveillants (par exemple, Azure Advanced Threat Protection) avant la migration pour garantir la sécurité.

Après avoir examiné la pertinence des fichiers, vous constatez souvent que le volume total de données diminue considérablement, en particulier dans les systèmes CRM à long terme, ce qui rend la migration plus efficace.

Stratégies d’archivage des données

Certaines données, telles que les anciens e-mails, les cas fermés ou les prospects disqualifiés, restent importantes, mais rarement accessibles. Pour réduire le volume de migration sans perturber les opérations métier, développez une stratégie d’archivage intelligente.

Étape 1 : Identifier les données archivées

Les candidats courants sont les suivants :

• E-mails âgés de plus de trois ans
• Cas fermés
• Opportunités perdues
• Prospects disqualifiés
• E-mails marketing, publications et journaux d’audit

Passez en revue votre système pour identifier d’autres tables que vous pouvez archiver.

Étape 2 : Choisir une approche d’archivage

• Conservez les données dans le système source. Conservez quelques licences d’administrateur pour l’accès tout en désactivant les autres pour réduire les coûts.
• Passez au stockage externe. Utilisez des bases de données locales, stockage Blob Azure ou tables Azure pour stocker des enregistrements archivés. Cette approche réduit les coûts de stockage et de migration, mais nécessite une stratégie de migration distincte.
• Utilisez un environnement Dataverse distinct. Cette option est moins courante, mais elle est utile si vous souhaitez isoler les données archivées. Vous pouvez mettre hors service cet environnement ultérieurement pour simplifier la planification de basculement.

Infrastructure de migration de données recommandée

Pour garantir une migration rapide et fiable des données vers Dataverse :

• Utilisez une machine virtuelle dans la même région que votre environnement Dataverse pour réduire la latence et améliorer la vitesse de migration.
• Choisissez une machine virtuelle hautes performances. Au minimum, utilisez une machine virtuelle D4 avec huit cœurs, 28 Go de RAM et un stockage de 500 Go pour gérer efficacement de grands volumes de données.
• Préférez une base de données locale sur la machine virtuelle. Évitez les connexions distantes pendant la migration. Si vous utilisez Azure Data Factory, déployez-le dans la même région que votre environnement Dataverse pour des performances optimales.

Étape suivante