Comment migrer ses données vers Salesforce sans rien perdre ?

1. Auditer les sources avant de choisir un outil

La première étape se passe dans les données sources. Pour chaque source, qu'il s'agisse d'un ancien CRM, d'un ERP, de fichiers Excel ou d'exports d'outils métier, on inventorie les objets, les volumes et les règles de gestion implicites.

• Volumes par objet et par source, et leur évolution sur les derniers mois.
• Clés d'identification : existe-t-il un identifiant stable pour chaque client, contact et contrat ?
• Qualité par champ : taux de valeurs vides, formats hétérogènes pour les dates, téléphones et pays, valeurs hors liste.
• Règles implicites : champs libres utilisés comme listes de valeurs, codes internes, conventions de saisie propres à une équipe.

Cet audit produit deux livrables : un inventaire chiffré des sources et une liste des risques, comme les données orphelines, les références cassées ou les doublons massifs. C'est sur cette base que l'on choisit les outils, et non l'inverse.

2. Fixer le périmètre : migrer, archiver ou abandonner

Tout ne mérite pas d'être migré. Pour chaque objet, on décide ce qui part dans Salesforce, ce qui est archivé dans un stockage consultable et ce qui est abandonné. La question à poser pour chaque catégorie : sert-elle un processus actuel, une obligation légale ou une analyse historique ?

Un critère de date est souvent le plus simple à appliquer, par exemple les comptes actifs et les opportunités des trois dernières années. Le reste est exporté, documenté et rendu accessible en lecture. Moins de données migrées, c'est moins de règles de transformation, une recette plus courte et un risque plus faible.

3. Construire le mapping champ par champ

Le mapping est le contrat de la migration. Pour chaque champ cible Salesforce, il documente la source, la transformation appliquée et la règle en cas de valeur absente. Les métiers le valident avec l'équipe technique.

• Objets standard d'abord : Account, Contact, Lead, Opportunity, Case, puis les objets personnalisés.
• Listes de valeurs : on aligne les picklists cibles avant de transformer les valeurs sources.
• Identifiants externes : un champ External ID par objet migré, pour permettre les upserts et le rapprochement avec le système d'origine.
• Relations : on documente l'ordre de chargement imposé par les lookups et les relations maître-détail.
• Propriétaires : chaque enregistrement doit être rattaché à un utilisateur actif ; les anciens collaborateurs sont remappés vers un propriétaire défini.
• Historique de création : la permission « Set Audit Fields upon Record Creation » permet de reprendre les dates et auteurs de création d'origine.
• Types d'enregistrement et devises : à fixer avant le chargement, car ils conditionnent les listes de valeurs et les montants.

4. Passer par un staging SQL

Charger directement les fichiers sources dans Salesforce est la meilleure façon de perdre le contrôle. Une base de staging, PostgreSQL ou SQL Server par exemple, reçoit chaque source telle quelle, puis la transforme par des vues ou des scripts versionnés.

Concrètement, le staging contient trois couches : les données brutes telles qu'importées, les tables transformées au format Salesforce, et les tables de résultat qui reçoivent les identifiants Salesforce créés. Cette troisième couche sert à résoudre les relations entre objets et à préparer un éventuel retour arrière.

Le staging permet aussi de rejouer les transformations autant de fois que nécessaire, de produire des rapports d'écart et de conserver la traçabilité entre un enregistrement Salesforce et sa ligne d'origine.

5. Dédoublonner avant de charger

Les doublons se traitent dans le staging, avec des règles explicites : clé exacte comme l'email ou le SIRET, puis rapprochements approximatifs sur le nom et l'adresse. Chaque fusion est journalisée. Les règles de doublons de Salesforce servent ensuite de filet de sécurité.

La méthode détaillée, avec les limites de la fusion native, est décrite dans le guide pour supprimer les doublons dans Salesforce.

6. Charger par lots, dans le bon ordre

Les chargements suivent les dépendances entre objets. Un ordre type :

• Utilisateurs, rôles et données de référence, comme les produits et les catalogues de prix.
• Comptes, puis contacts.
• Opportunités, puis leurs lignes de produits.
• Requêtes, contrats et objets personnalisés qui référencent les précédents.
• Activités, notes et fichiers en dernier, car ils pointent vers tout le reste.

Pour les volumes importants, l'API Bulk 2.0 est la voie normale ; Data Loader et les scripts s'appuient dessus. Pendant les chargements de masse, les automatisations lourdes sont contournées pour l'utilisateur de chargement, puis réactivées. Le choix de l'outil est détaillé dans le guide Data Loader ou script.

Chaque lot produit un journal : identifiants créés, erreurs par ligne, durée. Ces journaux alimentent le rapport de recette et servent de base au rollback.

7. Recetter avec les utilisateurs

La recette se déroule d'abord dans un sandbox Full ou Partial, sur une copie représentative des données, avant toute bascule en production. Elle combine des contrôles automatiques et des vérifications métier.

• Comptages source et cible par objet, avec une explication pour chaque écart.
• Contrôle des relations : chaque contact rattaché au bon compte, chaque opportunité au bon propriétaire.
• Échantillons choisis par les métiers, comparés champ par champ avec la source.
• Tests de processus : un commercial retrouve ses comptes, un rapport redonne les totaux attendus.

8. Basculer avec un plan de rollback

La bascule est planifiée à l'heure près : gel des saisies dans l'ancien système, dernier delta, chargement, contrôles, ouverture aux utilisateurs. Le plan de rollback décrit comment revenir en arrière si un contrôle échoue : sauvegarde préalable, scripts de suppression par identifiants de lot, critères de décision et personne habilitée à décider.

La période qui suit compte autant que la bascule : support renforcé pendant une à deux semaines, liste des anomalies remontées par les utilisateurs, corrections par lots journalisés.

Les erreurs les plus fréquentes

• Choisir l'outil avant d'avoir audité les données.
• Migrer tout l'historique par défaut, sans se demander à quoi il servira.
• Charger directement en production sans répétition complète en sandbox.
• Oublier les automatisations qui se déclenchent pendant le chargement : emails envoyés aux clients, tâches créées par milliers.
• Perdre le lien entre chaque enregistrement Salesforce et sa ligne d'origine, ce qui rend toute correction ultérieure hasardeuse.