Comment reussir une migration de donnees Salesforce

Reponse courte : une migration de donnees Salesforce se joue pendant la phase de qualite des donnees, des semaines avant le jour du chargement. Profilez les donnees source, decidez volontairement ce que vous ne reprendrez pas, cartographiez chaque champ avec un external ID derriere, puis repetez la bascule jusqu'a ce qu'elle devienne ennuyeuse. Le chargement est la partie facile, et ce n'est presque jamais lui qui echoue.

Pourquoi les migrations Salesforce echouent-elles vraiment ?

Rarement a cause du chargement. Data Loader, l'API Bulk et les outils ETL fonctionnent. Les echecs remontent a des decisions esquivees plus tot :

• Aucun proprietaire nomme pour un domaine de donnees, donc personne ne pouvait valider une regle.
• Des doublons que tout le monde voyait et que personne n'a su trancher.
• Un champ source dont le sens a derive il y a des annees et qui a ete mappe sur son libelle.
• Un perimetre devenu discretement "tout", parce que ne rien retirer semblait plus sur que choisir.

Ces quatre points se corrigent a bas cout en semaine deux et deviennent brutaux la nuit de la bascule. C'est tout l'argument en faveur d'une qualite de donnees traitee en amont.

Que signifie profiler, concretement ?

Profiler, c'est mesurer, pas inspecter. Avant qu'une seule ligne de mapping soit ecrite, 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 a la liste de selection cible. C'est la que "Prospect", "prospect" et "PROSPECT " deviennent trois valeurs et une discussion.
• Taux de doublons sur la cle de rapprochement envisagee. Mesurez-le avant de choisir la cle, pas apres.
• Taux d'orphelins sur chaque relation. Les enregistrements enfants sans parent resolvable determinent votre ordre de chargement et votre volume d'erreurs.
• Taux de resolution des proprietaires. Quelle proportion pointe vers un utilisateur Salesforce actif, et qui recupere le reste.
• Plages de dates et valeurs aberrantes. Un enregistrement date de 1900 ou 2099 heurtera une regle de validation au pire moment.

Le livrable est un court rapport de profilage. Son vrai role est de transformer des opinions en chiffres, pour que les discussions de perimetre se terminent par une decision plutot que par une reunion.

Que faut-il decider de ne pas migrer ?

C'est la decision au plus fort effet de levier et celle que la plupart des plans omettent. Chaque enregistrement a quatre destins possibles, et un seul coute cher :

1. Migrer. Il est necessaire operationnellement, dans Salesforce, a un processus identifie.
2. Resumer. L'historique compte en agrege, pas ligne par ligne. Chargez un cumul, pas dix ans de transactions.
3. Archiver. Conservez-le dans un entrepot ou en export pour la conformite, hors du CRM.
4. Laisser. Gardez le systeme historique en lecture seule pendant une periode definie pour les consultations.

Reglages par defaut raisonnables : les enregistrements clos anterieurs a votre horizon de reporting sont resumes, les contacts sans activite ni e-mail joignable sont archives, 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 apres la mise en service. Reduire le perimetre est le gain de performance le moins cher a votre disposition.

Comment batir un mapping qui survit au contact des donnees ?

Une ligne par champ cible, portant chacune : champ source, regle de transformation, valeur par defaut, proprietaire, validation a passer, et date de validation de la decision. Une ligne sans proprietaire n'est pas un mapping, c'est un espoir.

Deux choix techniques determinent le calme du reste du projet :

• Posez un external ID sur chaque objet charge. Il porte la cle du systeme historique, ce qui resout les relations parent-enfant sans identifiants Salesforce, rend les chargements idempotents via upsert et securise toute reprise. Sans lui, chaque relance risque de creer des doublons.
• Choisissez la cle de rapprochement avant d'ecrire la moindre transformation. E-mail, numero fiscal, identifiant historique ou cle composee. Le rapport de profilage dit laquelle est reellement unique dans vos donnees.

Actez ensuite par ecrit quelle automatisation est suspendue pendant le chargement et qui la reactive : regles de validation, triggers, flows, regles d'attribution, regles de doublons et alertes e-mail. Un e-mail de bienvenue involontaire a 40 000 contacts migres est la version classique de cette erreur.

Combien de repetitions, 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 plutot que les volumes. Des totaux corrects avec des parents casses est le mode d'echec le plus rassurant de toute la discipline.
3. Passage chronometre. Volume complet, mesure de bout en bout, pour que la fenetre de bascule soit un chiffre observe et non estime.

Conservez chaque journal d'erreurs et suivez le taux d'erreur comme une tendance. Si le troisieme 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 sequence avec des horaires et un responsable par ligne, pas un recit :

1. Geler le systeme 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 declare, par vagues qui isolent les erreurs.
5. Reactiver l'automatisation et confirmer chaque element un par un.
6. Lancer les requetes de reconciliation : volumes par objet, controles d'orphelins, verifications sur des enregistrements nommes choisis a l'avance par le metier.
7. Validation du metier sur ces enregistrements, puis go ou no-go.
8. Degeler, ou executer le rollback.

Definissez le rollback avant la nuit de bascule, quand c'est encore une question de conception et non une panique. En pratique : garder le systeme historique faisant foi et en lecture seule jusqu'a la validation, et conserver un external ID sur chaque enregistrement migre pour permettre une suppression ciblee ou un rechargement complet. Puis staffez correctement les 48 a 72 premieres heures, car les questions du premier jour revelent ce que le rapport de profilage a manque.

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

FAQ

Combien de temps prend une migration de donnees Salesforce ?

Le chargement prend des heures. Le projet dure le temps des decisions de qualite de donnees, et c'est pourquoi c'est le passage chronometre, pas le planning, qui doit fixer la fenetre de bascule.

Faut-il nettoyer dans le systeme source ou pendant le chargement ?

Dans la source, la ou sont les proprietaires, autant que possible. Les regles de transformation cachees dans un script sont invisibles pour le metier et rediscutees apres la mise en service.

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

Oui. Ils securisent les reprises, resolvent 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 identifie. Resumez le reste et archivez le solde hors du CRM : l'historique est la premiere source de derive de perimetre dans ces projets.