Une Salesforce est rarement ce à quoi on s'attend au départ. Les équipes la planifient comme un simple transfert de données, mais découvrent qu'elle implique également la structuration, la gestion des responsabilités et la vérification de l'exactitude des informations. Une mauvaise planification peut entraîner des mois de correction d'enregistrements erronés, de dates manquantes et d'agents inactifs apparaissant encore dans les rapports.
Ce guide présente le plan précis que notre équipe a utilisé avec plus de 40 000 entreprises ayant migré vers Agentforce Service (Salesforce) via Help Desk Migration depuis 2016. Il couvre les cinq phases, l'ordre de chargement, les compromis entre les outils (importation manuelle de CSV, Salesforce Data Loader, Skyvia, Help Desk Migrationet services gérés), des échéanciers réalistes et le travail de validation qui déterminera si votre premier Salesforce se déroulera sereinement ou dans la panique.
Si votre système source est un service d'assistance comme Zendesk, Freshdesk, Intercom, HelpDeskou Dixa, une section dédiée apparaît vers la fin du guide. Ce processus suit des règles différentes d'une migration CRM versSalesforce , et la plupart des guides génériques l'omettent.
TL;DR
- Une migration de données Salesforce transfère les clients, les tickets, les articles de la base de connaissances et la configuration d'un système existant vers Salesforce Service Cloud ou Sales Cloud en cinq phases : définition du périmètre, préparation, mappage, migration et validation.
- L'outil de migration approprié dépend du volume de données et du système source : CSV manuel pour les petits transferts, Salesforce Data Loader ou un outil de migration automatisé pour Zendesk, Freshdesk, Intercom, HelpDeskou Dixa.
- L'ordre de migration est important : Comptes → Contacts → Opportunités/Dossiers → Activités → Pièces jointes. Si vous sautez une étape, votre structure de données sera corrompue.
- La plupart des migrations Salesforce prennent de quelques heures à quelques jours avec l'assistant de migration automatisé de Help Desk Migration, et non des semaines.
- Une démo gratuite migre 20 cas et articles réels dans votre environnement de test Salesforce afin que vous puissiez valider le mappage des champs avant de payer pour la migration complète.
Qu'est-ce que la migration de données Salesforce ?
Salesforce La migration de données consiste à transférer les enregistrements (clients, contacts, requêtes, pièces jointes, articles de la base de connaissances et objets personnalisés) d'un système source vers Salesforce Sales Cloud ou Service Cloud. Elle comprend l'extraction, le nettoyage, le mappage des champs, le chargement et la validation des données après migration.
Vous aurez généralement besoin de l'un de ces éléments :
- Une migration à partir de zéro — votre équipe découvre Salesforce et importe les données initiales à partir de feuilles de calcul, d'un CRM existant ou d'un service d'assistance.
- Un changement de plateforme — passer de Zendesk, Freshdesk, HubSpot, ServiceNowou d'un autre CRM à Salesforce.
- de Salesforce Classic vers Lightning — une mise à niveau de l'interface utilisateur et du modèle de données au sein Salesforce.
- Consolidation d'organisations — fusion de deux ou plusieurs Salesforce suite à une acquisition.
Ce guide se concentre sur les deux premiers points — la plupart des lecteurs prévoient de passer d'une autre plateforme de support technique à Salesforce.
Votre plan de migration de données Salesforce en 5 phases
Les grands cabinets de conseil proposent des plans en 10 étapes. En réalité, cinq étapes seulement déterminent si vous migrerez des données clients propres ou si vous passerez votre premier mois à corriger des problèmes.
Phase 1 — Portée et inventaire
Commencez par compter les enregistrements, sans tenir compte des champs. Comptez les tickets, les contacts, les comptes, les pièces jointes, les articles de la base de connaissanceset les éléments personnalisés de chaque source. Notez l'ancienneté des enregistrements : les données de plus de 3 à 5 ans n'ont généralement pas besoin d'être déplacées.
Le résultat de cette étape est un tableau indiquant le nombre d'enregistrements et une décision écrite sur les éléments à déplacer (« nous migrons les clients actifs, les dossiers des 3 dernières années et l'intégralité de la base de connaissances »).
Phase 2 — Nettoyage et préparation des données
Nettoyez vos données avant de les transférer, pas après. Une fois les données erronées dans Salesforce, des processus automatiques s'exécutent à chaque modification et les utilisateurs commencent à travailler. Corriger les problèmes en cours d'exécution est coûteux. Supprimez les contacts en double, renseignez les champs obligatoires, supprimez les enregistrements de test, archivez les requêtes fermées et inactives et décidez du sort des agents inactifs.
Utilisez Help Desk Migrationde Salesforce la checklist de migration des données. Elle comporte 47 points et permet de détecter la plupart des problèmes avant la migration.
Phase 3 — Cartographie sur le terrain
Créez un document de mappage. Chaque champ source est affiché sur une ligne avec son nom, son type, l'objet Salesforce correspondant, le nom du champ cible, les modifications requises et la personne responsable.
La plupart des projets échouent discrètement à ce stade. Les types de champs Salesforce sont stricts. Un champ de texte libre « Statut » dans Zendesk doit correspondre à une valeur de liste de sélection Salesforce déjà présente dans votre système. Créez d'abord les valeurs de la liste de sélection, puis associez-les.
Phase 4 — Migration (essai, puis complète)
Commencez par une migration de démonstration en déplaçant 20 tickets et articles choisis au hasard. Validez les résultats de la migration et identifiez les enregistrements ou champs corrompus. Testez l'ensemble des modifications sur un petit jeu de données facile à manipuler avant de les appliquer aux données réelles. Lancez ensuite la migration complète des données.
Avec Help Desk Migration, la version pilote est la migration de démonstration gratuite : elle s’exécute automatiquement, utilise des enregistrements réels provenant de votre source et les importe dans votre Salesforce . Vous pouvez également l’exécuter dans un environnement de test (Sandbox) afin d’éviter de mélanger les enregistrements réels et les enregistrements de test.
Phase 5 — Validation et surveillance post-migration
Avant la mise en production : comptez les enregistrements dans la source et la cible, vérifiez 20 enregistrements pour vous assurer des champs , confirmez le bon fonctionnement des recherches, exécutez un rapport d’exemple et comparez-le à la source. Après la mise en production, surveillez pendant deux semaines l’apparition d’enregistrements manquants, d’automatisations défaillantes et de baisses de la qualité des données.
Planifiez une migration delta pour les dernières heures avant la bascule — elle synchronise tous les enregistrements créés ou mis à jour dans la source pendant votre validation.
Comparaison des outils de migration de données Salesforce
Il existe trois principaux types d'outils de migration de données Salesforce : l'importation manuelle de fichiers CSV , les outils intégrés Salesforce et les services automatisés tiers. Le choix de la meilleure option dépend du volume de vos données, de leur provenance et du niveau d'assistance technique dont vous disposez.
| Approche | Idéal pour | Rapidité | Coût | effort technique | Éléments du service d'assistance (base de connaissances, conversations parallèles, images intégrées) | Démo gratuite |
| Importation manuelle CSV via l'assistant d'importation de données | Moins de 50 000 enregistrements, schéma simple | Lent (heures par objet) | Gratuit | Niveau intermédiaire : vous créez manuellement des fichiers CSVet des tables de correspondance | Reconstruction manuelle requise | Non |
| Chargeur de données Salesforce / Atelier | Transfert d'organisation à organisation ou de CRM versSalesforce, jusqu'à 5 millions d'enregistrements par objet | Moyen | Gratuit | Niveau élevé — nécessite des compétences en administration/développement | Reconstruction manuelle requise | Non |
| Skyvia (ETL/iPaaS) | Pour les équipes qui souhaitent un outil de pipeline de données à long terme, et non une simple migration ponctuelle | Moyen | 79 $ à 159 $/mois (la cartographie avancée nécessite le niveau Standard) | Medium — interface utilisateur Web en libre-service | Large mais manuel — la base de connaissances et les conversations annexes nécessitent des packages séparés | Forfait gratuit, 10 000 enregistrements/mois |
| Services de gestion/de conseil | Entreprises aux schémas complexes, industries réglementées | Lent (4 à 12 semaines de découverte + exécution) | Frais de projet de plus de 15 000 $ | Bas — ils font le travail | Inclus dans le service | Test en environnement de test uniquement |
| Help Desk Migration (HDM) | Migration d'un système de support technique (Zendesk, Freshdesk, Intercom, HelpDesk, Dixa) vers Salesforce Service Cloud | Rapide (de quelques heures à quelques jours) | Environ 1 600 $ à 2 000 $ en une seule fois pour 100 000 enregistrements | Faible — Assistant de migration automatisé, sans code | Couverture complète en une seule étape de l'Assistant de migration | Oui — données gratuites, automatiques et réelles |
Quelques remarques sincères sur les compromis.
L'utilisation manuelle CSV fichier d'un convient pour déplacer quelques milliers de contacts une seule fois. Cependant, cette méthode est peu pratique pour les données liées, les pièces jointes ou les informations importantes et anciennes.
Salesforce Data Loader est gratuit, mais c'est un outil d'administration, pas un outil de migration. Il permet de définir l'ordre de chargement, de reconstruire les relations entre les données et de gérer les erreurs. Il est utile pour les travaux de données réguliers, mais peu pratique pour une importation de données ponctuelle avec une échéance.
Skyvia est une plateforme ETL adaptable. Si vous recherchez un outil unique pour la migration depuis Agentforce Service, la synchronisation des données d'entrepôt et le traitement continu des données, c'est une solution intéressante. En revanche, pour l'importation depuis Agentforce Service, chaque élément (base de connaissances, conversations annexes, copies et images intégrées) nécessite son propre package de migration. Il est également nécessaire de mapper manuellement le champ `created_at` à Salesforceafin de conserver les horodatages. Prévoyez 4 à 6 packages et quelques jours de travail pour le mappage.
Help Desk Migration est une solution native conçue spécifiquement pour ce type de tâche. L'assistant de migration gère en une seule opération les tickets, les commentaires publics/privés, les articles de la base de connaissances, les conversations parallèles, les destinataires en copie, les images intégrées, les pièces jointes, les agents, les organisations et les clients. Les horodatages, les anciens identifiants et les statuts sont automatiquement conservés. La tarification est unique et par enregistrement, avec une courbe non linéaire qui dégressif en fonction du volume.
Ordre de chargement des objets : pourquoi les dépendances sont importantes
Les enregistrements Salesforce présentent des dépendances parent-enfant. Si vous les chargez dans le désordre, vos recherches échoueront : le contact se charge, mais son account_id ne pointe vers rien, et le service Agentforce le définit silencieusement sur null.
Ordre de chargement standard pour une migration Sales Cloud :
- Comptes (parent de presque tout le reste)
- Contacts (nécessite un compte)
- Câbles (indépendants — peuvent être chargés en parallèle avec les contacts)
- Opportunités (nécessitent un compte et généralement des contacts)
- Activités (Tâches, Événements — pointer vers Comptes/Contacts/Opportunités)
- Pièces jointes / Fichiers (indiquez l'un des éléments ci-dessus)
Pour une migration Service Cloud depuis un centre d'assistance, l'ordre équivalent est le suivant :
- Utilisateurs / Agents (pour que les billets aient des propriétaires valides)
- Comptes / Organisations
- Contacts / Clients
- Dossiers (l'équivalent des tickets) — avec commentaires publics et internes
- Articles de connaissances
- Pièces jointes et images intégrées
Combien de temps dure une migration de données Salesforce ?
La migration de données Salesforce peut prendre de quelques heures à 8-16 semaines. Le facteur déterminant n'est pas le choix de l'outil, mais le volume d'enregistrements, le nombre de champs personnalisés, la complexité de l'intégration et le temps que l'entreprise consacre à la validation.
Calendrier prévisionnel de la migration du service Agentforce avec Help Desk Migration:
- SMB (moins de 50 000 enregistrements): 4 à 24 heures de temps d'exécution de la migration ; 2 à 3 jours au total, y compris le travail préparatoire et la vérification des résultats de la migration.
- Migration de taille moyenne (50 000 à 500 000 enregistrements): 1 à 3 jours de temps d'exécution de la migration ; généralement 1 à 2 semaines.
- Migration d'entreprise (plus de 500 000 enregistrements): 2 à 7 jours de temps d'exécution de la migration ; 2 à 6 semaines au total, y compris les transferts progressifs et deux migrations Delta.
Un cabinet de conseil spécialisé vous proposera un délai de 8 à 16 semaines pour un projet d'envergure équivalente ; or, la majeure partie de ce temps est consacrée à la phase de découverte et d'évaluation, et non à la migration proprement dite. L'automatisation permet de réduire considérablement ce délai, car les tâches répétitives (détection des champs, mappage des schémas, gestion des erreurs) sont intégrées à l'outil.
Coût d'une migration de données Salesforce
Trois modèles de tarification dominent le marché : le paiement unique par enregistrement, l’abonnement mensuel et la prestation de services par projet. Leurs chiffres indicatifs sont comparables, mais leur coût total diffère considérablement.
- Le service de migration automatisé est facturé par enregistrement en fonction du volume migré. Le tarif Help Desk Migration de 100 000 enregistrements est d'environ 1 600 $ à 2 000 $ (paiement unique). Ce tarif diminue avec l'augmentation du volume.
- Les abonnements mensuels à des outils comme Skyvia ou Fivetran peuvent coûter entre 79 et 159 dollars par mois pour la version cartographique avancée. Ce modèle semble abordable au premier abord, mais une migration de données complexe peut prendre de trois à six mois, et l'abonnement continue d'être facturé par la suite.
- Les services par projet débutent à 15 000 $, les évaluations obligatoires coûtant entre 5 000 $ et 10 000 $. Un investissement judicieux si votre schéma est réellement complexe ; un gaspillage d’argent dans le cas contraire.
Un test utile consiste à calculer le coût total prévu sur toute la durée de la migration, et non pas seulement sur le premier mois. Les outils par abonnement semblent moins chers au mois, mais coûtent plus cher par projet pour un travail ponctuel.
meilleures pratiques de migration de données Salesforce
Sept règles tirées d'équipes ayant réalisé des migrations Salesforce sans problème.
- Nettoyez les données avant la migration, pas après. Les automatisations se déclenchent à chaque modification au sein du service Agentforce ; corriger des données erronées en cours de migration coûte 10 fois plus cher que de les corriger à la source.
- Cartographiez deux fois, migrez une seule fois. Faites établir les documents de cartographie par deux personnes indépendantes, puis conciliez les divergences. C'est dans les désaccords que se cachent les problèmes.
- Effectuez une migration d'essai sur des enregistrements réels. Les données de test synthétiques masquent les incohérences de types de champs. La démo gratuite utilise de véritables enregistrements provenant de votre plateforme source ; n'hésitez pas à l'essayer.
- Désactivez les règles de validation lors du chargement en masse. Utiles en production, elles peuvent s'avérer désastreuses lors d'un transfert de données. Désactivez-les pendant la migration, réactivez-les ensuite, puis effectuez une nouvelle validation.
- Effectuez la migration en dehors des heures de pointe. Même avec des outils garantissant une interruption de service, la concentration de votre équipe reste le principal facteur limitant. Lancez la migration finale lorsque votre activité ne sera pas perturbée par les opérations de validation.
- Documentez tout au fur et à mesure : chaque décision, chaque transformation, chaque solution de contournement. La prochaine migration ou l’audit vous en remerciera.
- Planifiez un audit post-mise en production au 14e jour. Deux semaines plus tard, exécutez les mêmes rapports sur la source et la cible. Les dérives, les orphelins et les automatisations défaillantes seront alors détectés.
Erreurs courantes lors de la migration Salesforce (et comment les éviter)
Six schémas que nous observons sans cesse dans les projets qui nous sont confiés en pleine crise.
- Ordre de chargement incorrect. Charger les contacts avant les comptes entraîne des résultats nuls lors des recherches. Solution : charger d’abord les éléments parents et vérifier leur nombre avant de passer à la couche suivante.
- Les données sources erronées contiennent des contacts en double, des champs obligatoires vides et des utilisateurs finaux supprimés. Solution : nettoyez les données avant la migration. La liste de contrôle de migration du service Agentforce couvre les problèmes courants.
- Aucun plan de restauration. Une migration irréversible oblige les entreprises à transférer des données corrompues, faute de quoi il faudra tout recommencer. Solution : effectuez une Salesforce avant le chargement et documentez la procédure de restauration.
- Les règles de validation et les déclencheurs peuvent dysfonctionner lors d'une migration complète. Ils ont été conçus pour la saisie de données une par une, et non pour le chargement de 100 000 enregistrements. Solution : désactivez-les temporairement pendant la migration complète, puis réactivez-les une fois celle-ci terminée.
- Mappage de champs personnalisés manquant. Une migration qui a « réussi » mais qui a supprimé 80 champs personnalisés est une migration ayant échoué, ce que les utilisateurs découvriront ultérieurement. Solution : Associez explicitement les champs personnalisés et vérifiez que les valeurs de la liste de sélection cible existent avant la migration complète.
- Aucune recette utilisateur avant la mise en production. « La migration s'est bien déroulée » ne constitue pas une validation. Solution : vérifier au moins 50 enregistrements et les comparer entre le service source et le service Agentforce. Ensuite, faire tester la plateforme cible par un utilisateur réel avant la bascule finale.
Migration d'une plateforme de support technique vers le service Agentforce
Les données du service d'assistance ne sont pas des données CRM. Les tickets, les conversations parallèles, les articles de la base de connaissances, l'historique des agents et le contexte du support client nécessitent un traitement différent de celui des comptes et des opportunités ; or, la plupart des guides de migration Salesforce génériques passent complètement sous silence cet aspect.
Voici la version courte par plateforme source. Chaque lien renvoie à la page de migration dédiée, qui comprend le tableau de correspondance des champs et un lien vers une démonstration gratuite.
De Zendesk
Migration de Zendesk vers Salesforce Service Cloud →
Voici comment les enregistrements Zendesk sont migrés vers Agentforce Service : les tickets Zendesk deviennent des requêtes Salesforce . Les commentaires publics deviennent des commentaires de requête, et les notes internes sont associées aux commentaires internes de requête. Les articles de la base de connaissances sont transférés vers Salesforce Knowledge, ainsi que les catégories et les sections. Les personnes en copie, les images intégrées et les pièces jointes sont également transférées. Les conversations parallèles sont transférées sous forme de commentaires privés. Les enregistrements d'appels sont migrés sous forme de pièces jointes MP3. Les agents sont associés à des utilisateurs Salesforce , et les clients deviennent des contacts.
De Freshdesk
Migration Freshdesk vers Salesforce Service Cloud →
Freshdesk deviennent des dossiers, tandis que les agents migrent en tant qu'utilisateurs vers le service Agentforce. Les notes publiques et privées sont converties en commentaires de dossiers. Les entreprises deviennent Salesforce ; les contacts restent des contacts. Concernant la migration de la base de connaissances, les catégories et les dossiers sont transformés en catégories de premier et de deuxième niveau.
Les champs personnalisés, les balises et les pièces jointes sont transférés. Les images intégrées sont migrées en tant que pièces jointes. De plus, vous pouvez également migrer les traductions de contenu et mettre à jour les liens internes entre les articles grâce à des options automatisées.
De la part de HelpDesk, Intercom, Dixaet autres
Voir toutes les sources prises en charge →
Le schéma de migration reste le même : les tickets deviennent des requêtes, les conversations des commentaires et le contenu de la base de connaissances devient une base de connaissances. Vous pouvez consulter les tableaux de correspondance et les exemples de flux sur la page de chaque paire de plateformes.
Étude de cas : Pandora
Découvrez comment Pandora a migré de Zendesk vers Salesforce →
Pandora, la plus grande marque de bijoux au monde, devait migrer des années de données de support client de Zendesk vers Agentforce Service (Salesforce Service Cloud) sans la moindre interruption de service. À cette échelle, la moindre perturbation aurait pu lui coûter des millions.
Le résultat ? Une transition fluide et sans interruption de service, offrant aux agents de Pandora une vue unifiée à 360 degrés de l'historique d'achats, des demandes de réparation et des interactions passées de chaque client.
Prêt à migrer vers Salesforce?
L'essentiel du travail lors d'une migration de données Salesforce consiste à prendre des décisions : périmètre, mappage, ordre de chargement et critères de validation. La migration proprement dite, si vous utilisez un outil automatisé capable de comprendre les données du service d'assistance, ne prend que quelques heures, et non des semaines.
Commencez par une migration de démonstration gratuite. Help Desk Migration transfère 20 enregistrements réels de votre source vers votre Salesforce Vous pourrez ainsi visualiser précisément l'apparence des tickets, commentaires, articles de la base de connaissances et pièces jointes dans Agentforce Service avant de vous engager dans la migration complète. Aucune carte de crédit ni appel commercial ne sont requis.
Vous avez un schéma complexe ou travaillez dans un secteur réglementé ? Contactez un expert en migration →
Foire aux questions
La migration de données Salesforce consiste à transférer les enregistrements (comptes, contacts, requêtes, opportunités, articles de la base de connaissances et objets personnalisés) d'un système source vers Salesforce Sales Cloud ou Salesforce Service Cloud. Elle comprend l'extraction, le nettoyage, le mappage des champs, le chargement et la validation des données. La plupart des équipes utilisent soit les outils natifs de Salesforce(Data Loader, Assistant d'importation de données), soit une plateforme de migration tierce comme Help Desk Migration.
La durée d'exécution de la migration varie de quelques heures pour les petits ensembles de données des PME à plusieurs jours pour les ensembles de données d'entreprise de plus de 500 000 enregistrements.
Dans le cadre Help Desk Migration, la durée totale du projet est généralement de 2 à 3 jours pour les PME, de 1 à 2 semaines pour les entreprises de taille intermédiaire et de 2 à 6 semaines pour les grandes entreprises. Les sociétés de conseil spécialisées annoncent quant à elles une durée de 8 à 16 semaines pour un projet similaire, car leur modèle inclut des phases d'analyse approfondies.
Salesforce propose Data Loader et l'Assistant d'importation de données comme outils natifs ; tous deux sont gratuits et nécessitent des droits d'administrateur. Pour les migrations depuis un système tiers, notamment un service d'assistance, des outils automatisés comme Help Desk Migration gèrent la traduction de schéma, le mappage des champs et les dépendances entre objets en une seule étape, y compris les articles de la base de connaissances, les conversations annexes et les images intégrées, autant d'éléments que les outils natifs vous obligent à recréer manuellement.
Les quatre types les plus courants sont la migration de stockage (déplacement de données entre un stockage physique et le cloud), la migration database (changement de moteur ou de schéma database ), la migration d'application (passage d'une plateforme logicielle à une autre, ce qui est généralement le cas pour la migration Salesforce ) et la migration de processus métier (déplacement de données accompagnant une modification du flux de travail). La plupart des projets de migration de services d'assistance versSalesforce sont des migrations d'application comportant également des éléments de migration database .
Effectuez un comptage des enregistrements dans la source et la cible pour chaque objet (comptes, contacts, requêtes, articles de la base de connaissances, pièces jointes) et corrigez les différences. Vérifiez l'exactitude des champs de 50 enregistrements, y compris les horodatages et les recherches. Générez un rapport d'exemple dans les deux systèmes et comparez les résultats de la migration. Avec Help Desk Migration, vous pouvez effectuer une migration de démonstration gratuite pour vérifier le mappage des champs sur des enregistrements réels avant de lancer la migration complète.
- Nettoyer les données sources avant le chargement.
- Testez une migration de démonstration avec de vrais enregistrements.
- Désactiver temporairement les règles de validation et les déclencheurs pendant la migration complète.
- Téléchargez les enregistrements dans l'ordre de dépendance (Comptes → Contacts → Dossiers → Pièces jointes).
- Effectuez un audit post-migration de 2 semaines pour repérer les incohérences et les problèmes d'automatisation.
- Planifiez une migration delta après la migration complète afin de ne transférer que les enregistrements nouveaux et mis à jour.
