Comment réussir une migration de données Salesforce

Réponse courte : une migration de données Salesforce se joue pendant la phase de qualité des données, des semaines avant le jour du chargement. Profilez les données source, décidez volontairement ce que vous ne reprendrez pas, cartographiez chaque champ avec un external ID derrière, puis répétez la bascule jusqu'à ce qu'elle devienne ennuyeuse. Le chargement est la partie facile, et ce n'est presque jamais lui qui échoue.

Pourquoi les migrations Salesforce échouent-elles vraiment ?

Rarement à cause du chargement. Data Loader, l'API Bulk et les outils ETL fonctionnent. Les échecs remontent à des décisions esquivées plus tôt :

• Aucun propriétaire nommé pour un domaine de données, donc personne ne pouvait valider une règle.
• Des doublons que tout le monde voyait et que personne n'a su trancher.
• Un champ source dont le sens a dérivé il y a des années et qui a été mappé sur son libellé.
• Un périmètre devenu discrètement "tout", parce que ne rien retirer semblait plus sûr que choisir.

Ces quatre points se corrigent à bas coût en semaine deux et deviennent brutaux la nuit de la bascule. C'est tout l'argument en faveur d'une qualité de données traitée en amont.

Que signifie profiler, concrètement ?

Profiler, c'est mesurer, pas inspecter. Avant qu'une seule ligne de mapping soit écrite, produisez des chiffres pour chaque objet source :

• Taux de remplissage par champ. Un champ rempli dans 4% des enregistrements n'est pas un champ, c'est une rumeur.
• Valeurs distinctes face à la liste de sélection cible. C'est là que "Prospect", "prospect" et "PROSPECT " deviennent trois valeurs et une discussion.
• Taux de doublons sur la clé de rapprochement envisagée. Mesurez-le avant de choisir la clé, pas après.
• Taux d'orphelins sur chaque relation. Les enregistrements enfants sans parent résolvable déterminent votre ordre de chargement et votre volume d'erreurs.
• Taux de résolution des propriétaires. Quelle proportion pointe vers un utilisateur Salesforce actif, et qui récupère le reste.
• Plages de dates et valeurs aberrantes. Un enregistrement daté de 1900 ou 2099 heurtera une règle de validation au pire moment.

Le livrable est un court rapport de profilage. Son vrai rôle est de transformer des opinions en chiffres, pour que les discussions de périmètre se terminent par une décision plutôt que par une réunion.

Que faut-il décider de ne pas migrer ?

C'est la décision au plus fort effet de levier et celle que la plupart des plans omettent. Chaque enregistrement a quatre destins possibles, et un seul coûte cher :

1. Migrer. Il est nécessaire opérationnellement, dans Salesforce, à un processus identifié.
2. Résumer. L'historique compte en agrégé, pas ligne par ligne. Chargez un cumul, pas dix ans de transactions.
3. Archiver. Conservez-le dans un entrepôt ou en export pour la conformité, hors du CRM.
4. Laisser. Gardez le système historique en lecture seule pendant une période définie pour les consultations.

Réglages par défaut raisonnables : les enregistrements clos antérieurs à votre horizon de reporting sont résumés, les contacts sans activité ni e-mail joignable sont archivés, et les champs de texte libre sur lesquels personne ne reporte ne passent pas du tout. Chaque enregistrement exclu retire du mapping, des erreurs de validation, des cas de test et du support après la mise en service. Réduire le périmètre est le gain de performance le moins cher à votre disposition.

Comment bâtir un mapping qui survit au contact des données ?

Une ligne par champ cible, portant chacune : champ source, règle de transformation, valeur par défaut, propriétaire, validation à passer, et date de validation de la décision. Une ligne sans propriétaire n'est pas un mapping, c'est un espoir.

Deux choix techniques déterminent le calme du reste du projet :

• Posez un external ID sur chaque objet chargé. Il porte la clé du système historique, ce qui résout les relations parent-enfant sans identifiants Salesforce, rend les chargements idempotents via upsert et sécurise toute reprise. Sans lui, chaque relance risque de créer des doublons.
• Choisissez la clé de rapprochement avant d'écrire la moindre transformation. E-mail, numéro fiscal, identifiant historique ou clé composée. Le rapport de profilage dit laquelle est réellement unique dans vos données.

Actez ensuite par écrit quelle automatisation est suspendue pendant le chargement et qui la réactive : règles de validation, triggers, flows, règles d'attribution, règles de doublons et alertes e-mail. Un e-mail de bienvenue involontaire à 40 000 contacts migrés est la version classique de cette erreur.

Combien de répétitions, et que mesurer ?

Trois au minimum, dans une sandbox proche de la production.

1. Passage de forme. Est-ce que cela charge, tout simplement ? Types de champs, champs obligatoires, valeurs de listes, types d'enregistrement.
2. Passage de justesse. Validez les relations plutôt que les volumes. Des totaux corrects avec des parents cassés est le mode d'échec le plus rassurant de toute la discipline.
3. Passage chronomètre. Volume complet, mesure de bout en bout, pour que la fenêtre de bascule soit un chiffre observé et non estimé.

Conservez chaque journal d'erreurs et suivez le taux d'erreur comme une tendance. Si le troisième passage n'est pas nettement plus propre que le premier, le mapping ne converge pas et la date de mise en service est une fiction.

Que contient le plan de bascule ?

Un plan de bascule est une séquence avec des horaires et un responsable par ligne, pas un récit :

1. Geler le système source et annoncer le gel aux utilisateurs, pas seulement au canal projet.
2. Prendre l'extraction delta finale.
3. Suspendre l'automatisation figurant sur la liste convenue.
4. Charger les parents avant les enfants, dans l'ordre déclaré, par vagues qui isolent les erreurs.
5. Réactiver l'automatisation et confirmer chaque élément un par un.
6. Lancer les requêtes de réconciliation : volumes par objet, contrôles d'orphelins, vérifications sur des enregistrements nommés choisis à l'avance par le métier.
7. Validation du métier sur ces enregistrements, puis go ou no-go.
8. Dégeler, ou exécuter le rollback.

Définissez le rollback avant la nuit de bascule, quand c'est encore une question de conception et non une panique. En pratique : garder le système historique faisant foi et en lecture seule jusqu'à la validation, et conserver un external ID sur chaque enregistrement migré pour permettre une suppression ciblée ou un rechargement complet. Puis staffez correctement les 48 à 72 premières heures, car les questions du premier jour révèlent ce que le rapport de profilage a manqué.

Nous menons les migrations ainsi dans nos projets Salesforce, et c'est en partie ainsi que nous avons mis 20+ organisations en production. Si vous en cadrez une et voulez un second avis sur les données avant d'engager une date, commencez ici.

FAQ

Combien de temps prend une migration de données Salesforce ?

Le chargement prend des heures. Le projet dure le temps des décisions de qualité de données, et c'est pourquoi c'est le passage chronomètre, pas le planning, qui doit fixer la fenêtre de bascule.

Faut-il nettoyer dans le système source ou pendant le chargement ?

Dans la source, là où sont les propriétaires, autant que possible. Les règles de transformation cachées dans un script sont invisibles pour le métier et rediscutées après la mise en service.

Les external IDs sont-ils utiles si l'on ne migre qu'une fois ?

Oui. Ils sécurisent les reprises, résolvent les relations sans identifiants Salesforce et rendent possibles un rollback ou un rechargement cible plus tard.

Quelle profondeur d'historique reprendre ?

Uniquement ce qu'utilise un processus ou un rapport identifié. Résumez le reste et archivez le solde hors du CRM : l'historique est la première source de dérive de périmètre dans ces projets.