En bref : une migration de Salesforce vers HubSpot se joue sur trois décisions : le périmètre d'historique repris, la méthode de reprise et l'ordre de chargement des objets. Les champs se mappent vite ; ce sont les associations et les activités qui déterminent la durée du projet.
Vous êtes DSI (directeur des systèmes d'information) ou directeur commercial d'une ETI ou d'une PME B2B française, votre renouvellement Salesforce approche et HubSpot est sur la table ? « Peut-on migrer ? » a une réponse connue : oui. La question utile est « que reprend-on, dans quel ordre, avec quelle méthode ? ». Voici comment nous la traitons en mission.
Les deux modèles de données se correspondent objet par objet sur l'essentiel. HubSpot documente cette correspondance dans son intégration native : leads et contacts Salesforce alimentent les contacts HubSpot, les comptes alimentent les entreprises, les opportunités alimentent les transactions, les requêtes (cases) alimentent les tickets.
Objet Salesforce |
Objet HubSpot |
Point de vigilance |
|---|---|---|
Lead et Contact |
Contact |
Deux objets Salesforce pour un seul objet HubSpot. La distinction lead/contact se rejoue avec une propriété de cycle de vie, à décider avant la reprise. |
Account |
Entreprise |
La hiérarchie de comptes (comptes parents) se remodélise avec les associations d'entreprises HubSpot et leurs libellés. |
Opportunity |
Transaction (deal) |
Les Record Types et les étapes d'opportunité se traduisent en pipelines et étapes HubSpot. C'est un arbitrage métier, pas une conversion automatique. |
Case |
Ticket |
À reprendre seulement si le service client bascule aussi. Sinon, on archive. |
Objet personnalisé |
Objet personnalisé |
Disponible sur les éditions HubSpot qui l'autorisent. Le schéma doit être créé avant tout chargement. |
Task, Event, EmailMessage |
Activités (tâches, réunions, e-mails) |
Le poste le plus lourd du projet. Voir la section dédiée plus bas. |
Ce que cette table ne dit pas : les champs se mappent en quelques ateliers, alors que les liens entre fiches — quel contact sur quelle opportunité, quelle activité sur quelle transaction — représentent le vrai travail. Comme pour une intégration ERP (progiciel de gestion intégré), la difficulté n'est jamais la donnée isolée : c'est la relation entre les données.
Trois voies existent, et elles se combinent volontiers.
Méthode |
Ce qu'elle reprend bien |
Sa limite |
Quand la choisir |
|---|---|---|---|
Export de fichiers puis import HubSpot |
Contacts, entreprises, transactions, objets personnalisés, et les associations déclarées dans le fichier. |
L'historique d'activités détaillé demande un travail de préparation important côté fichiers. |
Bascule nette, à date fixée, sans lien durable entre les deux systèmes. |
Intégration native Salesforce-HubSpot en pont temporaire |
La synchronisation continue des objets standards et des activités pendant la période de transition. |
Elle synchronise en continu ; elle n'est pas conçue pour charger en masse un historique ancien. Il faut aussi la débrancher proprement à la bascule. |
Migration progressive par équipe ou par région, avec les deux outils vivants quelques semaines. |
Reprise par API (interface de programmation) et middleware |
Les cas non standards : objets personnalisés complexes, règles de dédoublonnage spécifiques, volumes importants avec reprises partielles. |
Développement à cadrer, et écriture soumise aux règles de validation du portail. |
Modèle de données éloigné du standard, ou contrainte forte de traçabilité de la reprise. |
Une précision utile depuis cette rentrée : une reprise par API écrit des fiches CRM (gestion de la relation client), donc elle est soumise aux règles de validation configurées dans le portail. Depuis la version 2026-09 de l'API, un champ requis à la création ou une propriété conditionnellement obligatoire non renseignée renvoie une erreur plutôt qu'une fiche incomplète — mécanisme détaillé dans notre article sur les échéances API de la rentrée 2026. Conséquence pratique : chargez d'abord, durcissez les règles de saisie ensuite. Le contrôle qualité se fait alors sur le fichier source, en amont, et non sur le refus de l'API.
L'ordre de chargement décide de la quantité de reprises manuelles en fin de projet. HubSpot pose les associations à partir d'identifiants uniques présents dans chaque ligne du fichier d'import : une association ne se crée que si les deux fiches existent déjà, ou sont créées dans le même fichier.
Ces trois vérifications se font sur un lot réduit, quelques centaines de fiches représentatives, avant de lancer le chargement complet.
C'est la décision qui pèse le plus sur le budget, et elle appartient à la direction commerciale, pas à la DSI. Reprendre l'intégralité des e-mails, appels, tâches et réunions depuis l'origine du CRM est techniquement possible, et rarement le meilleur emploi du budget de migration.
La question à poser en atelier tient en une ligne : sur quel horizon un commercial consulte-t-il réellement l'historique d'un compte avant un rendez-vous ? La réponse fixe le périmètre. L'arbitrage que nous retenons le plus souvent : historique complet sur les comptes actifs et les affaires en cours, archive exportée et consultable hors CRM pour le reste.
Deux garde-fous. Un historique repris sans ses associations n'a aucune valeur d'usage : mieux vaut un périmètre plus court et correctement rattaché. Et la reprise d'un historique de communications reste un traitement de données personnelles, à aligner sur vos durées de conservation déclarées — cadre que détaille notre article sur la conformité RGPD dans HubSpot.
Le double run rassure, et il coûte deux fois. Trois repères pour le borner.
Fixez la date de bascule avant de commencer. Sans date, les équipes saisissent dans les deux outils, ce qui recrée les écarts que la migration devait supprimer. La fin de contrat Salesforce est un bon point d'ancrage, à condition de la connaître tôt.
Un seul système fait foi à la fois. Désignez explicitement, objet par objet, lequel porte la vérité pendant la transition. L'intégration native permet de tenir cette règle avec des directions de synchronisation choisies par propriété.
Prévoyez l'export final. Avant la fin du contrat, produisez un export de sauvegarde complet de Salesforce et rangez-le comme une archive documentée. Après la date de fin, cette extraction n'est plus disponible.
Une migration menée comme un transfert de données produit un CRM qui ressemble à l'ancien : mêmes propriétés inutilisées, mêmes étapes de pipeline que personne ne sait définir. Menée comme une décision de périmètre, elle produit un modèle de données choisi, un historique arbitré et des règles écrites.
C'est aussi la meilleure fenêtre pour poser les fondations d'une architecture de revenu (Revenue Architecture) : règles de pipeline, définition du MQL (marketing qualified lead, prospect qualifié par le marketing), identifiants clients dont dépendent le forecast et la facturation. Ces décisions sont simples à prendre sur un portail qu'on construit, coûteuses à imposer sur un portail en production.
Chez Uptoo Digital, partenaire HubSpot depuis plus de 10 ans, nous traitons ces migrations dans cet ordre : périmètre, modèle, reprise. Pour cadrer la vôtre sur vos volumes réels, réservons un atelier de cadrage (90 min, 290 €, déduit de la mission). Notre méthode est décrite sur la page implémentation et migration HubSpot, et le cadre général dans notre guide de la migration HubSpot pour les DSI.
Oui, en passant par une phase de transition. L'intégration native entre Salesforce et HubSpot synchronise les contacts, entreprises, transactions et tickets pendant que les équipes basculent, ce qui évite l'arrêt brutal. Elle sert de pont, pas de méthode de reprise historique : l'historique profond se charge en parallèle par import de fichiers ou par API, puis le pont est débranché à la date de bascule décidée.
Par des identifiants uniques présents dans chaque ligne du fichier d'import. Pour rattacher des contacts et des entreprises déjà présents dans le portail, HubSpot n'accepte que l'adresse e-mail principale et le domaine de l'entreprise comme identifiants. Une fiche associée à plusieurs autres se déclare en répétant la ligne, une association par ligne. C'est pourquoi l'ordre de chargement compte autant que le mapping des champs.
Ils se traduisent en pipelines et étapes HubSpot, mais la traduction n'est pas automatique. C'est un arbitrage à mener en atelier avec la direction commerciale : quels processus méritent un pipeline distinct, quelles étapes décrivent un fait vérifiable côté acheteur. Ce travail conditionne la lisibilité du forecast après bascule, et il est bien plus simple à mener avant le chargement des transactions qu'après.
C'est une décision de périmètre, pas une contrainte technique. Le critère utile : sur quel horizon vos commerciaux consultent réellement l'historique avant un rendez-vous. L'arbitrage que nous retenons le plus souvent consiste à reprendre l'historique complet sur les comptes actifs et les affaires en cours, et à conserver le reste en archive exportée hors CRM. Le périmètre retenu doit rester cohérent avec vos durées de conservation déclarées.
Oui, et c'est nouveau depuis la version 2026-09 de l'API. Les champs requis à la création et les propriétés conditionnellement obligatoires définis par vos administrateurs s'appliquent désormais aux écritures des intégrations. Sur une reprise, l'ordre recommandé est donc : charger les données historiques d'abord, durcir les règles de saisie ensuite. Testez systématiquement sur un lot réduit avant le chargement complet.
Uptoo Digital
Partenaire HubSpot Elite (~1 % des partenaires dans le monde), 650 projets livrés pour plus de 350 entreprises. Membre du groupe Uptoo.
Parlons de votre migration →