Migration Salesforce : Data Import Wizard, Data Loader, Bulk API 2.0 ou ETL ?

La documentation Salesforce présente cinq façons différentes d'importer des données. Le problème n'est pas de les trouver — c'est de savoir laquelle choisir selon le volume, le niveau de compétence technique disponible et le degré d'automatisation souhaité. Ce guide présente les cinq outils avec leur tableau de décision, leurs limites réelles et les configurations qui font la différence.

Les cinq outils de migration Salesforce

• Data Import Wizard : outil graphique natif dans Salesforce Setup. Prend en charge les objets standards (Contacts, Leads, Comptes, Opportunités, membres de Campagne). Limite : 50 000 enregistrements par lot. Aucune compétence technique requise.
• Data Loader : application desktop (Windows / macOS). Prend en charge tous les objets, y compris les objets personnalisés. Recommandé pour des volumes de 5 000 à 5 millions d'enregistrements. Peut fonctionner en mode Bulk API pour les gros volumes.
• Bulk API 2.0 : API REST asynchrone de Salesforce dédiée aux gros volumes. Traite les données par lots, optimisée pour les insertions / mises à jour massives sans saturer les limites API synchrones. Accessible via Data Loader, Salesforce CLI ou tout client HTTP.
• Salesforce CLI (sf) : ligne de commande officielle Salesforce. La commande sf data upsert bulk permet d'exécuter des opérations Bulk API 2.0 directement depuis un terminal ou un script CI/CD. Idéale pour automatiser une migration reproductible.
• ETL / iPaaS (MuleSoft, Informatica, Talend) : solution pour les migrations complexes impliquant plusieurs systèmes sources, des transformations importantes ou une synchronisation continue post-migration.

Tableau de décision

• Volume < 50k, objets standards, pas de compétences techniques → Data Import Wizard
• Volume 50k–5M, tous objets, administrateur Salesforce → Data Loader (mode Bulk)
• Volume > 1M, automatisation requise, pipeline CI/CD → Bulk API 2.0 via Salesforce CLI
• Plusieurs sources, transformations complexes, budget intégration → ETL / MuleSoft
• Migration org-to-org (configurations + données) → Metadata API + Data Loader combinés

Data Loader en mode Bulk API

Par défaut, Data Loader utilise l'API REST standard (200 enregistrements par lot). Pour les migrations importantes, il faut activer le mode Bulk API dans les paramètres de Data Loader. En mode Bulk, Data Loader envoie les données en lots asynchrones de plusieurs milliers d'enregistrements, ce qui réduit considérablement le temps de migration et la consommation de limites API journalières.

Paramètre clé à configurer dans Data Loader Settings → Use Bulk API. Note importante : Bulk API ne déclenche pas les triggers Apex ni les règles de validation complexes par défaut. Si votre org contient des triggers critiques (déduplication, calculs automatiques, synchronisations tierces), tester en sandbox avec un jeu de données représentatif est indispensable avant la migration en production.

Salesforce CLI et Bulk API 2.0

La commande Salesforce CLI pour une migration par upsert en Bulk API 2.0 :

• sf data upsert bulk --sobject Account --file accounts.csv --external-id External_ID__c --wait 10
• --sobject : l'objet Salesforce cible (Account, Contact, Opportunity, ou tout objet custom)
• --file : le fichier CSV source (encodage UTF-8 obligatoire)
• --external-id : le champ marqué External ID pour l'opération upsert (insert si absent, update si présent)
• --wait : temps d'attente en minutes avant timeout (mettre 0 pour mode asynchrone avec polling manuel)

L'opération upsert est fondamentale pour les migrations : elle vérifie si un enregistrement avec cet External ID existe déjà dans Salesforce. Si oui : mise à jour. Si non : création. Cela rend la migration idempotente — relancer la commande deux fois ne crée pas de doublons.

L'External ID : le concept clé

L'External ID est un champ personnalisé marqué comme tel dans Salesforce (cochez 'External ID' dans la définition du champ). Il stocke l'identifiant de l'enregistrement dans le système source (ID client ERP, ID contact ancien CRM, etc.). Trois usages critiques pendant une migration :

• Upsert sans doublon : Salesforce sait si l'enregistrement doit être créé ou mis à jour.
• Reconstruction des relations : lors de l'import des Contacts, vous pouvez référencer l'Account parent via son External ID au lieu de son Salesforce ID (qui n'existe pas encore lors de la première migration).
• Traçabilité post-migration : conserver le legacy_id dans un champ External ID permet de retrouver facilement l'enregistrement d'origine en cas de question ou de litige.

Ordre de migration des objets Salesforce

L'ordre d'import est aussi important que la méthode. Salesforce ne peut pas rattacher un Contact à un Account qui n'existe pas encore.

• 1. Users (ou mapping des propriétaires existants)
• 2. Accounts (comptes)
• 3. Contacts
• 4. Leads (si séparés des contacts)
• 5. Opportunities
• 6. Opportunity Products (OpportunityLineItem)
• 7. Cases et Service Cloud objects
• 8. Activities (Tasks, Events) — toujours en dernier car elles se rattachent à presque tous les objets

Réconciliation après migration Salesforce

Après l'import, ne pas se contenter de vérifier que le nombre total de lignes correspond. Valider également : tous les Contacts ont un AccountId renseigné (pas de contact orphelin), toutes les Opportunities ont un StageName valide et un AccountId, les OwnerId pointent vers des utilisateurs actifs, les champs montant (Amount) et date (CloseDate) sont dans des plages cohérentes, les enregistrements rejetés par Bulk API ont été analysés et traités.

Pour les migrations d'une org Salesforce vers une autre avec préservation des relations et des métadonnées, consultez : Migrer vers Salesforce — comment préserver les IDs, les relations et les métadonnées