Migrer les données héritées sans tout gâcher

La migration des données héritées est difficile.

De nombreuses organisations disposent de systèmes CRM d'entreprise anciens et complexes sur site. Aujourd'hui, il existe de nombreuses alternatives cloud SaaS, qui présentent de nombreux avantages. payez au fur et à mesure et ne payez que ce que vous utilisez. Par conséquent, ils décident de passer aux nouveaux systèmes.

Personne ne veut laisser de précieuses données sur les clients dans l'ancien système et commencer avec le nouveau système vide, nous devons donc migrer ces données. Malheureusement, la migration des données n'est pas une tâche facile, car environ 50 % des efforts de déploiement sont consacrés aux activités de migration des données. Selon Gartner, Salesforce est le leader des solutions cloud CRM. Par conséquent, la migration des données est un sujet majeur pour le déploiement de Salesforce.

Alors, comment pouvons-nous assurer une transition réussie des données héritées vers un nouveau système brillant et nous assurer que nous préserverons tout son historique ? Dans cet article, je donne 10 conseils pour une migration de données réussie. Les cinq premiers conseils s'appliquent à toute migration de données, quelle que soit la technologie utilisée.

Migration de données en général

1. Faites de la migration un projet distinct

Dans la liste de contrôle du déploiement de logiciels, la migration des données n'est pas un élément "d'exportation et d'importation" géré par un outil de migration de données intelligent "appuyez sur un bouton" qui a un mappage prédéfini pour les systèmes cibles.

La migration des données est une activité complexe, qui mérite un projet, un plan, une approche, un budget et une équipe distincts. Une portée et un plan au niveau de l'entité doivent être créés au début du projet, évitant ainsi les surprises, telles que "Oh, nous avons oublié de charger les rapports de visite de ces clients, qui le fera ?" deux semaines avant la date limite.

L'approche de migration des données définit si nous allons charger les données en une seule fois (également connu sous le nom de big bang ), ou si nous allons charger de petits lots chaque semaine.

Ce n'est pas une décision facile, cependant. L'approche doit être convenue et communiquée à toutes les parties prenantes commerciales et techniques afin que chacun sache quand et quelles données apparaîtront dans le nouveau système. Cela s'applique également aux pannes de système.

2. Estimez de façon réaliste

Ne sous-estimez pas la complexité de la migration des données. De nombreuses tâches chronophages accompagnent ce processus, qui peut être invisible au début du projet.

Par exemple, charger des ensembles de données spécifiques à des fins de formation avec un ensemble de données réalistes, mais avec des éléments sensibles masqués, afin que les activités de formation ne génèrent pas de notifications par e-mail aux clients.

Le facteur de base pour l'estimation est le nombre de champs à transférer d'un système source vers un système cible.

Un certain temps est nécessaire aux différentes étapes du projet pour chaque champ, y compris la compréhension du champ, le mappage du champ source au champ cible, la configuration ou la création de transformations, la réalisation de tests, la mesure de la qualité des données pour le champ, etc.

L'utilisation d'outils intelligents, tels que Jitterbit, Informatica Cloud Data Wizard, Starfish ETL, Midas, etc., peut réduire ce temps, en particulier dans la phase de construction.

En particulier, la compréhension des données sources - la tâche la plus cruciale de tout projet de migration - ne peut pas être automatisée par des outils, mais nécessite que les analystes prennent du temps pour parcourir la liste des champs un par un.

L'estimation la plus simple de l'effort global est d'un jour-homme pour chaque champ transféré depuis l'ancien système.

Une exception est la réplication de données entre les mêmes schémas source et cible sans autre transformation - parfois appelée migration 1:1 - où nous pouvons baser l'estimation sur le nombre de tables à copier.

Une estimation détaillée est un art à part entière.

3. Vérifier la qualité des données

Ne surestimez pas la qualité des données source, même si aucun problème de qualité des données n'est signalé par les systèmes hérités.

Les nouveaux systèmes ont de nouvelles règles, qui peuvent être enfreintes avec les données héritées. Voici un exemple simple. L'e-mail de contact peut être obligatoire dans le nouveau système, mais un ancien système de 20 ans peut avoir un point de vue différent.

Il peut y avoir des mines cachées dans les données historiques qui n'ont pas été touchées depuis longtemps mais qui pourraient s'activer lors du transfert vers le nouveau système. Par exemple, les anciennes données utilisant des devises européennes qui n'existent plus doivent être converties en euros, sinon les devises doivent être ajoutées au nouveau système.

La qualité des données influence considérablement l'effort, et la règle simple est la suivante : plus nous avançons dans l'histoire, plus nous découvrirons de désordre. Ainsi, il est essentiel de décider tôt de la quantité d' historique que nous voulons transférer dans le nouveau système.

4. Engagez les gens d'affaires

Les gens d'affaires sont les seuls qui comprennent vraiment les données et qui peuvent donc décider quelles données peuvent être jetées et quelles données conserver.

Il est important d'avoir quelqu'un de l'équipe commerciale impliqué pendant l'exercice de cartographie, et pour un futur retour en arrière, il est utile d'enregistrer les décisions de cartographie et les raisons de celles-ci.

Puisqu'une image vaut plus que mille mots, chargez un lot de test dans le nouveau système et laissez l'équipe commerciale jouer avec.

Même si le mappage de la migration des données est examiné et approuvé par l'équipe commerciale, des surprises peuvent apparaître une fois que les données apparaissent dans l'interface utilisateur du nouveau système.

"Oh, maintenant je vois, nous devons le changer un peu", devient une phrase courante.

Le fait de ne pas engager d'experts en la matière, qui sont généralement des personnes très occupées, est la cause la plus courante de problèmes après la mise en service d'un nouveau système.

5. Visez une solution de migration automatisée

La migration des données est souvent considérée comme une activité ponctuelle, et les développeurs ont tendance à se retrouver avec des solutions pleines d'actions manuelles dans l'espoir de ne les exécuter qu'une seule fois. Mais il existe de nombreuses raisons d'éviter une telle approche.

• Si la migration est divisée en plusieurs vagues, nous devons répéter les mêmes actions plusieurs fois.
• En règle générale, il y a au moins trois exécutions de migration pour chaque vague : une simulation pour tester les performances et les fonctionnalités de la migration des données, une charge complète de validation des données pour tester l'ensemble des données et effectuer des tests métier, et bien sûr, une charge de production. Le nombre d'exécutions augmente avec la mauvaise qualité des données. L'amélioration de la qualité des données est un processus itératif, nous avons donc besoin de plusieurs itérations pour atteindre le taux de réussite souhaité.

Ainsi, même si la migration est une activité ponctuelle par nature, avoir des actions manuelles peut considérablement ralentir vos opérations.

Migration des données Salesforce

Ensuite, nous couvrirons cinq conseils pour une migration Salesforce réussie. Gardez à l'esprit que ces conseils s'appliquent probablement également à d'autres solutions cloud.

6. Préparez-vous à de longues charges

La performance est l'un des compromis, sinon le plus important, lors du passage d'une solution sur site à une solution cloud - Salesforce n'est pas exclu.

Les systèmes sur site permettent généralement le chargement direct des données dans une base de données sous-jacente, et avec un bon matériel, nous pouvons facilement atteindre des millions d'enregistrements par heure.

Mais pas dans le cloud. Dans le cloud, nous sommes fortement limités par plusieurs facteurs.

• Latence du réseau – Les données sont transférées via Internet.
• Couche d'application Salesforce - Les données sont déplacées via une épaisse couche d'API mutualisée jusqu'à ce qu'elles atterrissent dans leurs bases de données Oracle.
• Code personnalisé dans Salesforce - Validations personnalisées, déclencheurs, flux de travail, règles de détection de duplication, etc. - dont beaucoup désactivent les chargements parallèles ou en masse.

Par conséquent, les performances de charge peuvent atteindre des milliers de comptes par heure.

Il peut être inférieur ou supérieur, selon des éléments tels que le nombre de champs, de validations et de déclencheurs. Mais il est plusieurs fois plus lent qu'un chargement direct de la base de données.

La dégradation des performances, qui dépend du volume de données dans Salesforce, doit également être prise en compte.

Cela est dû aux index du SGBDR sous-jacent (Oracle) utilisé pour vérifier les clés étrangères, les champs uniques et l'évaluation des règles de duplication. La formule de base est d'environ 50 % de ralentissement pour chaque note de 10, causé par O(logN) la partie complexité du temps dans les opérations de tri et d'arbre B.

De plus, Salesforce a de nombreuses limites d'utilisation des ressources.

L'un d'eux est la limite de l'API de transfert en masse fixée à 5 000 lots dans des fenêtres glissantes de 24 heures, avec un maximum de 10 000 enregistrements dans chaque lot.

Ainsi, le maximum théorique est de 50 millions d'enregistrements chargés en 24 heures.

Dans un projet réel, le maximum est bien inférieur en raison de la taille de lot limitée lors de l'utilisation, par exemple, de déclencheurs personnalisés.

Cela a un fort impact sur l'approche de migration des données.

Même pour des ensembles de données de taille moyenne (de 100 000 à 1 million de comptes), l'approche du big bang est hors de question, nous devons donc diviser les données en vagues de migration plus petites.

Ceci, bien sûr, a un impact sur l'ensemble du processus de déploiement et augmente la complexité de la migration, car nous ajouterons des incréments de données dans un système déjà rempli par les migrations précédentes et les données saisies par les utilisateurs.

Il faut également tenir compte de ces données existantes dans les transformations de migration et les validations.

De plus, des charges longues peuvent signifier que nous ne pouvons pas effectuer de migrations pendant une panne du système.

Si tous les utilisateurs sont situés dans un pays, nous pouvons tirer parti d'une panne de huit heures pendant la nuit.

Mais pour une entreprise comme Coca-Cola, qui opère dans le monde entier, ce n'est pas possible. Une fois que nous avons les États-Unis, le Japon et l'Europe dans le système, nous couvrons tous les fuseaux horaires, donc le samedi est la seule option de panne qui n'affecte pas les utilisateurs.

Et cela peut ne pas suffire, nous devons donc charger en ligne , lorsque les utilisateurs travaillent avec le système.

7. Respecter les besoins de migration dans le développement d'applications

Les composants d'application, tels que les validations et les déclencheurs, doivent être capables de gérer les activités de migration de données. La désactivation matérielle des validations au moment du chargement de la migration n'est pas une option si le système doit être en ligne. Au lieu de cela, nous devons implémenter une logique différente dans les validations des modifications effectuées par un utilisateur de migration de données.

• Les champs de date ne doivent pas être comparés à la date système réelle car cela désactiverait le chargement des données historiques. Par exemple, la validation doit permettre de saisir une date de début de compte passée pour les données migrées.
• Les champs obligatoires, qui ne peuvent pas être remplis avec des données historiques, doivent être implémentés comme non obligatoires, mais avec une validation sensible à l'utilisateur, permettant ainsi des valeurs vides pour les données provenant de la migration, mais rejetant les valeurs vides provenant d'utilisateurs réguliers via l'interface graphique .
• Les déclencheurs, en particulier ceux qui envoient de nouveaux enregistrements à l'intégration, doivent pouvoir être activés/désactivés pour l'utilisateur de la migration de données afin d'éviter d'inonder l'intégration de données migrées.

Une autre astuce consiste à utiliser le champ Legacy ID ou Migration ID dans chaque objet migré. Il y a deux raisons à cela. La première est évidente : conserver l'identifiant de l'ancien système pour revenir en arrière ; Une fois les données dans le nouveau système, les utilisateurs peuvent toujours vouloir rechercher leurs comptes à l'aide des anciens identifiants, trouvés dans des endroits tels que les e-mails, les documents et les systèmes de suivi des bogues. Mauvaise habitude? Peut-être. Mais les utilisateurs vous remercieront si vous conservez leurs anciens identifiants. La deuxième raison est technique et vient du fait que Salesforce n'accepte pas les identifiants fournis explicitement pour les nouveaux enregistrements (contrairement à Microsoft Dynamics) mais les génère lors du chargement. Le problème se pose lorsque nous voulons charger des objets enfants car nous devons leur attribuer les ID des objets parents. Comme nous ne connaîtrons ces identifiants qu'après le chargement, il s'agit d'un exercice futile.

Utilisons les comptes et leurs contacts, par exemple :

1. Générer des données pour les comptes.
2. Chargez des comptes dans Salesforce et recevez les identifiants générés.
3. Incorporer de nouveaux identifiants de compte dans les données de contact.
4. Générer des données pour les contacts.
5. Charger des contacts dans Salesforce.

Nous pouvons le faire plus simplement en chargeant les comptes avec leurs identifiants hérités stockés dans un champ externe spécial. Ce champ peut être utilisé comme référence parent, donc lors du chargement des contacts, nous utilisons simplement l'ID hérité du compte comme pointeur vers le compte parent :

1. Générez des données pour les comptes, y compris l'ancien ID.
2. Générez des données pour les contacts, y compris l'ancien ID de compte.
3. Chargez des comptes dans Salesforce.
4. Chargez les contacts dans Salesforce, en utilisant l'ancien ID de compte comme référence parent.

La bonne chose ici est que nous avons séparé une génération et une phase de chargement, ce qui permet un meilleur parallélisme, une diminution du temps d'indisponibilité, etc.

8. Soyez conscient des fonctionnalités spécifiques de Salesforce

Comme tout système, Salesforce comporte de nombreuses parties délicates dont nous devons être conscients afin d'éviter les mauvaises surprises lors de la migration des données. Voici quelques exemples :

• Certaines modifications sur les utilisateurs actifs génèrent automatiquement des notifications par e-mail aux e-mails des utilisateurs. Ainsi, si nous voulons jouer avec les données des utilisateurs, nous devons d'abord désactiver les utilisateurs et les activer une fois les modifications terminées. Dans les environnements de test, nous brouillons les e-mails des utilisateurs afin que les notifications ne soient pas déclenchées du tout. Étant donné que les utilisateurs actifs consomment des licences coûteuses, nous ne sommes pas en mesure d'avoir tous les utilisateurs actifs dans tous les environnements de test. Nous devons gérer des sous-ensembles d'utilisateurs actifs, par exemple, pour activer uniquement ceux dans un environnement de formation.
• Les utilisateurs inactifs, pour certains objets standard tels que Compte ou Incident, ne peuvent être affectés qu'après avoir accordé l'autorisation système "Mettre à jour les enregistrements avec les propriétaires inactifs", mais ils peuvent être affectés, par exemple, aux contacts et à tous les objets personnalisés.
• Lorsque Contact est désactivé, tous les champs de désactivation sont activés en silence.
• Lors du chargement d'un objet Membre d'équipe de compte ou Partage de compte en double, l'enregistrement existant est écrasé en mode silencieux. Cependant, lors du chargement d'un partenaire d'opportunité en double, l'enregistrement est simplement ajouté, ce qui donne un doublon.
• Les champs système, tels que Created Date de création , Created By ID , Last Modified Date , Last Modified By ID , ne peuvent être explicitement écrits qu'après avoir accordé une nouvelle autorisation système "Définir les champs d'audit lors de la création de l'enregistrement".
• Les modifications de valeur de l'historique des champs ne peuvent pas du tout être migrées.
• Les propriétaires des articles de la base de connaissances ne peuvent pas être spécifiés lors du chargement, mais peuvent être mis à jour ultérieurement.
• La partie délicate est le stockage du contenu (documents, pièces jointes) dans Salesforce. Il existe plusieurs façons de le faire (en utilisant des pièces jointes, des fichiers, des pièces jointes de flux, des documents), et chaque façon a ses avantages et ses inconvénients, y compris différentes limites de taille de fichier.
• Les champs de liste de sélection obligent les utilisateurs à sélectionner l'une des valeurs autorisées, par exemple, un type de compte. Mais lors du chargement de données à l'aide de l'API Salesforce (ou de tout outil basé dessus, tel qu'Apex Data Loader ou le connecteur Informatica Salesforce), n'importe quelle valeur passera.

La liste est longue, mais l'essentiel est le suivant : familiarisez-vous avec le système et apprenez ce qu'il peut faire et ce qu'il ne peut pas faire avant de faire des suppositions. Ne supposez pas un comportement standard, en particulier pour les objets principaux. Toujours rechercher et tester.

9. N'utilisez pas Salesforce comme plate-forme de migration de données

Il est très tentant d'utiliser Salesforce comme plate-forme pour créer une solution de migration de données, en particulier pour les développeurs Salesforce. C'est la même technologie pour la solution de migration de données que pour la personnalisation de l'application Salesforce, la même interface graphique, le même langage de programmation Apex, la même infrastructure. Salesforce a des objets qui peuvent agir comme des tables, et une sorte de langage SQL, Salesforce Object Query Language (SOQL). Cependant, veuillez ne pas l'utiliser ; ce serait un défaut architectural fondamental.

Salesforce est une excellente application SaaS avec de nombreuses fonctionnalités intéressantes, telles qu'une collaboration avancée et une personnalisation riche, mais le traitement de masse des données n'en fait pas partie. Les trois raisons les plus importantes sont :

• Performances – Le traitement des données dans Salesforce est plusieurs fois plus lent que dans RDBMS.
• Manque de fonctionnalités analytiques – Salesforce SOQL ne prend pas en charge les requêtes complexes et les fonctions analytiques qui doivent être prises en charge par le langage Apex, et dégraderait encore plus les performances.
• Architecture * – Placer une plateforme de migration de données dans un environnement Salesforce spécifique n'est pas très pratique. Habituellement, nous avons plusieurs environnements à des fins spécifiques, souvent créés ad hoc afin que nous puissions consacrer beaucoup de temps à la synchronisation du code. De plus, vous dépendriez également de la connectivité et de la disponibilité de cet environnement Salesforce spécifique.

Au lieu de cela, créez une solution de migration de données dans une instance distincte (il peut s'agir d'un cloud ou sur site) à l'aide d'une plate-forme RDBMS ou ETL. Connectez-le aux systèmes sources et ciblez les environnements Salesforce de votre choix, déplacez les données dont vous avez besoin dans votre zone de staging et traitez-les là-bas. Cela vous permettra de :

• Tirez parti de toute la puissance et des capacités du langage SQL ou des fonctionnalités ETL.
• Conservez tout le code et toutes les données au même endroit afin de pouvoir exécuter des analyses sur tous les systèmes.
  • Par exemple, vous pouvez combiner la configuration la plus récente de l'environnement de test Salesforce le plus récent avec des données réelles de l'environnement de production Salesforce.
• Vous n'êtes pas si dépendant de la technologie des systèmes source et cible et vous pouvez réutiliser votre solution pour le prochain projet.

10. Surveillance des métadonnées Salesforce

Au début du projet, nous récupérons généralement une liste de champs Salesforce et commençons l'exercice de mappage. Au cours du projet, il arrive souvent que de nouveaux champs soient ajoutés par l'équipe de développement d'applications dans Salesforce, ou que certaines propriétés de champs soient modifiées. Nous pouvons demander à l'équipe d'application d'informer l'équipe de migration des données de chaque modification du modèle de données, mais cela ne fonctionne pas toujours. Pour être sûr, nous devons avoir toutes les modifications du modèle de données sous supervision.

Pour ce faire, une méthode courante consiste à télécharger régulièrement des métadonnées pertinentes pour la migration depuis Salesforce dans un référentiel de métadonnées. Une fois que nous avons cela, nous pouvons non seulement détecter les changements dans le modèle de données, mais nous pouvons également comparer les modèles de données de deux environnements Salesforce.

Quelles métadonnées télécharger :

• Une liste d'objets avec leurs étiquettes et noms techniques et attributs tels que creatable ou updatable .
• Une liste de champs avec leurs attributs (mieux vaut tous les avoir).
• Une liste de valeurs de liste de sélection pour les champs de liste de sélection. Nous en aurons besoin pour cartographier ou valider les données d'entrée pour les valeurs correctes.
• Une liste de validations, pour s'assurer que les nouvelles validations ne créent pas de problèmes pour les données migrées.

Comment télécharger des métadonnées depuis Salesforce ? Eh bien, il n'y a pas de méthode de métadonnées standard, mais il existe plusieurs options :

• Générer Enterprise WSDL - Dans l'application Web Salesforce, accédez au menu Setup / API et téléchargez Enterprise WSDL fortement typé, qui décrit tous les objets et champs dans Salesforce (mais pas les valeurs de liste de sélection ni les validations).
• Appelez le service web Salesforce describeSObjects , directement ou en utilisant Java ou C# wrapper (consultez l'API Salesforce). De cette façon, vous obtenez ce dont vous avez besoin, et c'est la méthode recommandée pour exporter les métadonnées.
• Utilisez l'un des nombreux outils alternatifs disponibles sur Internet.

Préparez-vous pour la prochaine migration de données

Les solutions cloud, telles que Salesforce, sont prêtes instantanément. Si vous êtes satisfait des fonctionnalités intégrées, connectez-vous simplement et utilisez-les. Cependant, Salesforce, comme toute autre solution CRM cloud, apporte des problèmes spécifiques aux sujets de migration de données à prendre en compte, notamment en ce qui concerne les performances et les limites des ressources.

Déplacer les données héritées dans le nouveau système est toujours un voyage, parfois un voyage vers l'histoire caché dans les données des années passées. Dans cet article, basé sur une douzaine de projets de migration, j'ai présenté dix conseils pour migrer des données héritées et éviter avec succès la plupart des pièges.

La clé est de comprendre ce que les données révèlent. Ainsi, avant de commencer la migration des données, assurez-vous que votre équipe de développement Salesforce est bien préparée aux problèmes potentiels que vos données peuvent contenir.