Migrer vers Salesforce : comment préserver les relations, l'historique et les métadonnées

Vous pouvez migrer 100 % de vos Accounts, 100 % de vos Contacts et 100 % de vos Opportunities — et rater la migration Salesforce. Parce qu'une migration Salesforce réussie n'est pas seulement une question de données. C'est la convergence de quatre problèmes distincts : la gestion des identifiants, la reconstruction des relations, la préservation de l'historique, et la migration des métadonnées (configurations, objets personnalisés, Flows, règles, permissions). Cet article traite les quatre.

Problème 1 — La gestion des IDs Salesforce

Lors d'une migration d'une org Salesforce vers une autre (ou depuis un autre CRM vers Salesforce), les enregistrements reçoivent de nouveaux Salesforce IDs dans l'org cible. Un Account qui avait l'ID 001XXXXXXXXXXXX dans l'org source aura un ID complètement différent dans l'org cible. Si vos processus externes (ERP, scripts, appels API) référençaient les anciens IDs, ils sont immédiatement cassés après la migration.

La solution est de créer une table de correspondance (ID mapping table) entre les anciens et les nouveaux IDs, et/ou de stocker l'ID original dans un champ personnalisé External ID (exemple : Legacy_Salesforce_ID__c). Cette approche permet trois choses : retrouver l'enregistrement d'origine en cas de litige, utiliser l'External ID comme clé de réconciliation post-migration, et reconstruire les relations entre objets sans connaître les nouveaux Salesforce IDs à l'avance.

Problème 2 — External ID et upsert pour reconstruire les relations

L'External ID est probablement le concept le plus sous-utilisé dans les migrations Salesforce. Il transforme une migration fragile (qui dépend de l'ordre exact des imports et des IDs en temps réel) en une migration robuste et reproductible.

Principe de l'upsert avec External ID : si un enregistrement avec la valeur External_ID__c = '458792' existe déjà dans Salesforce, Data Loader / Bulk API le met à jour. Sinon, il le crée. Résultat : la migration est idempotente — relancer l'import ne crée pas de doublons.

Mais l'usage le plus puissant des External IDs concerne la reconstruction des relations parent-enfant. Lors de l'import des Contacts, vous n'avez pas besoin de connaître le Salesforce ID du Account parent. Salesforce accepte une notation de relation par External ID dans le fichier CSV : Account.External_ID__c. Data Loader résout lui-même la correspondance entre l'External ID et le vrai Salesforce ID du Account.

Structure CSV avec référence par External ID

• Colonne FirstName : prénom du contact
• Colonne LastName : nom du contact
• Colonne Email : email du contact
• Colonne Account.External_ID__c : l'External ID du compte parent (pas son Salesforce ID)
• Salesforce résout la relation automatiquement lors de l'import

Problème 3 — L'ordre d'import et les relations en cascade

L'ordre de migration des objets n'est pas optionnel. Un Contact importé avant que son Account parent n'existe dans l'org cible sera soit rejeté, soit créé sans AccountId — ce qui le rend orphelin. Les objets orphelins sont extrêmement difficiles à récupérer proprement après la migration.

• 1. Users — les propriétaires (Owner) doivent exister avant tous les objets.
• 2. Accounts — les comptes sont le socle de toutes les relations commerciales.
• 3. Contacts — rattachés à un Account via External ID.
• 4. Leads — si votre org sépare Leads et Contacts.
• 5. Opportunities — rattachées à un Account et optionnellement à un Contact.
• 6. Opportunity Products (OpportunityLineItem) — rattachés à une Opportunity.
• 7. Cases — rattachés à un Account et/ou un Contact.
• 8. Tasks et Events — toujours en dernier. Ils peuvent être rattachés à n'importe quel objet via WhoId (Contact / Lead) et WhatId (Account, Opportunity, Case…).

Problème 4 — Données ≠ Métadonnées

C'est la distinction la plus importante et la plus souvent ignorée. Vos données (enregistrements Account, Contact, Opportunity…) et vos métadonnées (objets personnalisés, champs, Flows, règles de validation, Apex classes, Lightning pages, Permission Sets, Custom Metadata…) sont deux entités séparées qui nécessitent deux méthodes de migration distinctes.

• Données → Data Loader, Bulk API, ETL : tout ce qui est enregistrement dans une table.
• Métadonnées → Metadata API, Salesforce CLI, Change Sets, DevOps Center : tout ce qui est configuration de l'org.

Schéma mental pour une migration Salesforce complète :

• DONNÉES : Accounts, Contacts, Opportunities, Cases, Leads, Activities, Custom Object records
• MÉTADONNÉES : Custom Objects (définitions), Custom Fields, Flows, Validation Rules, Apex Classes, Apex Triggers, Lightning Pages, Permission Sets, Profiles, Record Types, Custom Metadata Types, Custom Labels, Named Credentials

Migrer les métadonnées avec Salesforce CLI

Salesforce CLI est l'outil de référence pour déployer les métadonnées entre orgs. La commande sf project retrieve start récupère les métadonnées de l'org source dans un projet local versionnable. sf project deploy start les déploie vers l'org cible.

• sf project retrieve start --metadata ApexClass,Flow,ValidationRule,PermissionSet : récupère les métadonnées spécifiées depuis l'org source.
• sf project deploy start --target-org cible@entreprise.com : déploie le projet vers l'org cible.
• sf project deploy validate : valide le déploiement sans l'exécuter (dry run — fortement recommandé avant tout déploiement en production).

Change Sets (dans Salesforce Setup) déplacent également les métadonnées entre orgs connectées, mais sans contrôle de version ni intégration CI/CD. DevOps Center est la solution Salesforce pour les équipes qui veulent gérer les métadonnées dans un pipeline Git avec revue de code — il combine le contrôle de version et le déploiement Salesforce dans une interface intégrée.

Checklist migration Salesforce complète

• ☐ Champ External ID créé sur chaque objet migré (Account, Contact, Opportunity…)
• ☐ Table de correspondance Old ID → New ID préparée et archivée
• ☐ Métadonnées récupérées via sf project retrieve et versionnées dans Git
• ☐ Déploiement métadonnées validé en sandbox avant production
• ☐ Ordre d'import des objets respecté (Users → Accounts → Contacts → Opportunities → Activities)
• ☐ Migration pilote sur sandbox avec jeu de données complet
• ☐ Bulk API activé sur Data Loader pour les volumes > 50k
• ☐ Triggers Apex désactivés ou testés en sandbox (comportement Bulk API)
• ☐ Réconciliation post-migration : comptes orphelins, contacts sans Account, Opportunities sans Stage
• ☐ Vérification des systèmes externes qui référençaient les anciens Salesforce IDs

Pour choisir le bon outil entre Data Import Wizard, Data Loader et Bulk API selon votre volume, consultez : Migration Salesforce — Data Import Wizard, Data Loader, Bulk API ou ETL ?