Migrer son CRM vers HubSpot : le guide pas à pas pour réussir

Résumer cet article

Changer de CRM n’est pas le plus compliqué. Le plus compliqué, c’est ce qu’on emporte avec soi : des fiches en double, des champs que personne ne remplit, des statuts qui ne veulent plus rien dire. Importez tout cela dans HubSpot tel quel et vous obtiendrez un nouvel outil aussi peu fiable que l’ancien. Ce guide s’adresse à ceux qui préparent la migration : Sales Ops, RevOps, marketing, DSI. Il suit l’ordre d’un vrai projet, du cadrage à l’arrêt de l’ancien outil, que vous veniez de Salesforce, Dynamics, Zoho, Pipedrive, Sellsy ou d’un simple fichier Excel.

1. Cadrer le projet

Le piège classique tient en une phrase : « on migre tout, on verra après ». Une demi-journée de cadrage évite des semaines de reprise. Cinq décisions à prendre dès le départ.

1. Le périmètre : quels objets, et quelle profondeur d’historique ? Notre réflexe : ne reprendre que ce qui servira dans les 12 à 24 prochains mois.
2. La source de vérité : quel système fait foi pendant le projet, et jusqu’à quelle date ? L’ancien CRM passe en lecture seule à la bascule.
3. L’équipe : un sponsor, un chef de projet, un référent par métier, un profil technique pour les extractions. Sans référent métier, personne ne tranche sur les champs.
4. Le calendrier : évitez les fins de trimestre et prévoyez deux migrations à blanc au minimum.
5. Le succès, chiffré : par exemple, toutes les transactions ouvertes migrées avec leur entreprise, leur contact et leur propriétaire ; moins de 1 % d’écart sur le nombre de fiches ; pipeline ouvert identique à l’euro près.

Trois questions d’architecture méritent aussi d’être réglées tôt, car elles changent tout le reste. Les objets standards suffisent-ils, ou faut-il des objets personnalisés (selon l’édition) ? HubSpot doit-il rester synchronisé avec un ERP ou une boutique en ligne ? Qui garde l’accès à l’ancien CRM, et jusqu’à quand ?

Comptez de quelques semaines pour une petite équipe à plusieurs mois pour une structure multi-équipes avec historique et intégrations (ordre de grandeur, à valider après l’audit). La phase la plus souvent sous-estimée est le nettoyage.

Un exemple de ce que donne un bon cadrage : l’éditeur PakEnergy, né de quatre acquisitions, avait des équipes régionales dispersées et mettait 28 jours en moyenne à répondre à un prospect. Son passage de Salesforce à HubSpot a commencé par un audit des processus et par l’adhésion de la direction, avant tout import. Trois mois plus tard, ce délai était de 6,8 jours. Ces résultats sont publiés par l’agence qui a mené le projet : ils montrent l’intérêt du cadrage, sans promettre le même gain chez vous.

2. Auditer l’ancien CRM

Avant de décider quoi migrer, il faut savoir ce qu’on a vraiment. L’audit produit un inventaire chiffré, qui servira ensuite de référence pour contrôler la migration.

En pratique, exportez chaque objet en CSV complet, identifiants techniques compris, et analysez-les dans un tableur ou avec un petit script : taux de remplissage par colonne, valeurs distinctes, dates de dernière modification. Une fiche qu’on n’a pas touchée depuis trois à cinq ans et qui n’a aucune transaction est une bonne candidate à l’archivage.

Une règle ne souffre aucune exception : conservez l’identifiant d’origine de chaque fiche dans une propriété HubSpot dédiée (par exemple « ID ancien CRM »). C’est lui qui permet de relier les objets entre eux, de rejouer un import sans créer de doublons et de contrôler les écarts après coup.

3. Nettoyer et dédoublonner avant d’importer

Nettoyer

C’est l’étape qui rapporte le plus. Un doublon importé dans HubSpot se multiplie vite : des associations, des activités et des listes viennent se greffer dessus, et la fusion devient délicate. Nettoyez donc dans vos fichiers d’extraction, pas dans le portail.

L’ordre qui marche : retirer les fiches mortes (tests, fiches vides, comptes fermés depuis longtemps), uniformiser les formats, harmoniser les valeurs, corriger dates et montants, puis dédoublonner. Le tableau suivant montre ce que cela donne sur quelques champs (données fictives).

La dernière ligne est un classique : 3/4/26 veut dire le 3 avril en France et le 4 mars aux États-Unis. Un fichier qui mélange les deux conventions produit des dates fausses sans aucune erreur visible.

Repérer les doublons

Chaque objet a sa clé la plus fiable.

HubSpot dédoublonne nativement les contacts sur l’e-mail et les entreprises sur le nom de domaine : à l’import, une ligne qui porte une clé déjà présente met à jour la fiche existante au lieu d’en créer une seconde. Mais une entreprise sans domaine ou un contact sans e-mail n’a pas cette protection. Il faut alors une autre clé.

Pour les doublons « flous » (un nom écrit de deux façons, une filiale, une faute de frappe), un outil d’IA ou un script de rapprochement approximatif propose des paires avec un score de similarité. Vous validez les cas douteux, le reste passe en masse.

Côté entreprises françaises, les sources ouvertes font gagner un temps précieux. L’API Recherche d’Entreprises retrouve gratuitement SIREN, SIRET, code NAF, tranche d’effectif et adresse du siège. Le SIREN devient alors une clé d’unicité solide, à garder dans une propriété dédiée. Chez Synolia, nous avons automatisé ce travail : un traitement lit les mentions légales du site de chaque entreprise du CRM, en extrait le SIREN, le vérifie auprès de l’annuaire officiel, calcule un niveau de confiance et n’écrit dans HubSpot que les cas sûrs. Il a été conçu pour environ 35 000 entreprises françaises.

Pourquoi ne pas nettoyer après l’import ? Parce que la fusion en masse dans HubSpot est réservée aux éditions qui incluent Data Hub (à vérifier selon votre abonnement), et parce qu’une fusion est irréversible.

4. Cartographier le modèle de données

Le mapping est le document central du projet : il dit, champ par champ, d’où vient l’information et où elle arrive. Construisez-le avec les référents métier, pas seul dans votre coin.

Commencez par les objets. Les correspondances sont simples, avec quelques points d’attention.

Vient ensuite le travail fin, propriété par propriété. Une ligne de mapping dit au minimum quel est le champ source, quel est le champ HubSpot cible, quelle transformation appliquer et quelle valeur mettre par défaut.

Voici à quoi cela ressemble pour une transaction (exemple fictif) :

Quelques types de champs posent systématiquement problème. Les listes déroulantes d’abord : chaque valeur source doit exister dans HubSpot, écrite exactement pareil. Les champs calculés ensuite, qui ne se migrent pas et qu’on recrée. Les sélections multiples enfin, qui s’importent sous forme de valeurs séparées par des points-virgules. Et pour les montants, décidez de la devise avant d’importer.

Les pipelines se migrent rarement à l’identique, et c’est tant mieux : profitez-en pour simplifier, avec cinq à sept étapes, des critères de sortie clairs et une probabilité par étape. Préparez la correspondance entre anciennes et nouvelles étapes, y compris pour les transactions déjà gagnées ou perdues.

Dernier point, les statuts de cycle de vie : rapprochez vos anciens statuts (prospect, lead qualifié, client, ancien client) des étapes HubSpot. Par défaut, HubSpot n’accepte que la progression du cycle de vie. Pour importer une étape plus ancienne que l’actuelle, il faut d’abord vider la propriété sur les fiches concernées (comportement à vérifier dans la documentation avant le premier import).

5. Préparer le portail HubSpot

Un import ne réussit que si la destination est prête. Si votre édition le permet, faites cette préparation dans un portail de test (sandbox) : vous pourrez rejouer les imports autant que nécessaire sans toucher à la production.

• Les propriétés : créez celles qui manquent, avec le bon type et des listes de valeurs fermées. Soignez les noms internes, ils ne se changent pas ensuite.
• L’identifiant d’origine : une propriété « ID ancien CRM » par objet, déclarée en valeur unique. HubSpot refusera alors tout doublon dessus, et elle servira de clé pour mettre à jour des fiches existantes.
• Les pipelines et les cycles de vie, avant d’importer transactions et tickets.
• Les utilisateurs et les équipes : une fiche ne peut être affectée qu’à un utilisateur qui existe. Pour les anciens collaborateurs, prévoyez un propriétaire générique.
• Les droits : limitez l’import, l’export et la fusion à quelques personnes.
• Les effets de bord : désactivez les workflows qui envoient des e-mails, les notifications et les synchronisations pendant les imports. Un import massif peut inscrire des milliers de contacts dans un workflow en quelques minutes.

Avant tout gros import, faites un export de sauvegarde des objets concernés : cela vous donne un point de retour si le mapping réserve une surprise. Attention aussi au statut marketing des contacts : ils sont facturés selon l’édition, n’y mettez que ceux qui doivent l’être.

6. Choisir sa méthode de migration

Il existe quatre grandes façons de faire. Le bon choix dépend du volume, de la complexité du modèle et de l’historique à reprendre.

Notre règle de pouce : pour quelques dizaines de milliers de fiches sans particularité, l’import natif suffit largement. Dès qu’il y a des objets personnalisés, beaucoup d’associations ou un historique à reprendre, l’API est la voie la plus sûre, parce qu’elle permet de rejouer, de tracer et de corriger ligne à ligne. Beaucoup de projets combinent les deux.

Quelques habitudes à prendre quelle que soit la méthode : un fichier par objet, avec l’identifiant d’origine et la clé d’unicité ; de l’UTF-8 pour garder les accents ; un premier lot test de 50 à 100 lignes représentatives, contrôlé fiche par fiche ; le bon mode d’import (création pour le premier passage, mise à jour pour les corrections, les deux pour rejouer sans doublon) ; et un journal de ce qui a été importé, quand et par qui.

Deux cas réels montrent ce que cela donne. Pour une société de technologie financière américaine qui quittait un Salesforce mature, leur partenaire HubSpot a migré par étapes, avec des points de validation et une synchronisation à sens unique pendant la transition : 63 017 enregistrements, associations et historique d’activités conservés, en moins de trois mois. Chez MECAD, partenaire SOLIDWORKS, il fallait fusionner deux instances Salesforce dont les fiches se recoupaient : l’agence a importé la plus importante d’abord, puis la seconde en veillant à ne créer aucun doublon. Retenez le réflexe : quand plusieurs sources fusionnent, on importe la plus fiable en premier, et les suivantes en mise à jour plutôt qu’en création.

7. L’ordre d’import et les cas particuliers

L’ordre compte : on ne peut pas associer une transaction à une entreprise qui n’existe pas encore. La séquence qui limite les erreurs :

1. Utilisateurs, équipes, propriétés et pipelines.
2. Entreprises, puis contacts.
3. Produits, si vous reprenez un catalogue.
4. Transactions et tickets, avec leurs associations.
5. Objets personnalisés.
6. Activités : notes, appels, réunions, tâches, e-mails.
7. Documents et pièces jointes, en dernier.

Plusieurs cas particuliers méritent qu’on s’y arrête :

• L’historique : l’import natif sait créer des notes, des appels, des e-mails et des réunions rattachés à des fiches, à condition de fournir le contenu et, de préférence, la date de l’activité (sinon HubSpot utilise la date d’import). Demandez-vous quand même ce que vaut cet historique : trois ans de notes consultables servent plus que dix ans de traces que personne ne relira. Pour les e-mails, la connexion de la messagerie de chaque commercial à HubSpot journalisera les échanges futurs, sans rien importer.
• Les propriétaires : ils doivent exister dans HubSpot avant l’import. Pour les fiches de collaborateurs partis, décidez d’une règle : propriétaire générique, responsable d’équipe ou file de réaffectation.
• Les consentements : c’est le point le plus sensible sur le plan juridique. Migrez avec chaque contact son statut d’abonnement, la date et la source de son consentement. Un désinscrit réimporté comme abonné vous expose à une plainte et à un vrai problème de réputation. En cas de doute sur la validité d’un consentement, mieux vaut le considérer comme non acquis. Ce n’est pas un avis juridique : faites valider par votre DPO.
• Les dates et les sources d’origine : HubSpot horodate une fiche à la date de son import. Si l’ancienneté compte pour vos rapports, gardez la date de création et la source d’origine de chaque contact dans des propriétés dédiées, sans quoi vos rapports d’attribution repartiront de zéro.
• Les intégrations : reconnectez l’ERP, le site e-commerce, la facturation et les formulaires après l’import, pas avant : une synchronisation lancée trop tôt crée des doublons que vous venez de passer des semaines à éviter.

8. Tester, recetter, basculer

Une migration se répète avant de se réaliser. Le but est que le jour J ne soit que la troisième exécution d’un processus déjà rodé.

1. Une première migration à blanc sur un échantillon de 5 à 10 % des données, cas limites compris. Elle vérifie le mapping, les formats et les associations.
2. Une seconde sur le volume complet, dans le portail de test si possible. On mesure la durée réelle, on traite les erreurs, et les référents métier font la recette.
3. La migration finale, après gel de l’ancien CRM, suivie d’un delta : les fiches créées ou modifiées entre la dernière extraction et la bascule.

Après chaque passe, les mêmes contrôles :

Le jour de la bascule se déroule toujours de la même façon : on prévient tout le monde de la fenêtre de gel, on passe l’ancien CRM en lecture seule, on extrait, on importe, on contrôle, on importe le delta, puis on réactive workflows et intégrations un par un avant d’ouvrir HubSpot aux utilisateurs. Définissez aussi à l’avance le retour arrière : tant que la recette finale n’est pas signée, l’ancien CRM reste la référence, et vous savez quelles conditions déclenchent un retour.

Planifiez plutôt en début de semaine qu’un vendredi : l’équipe projet sera là pour absorber les premiers retours.

9. Après la bascule

La migration n’est réussie que si les équipes utilisent HubSpot tous les jours. Les quatre semaines qui suivent la bascule comptent plus que les mois de préparation.

La première semaine, restez en permanence : un point quotidien de 15 minutes avec les référents métier, un circuit simple pour remonter les anomalies, des corrections rapides. Les deux semaines suivantes, formez par métier, en partant de la journée type d’un commercial, d’un marketeur ou d’un agent du support, avec des vues et des tableaux de bord déjà prêts. La quatrième semaine, mesurez les critères de réussite fixés au cadrage et décidez des ajustements.

Ensuite, il faut que la base reste propre, et c’est là que beaucoup de projets se relâchent. Une base impeccable le jour J se dégrade vite : la donnée B2B vieillit en continu, et chaque formulaire, import ou intégration est une porte d’entrée pour les doublons. Reprenez les bonnes pratiques de gouvernance : champs obligatoires, valeurs normalisées, listes de contrôle, un responsable de la donnée et une revue mensuelle sur quelques indicateurs. Mieux encore, profitez de la migration pour automatiser : enrichissement continu depuis les sources ouvertes, détection des doublons, normalisation par workflow.

N’éteignez pas l’ancien CRM le jour de la bascule. Gardez-le en lecture seule pendant une durée décidée à l’avance (un à trois mois en général), faites une archive complète des données et des pièces jointes dans un stockage sécurisé, vérifiez les obligations de conservation liées à votre activité, puis résiliez en respectant le préavis.

10. Les erreurs classiques et la check-list

Sept erreurs reviennent presque à chaque fois :

1. Tout migrer, y compris les champs morts et les fiches obsolètes : le nouveau CRM naît déjà encombré.
2. Nettoyer après l’import, ce qui coûte plus cher et expose à des fusions irréversibles.
3. Perdre l’identifiant d’origine, et ne plus pouvoir rejouer un import ni contrôler les écarts.
4. Oublier les automatisations actives : des e-mails partent vers des milliers de contacts.
5. Négliger les consentements, avec des désinscrits réimportés comme abonnés.
6. Sauter la répétition et découvrir les erreurs de mapping devant les utilisateurs.
7. Oublier l’humain : sans formation ni référents, les équipes retournent à leurs tableurs.

Conclusion : faire de la migration un levier, pas une contrainte

Une migration vers HubSpot bien menée ne se contente pas de déplacer des données. Elle remet le modèle à plat, assainit la base et pose les fondations d’un CRM que les équipes ont envie d’utiliser. Les règles tiennent en peu de mots : cadrer, auditer, nettoyer avant d’importer, garder les identifiants d’origine, répéter à blanc, puis faire vivre.

Chez Synolia, nous accompagnons les entreprises à chaque étape : audit de l’ancien CRM, modèle de données cible, nettoyage et enrichissement automatisés, scripts de migration rejouables, recette, bascule et formation des équipes. Nous misons sur l’IA et l’automatisation pour que la qualité des données ne soit pas un chantier ponctuel mais un fonctionnement durable.

Vous préparez une migration ? Parlons-en !
Contactez-nos experts HubSpot