Données à migrer depuis HubSpot

Exporter vos données depuis l’interface HubSpot

Avant tout développement, HubSpot permet d’exporter chaque type d’objet en CSV depuis l’interface. C’est la première étape pour auditer vos données ou les transmettre à un prestataire.

Comment exporter depuis l’interface HubSpot

Dans le CRM, accédez à l’objet voulu (Contacts, Entreprises, Transactions, Tickets), puis cliquez Exporter depuis le haut de la liste. HubSpot génère un fichier CSV ou Excel avec les propriétés visibles dans la vue active.

Points d’attention avec l’export interface :

• Les vues filtrées n’exportent que les enregistrements visibles : exportez depuis une vue sans filtre actif pour récupérer l’intégralité des objets.
• Les associations ne sont pas incluses : l’export CSV d’un contact n’inclut pas le détail des transactions ou des tickets associés. Il contient toutefois un identifiant technique (ID) permettant de lier le contact aux autres objets, chaque entité devant être exportée séparément.
• Les propriétés masquées dans la vue ne sont pas exportées : sélectionnez “Toutes les propriétés” avant d’exporter.

Ce que l’export CSV ne couvre pas

Pour une migration complète, l’export CSV seul ne suffit pas. L’API REST HubSpot est nécessaire pour récupérer les activités, les associations entre objets et les listes actives avec leurs critères de filtrage.

---

Contacts et propriétés

Les contacts sont extraits via GET /crm/v3/objects/contacts avec pagination (10 par page par défaut, jusqu’à 100 par requête). HubSpot dispose de plus de 100 propriétés standard sur les contacts (firstname, lastname, email, phone, lifecyclestage, hs_lead_status…) en plus des propriétés personnalisées créées sur votre portail.

Propriétés standard à migrer

Propriété HubSpot	Correspondance cible
email	Identifiant unique du contact
firstname, lastname	Prénom, nom
phone, mobilephone	Téléphones
company	Nom de l’entreprise (texte libre, distinct de l’objet Company associé)
lifecyclestage	Étape du cycle de vie (lead, MQL, SQL, customer…)
hs_lead_status	Statut commercial (new, open, in_progress, qualified…)
createdate, lastmodifieddate	Timestamps à conserver pour l’historique

Étapes de cycle de vie

HubSpot utilise des lifecyclestage prédéfinis (subscriber, lead, marketingqualifiedlead, salesqualifiedlead, opportunity, customer, evangelist, other). Ces valeurs sont analysées et mappées vers les statuts équivalents dans le nouveau logiciel selon votre processus commercial.

---

Entreprises (companies)

Les entreprises sont extraites via GET /crm/v3/objects/companies. Chaque entreprise est liée à des contacts via des associations, récupérées séparément avec GET /crm/v3/objects/companies/{id}/associations/contacts.

HubSpot permet d’associer plusieurs entreprises à un même contact. Toutefois, une seule d’entre elles peut être définie comme l’entreprise principale. Cette relation prioritaire est conservée lors de la migration vers le modèle relationnel cible.

---

Transactions (deals) et pipelines

Les transactions sont extraites via GET /crm/v3/objects/deals. Chaque deal contient :

• dealname : nom de la transaction
• amount : valeur estimée
• dealstage : identifiant de l’étape dans le pipeline
• closedate : date de clôture prévue
• hs_probability : probabilité de conclusion

Configuration des pipelines

Les pipelines liée au deals et leurs étapes sont extraits via GET /crm/v3/pipelines/deals. Chaque étape possède un id, un label (affiché dans l’interface) et une probability. Cette configuration est remappée dans le nouveau cycle de vente lors de la migration.

Si vous avez plusieurs pipelines (pipeline standard + pipeline Enterprise, par exemple), chaque pipeline est analysé et recréé séparément dans le nouveau logiciel avec ses étapes et ses règles de progression.

---

Activités et historique (engagements)

Les activités sont les objets les plus volumineux à migrer. HubSpot expose chaque type d’activité via des endpoints dédiés en v3 :

Type d’activité	Endpoint API
Appels	GET /crm/v3/objects/calls
Emails envoyés/reçus	GET /crm/v3/objects/emails
Réunions	GET /crm/v3/objects/meetings
Notes	GET /crm/v3/objects/notes
Tâches	GET /crm/v3/objects/tasks

Chaque activité est liée à un ou plusieurs contacts, entreprises ou transaction via les associations. La récupération des associations nécessite des requêtes séparées par objet.

Volumes typiques

Sur un portail HubSpot actif depuis plusieurs années, les activités représentent souvent 10 à 50 fois le nombre de contacts. La migration est paginée et peut nécessiter plusieurs heures d’extraction selon les volumes, en respectant le rate limit de 100 requêtes par 10 secondes.

---

Tickets

Les tickets sont extraits via GET /crm/v3/objects/tickets. Ils possèdent leurs propres pipelines, consultables via GET /crm/v3/pipelines/tickets. Les tickets sont associés à des contacts et des entreprises, avec un historique de conversations accessible via GET /conversations/v3/conversations/threads/{threadId}/messages.

---

Propriétés personnalisées

Les propriétés personnalisées sont extraites via GET /crm/v3/properties/{objectType} (remplacer objectType par contacts, companies, deals ou tickets). Chaque propriété retourne son nom interne, son label affiché, son type et ses options si c’est une liste déroulante.

Types de propriétés HubSpot et correspondances

Type HubSpot	Correspondance cible
string	VARCHAR ou TEXT
number	DECIMAL ou INT
date, datetime	DATE ou DATETIME
enumeration (liste déroulante)	ENUM ou table de référence
bool	BOOLEAN
json	JSON ou champ structuré

Les propriétés de type enumeration exposent leurs options (valeur interne + label affiché). Ces options sont analysées pour créer les listes déroulantes équivalentes dans le nouveau logiciel.

---

Listes et segmentation

Les listes statiques et actives sont accessibles via GET crm/v3/lists. Chaque liste retourne ses membres (pour les listes statiques) ou ses filtres (pour les listes actives).

• Listes statiques : membres exportés directement. Migration vers des groupes ou tags manuels.
• Listes actives : les critères de filtrage sont analysés et recréés en requêtes dans le nouveau logiciel. Certains filtres comportementaux (ouverture d’email, visite de page) nécessitent une décision sur leur équivalent dans le nouveau système.

---

Ce qui nécessite une décision avant la migration

Certains éléments ne peuvent pas être migrés automatiquement :

• Les workflows HubSpot : déclencheurs et actions sont analysés et retranscrits en logique métier native (jobs planifiés, événements, règles applicatives)
• Les séquences de prospection : emails automatisés liés aux contacts commerciaux, remplacés par les séquences du nouveau logiciel
• Les formulaires HubSpot : remplacés par les formulaires intégrés au nouveau logiciel, avec reprise des champs et de la logique de routage
• Les intégrations natives (Slack, Stripe, Aircall) : raccordement sur les nouvelles APIs du logiciel cible
• Les rapports et tableaux de bord : indicateurs recréés dans le reporting sur mesure selon vos besoins réels, sans les métriques non utilisées

Ce qui peut rester dans HubSpot

La migration n’est pas forcément totale. Certaines fonctions peuvent coexister temporairement ou durablement avec le nouveau logiciel :

• HubSpot Marketing Hub : campagnes email, landing pages et nurturing peuvent rester dans HubSpot en se connectant au nouveau CRM via l’API
• Les bases non liées au périmètre du projet
• Les formulaires publics si HubSpot Forms reste pertinent pour un cas d’usage isolé

SmartBooster peut aussi développer un connecteur API pour synchroniser HubSpot avec le nouveau logiciel, au lieu de le remplacer complètement.

---

Ce qu’un prestataire sérieux doit faire

Si vous faites appel à un prestataire pour cette migration, voici les questions à poser pour évaluer sa rigueur avant de démarrer :

• Audit des propriétés avant l’extraction : le prestataire doit inventorier toutes les propriétés personnalisées et leurs types avant d’écrire le moindre script de migration.
• Mapping explicite des associations : la relation contact-entreprise-transaction-ticket doit être cartographiée et validée avec vous avant de démarrer l’extraction.
• Environnement de recette dédié : la migration doit être testée sur un environnement isolé avec des données réelles, jamais directement en production.
• Stratégie pour les activités : les volumes d’activités (appels, emails, réunions) doivent être estimés avant le démarrage pour anticiper les délais d’extraction et le respect des rate limits HubSpot.
• Plan de rollback : en cas d’anomalie détectée après la bascule, que se passe-t-il ? Votre portail HubSpot doit rester accessible pendant une période de vérification.

Chez SmartBooster, ces points font partie du cadrage initial de chaque projet de migration.

Authentification à l’API HubSpot

Pour extraire les données, HubSpot recommande désormais l’utilisation de la service key si votre version le permet. À défaut, l’usage des Private App Tokens reste possible malgré leur passage en statut legacy. Un token de lecture seule suffit pour une migration : crm.objects.contacts.read, crm.objects.companies.read, crm.objects.deals.read, crm.objects.tickets.read et les scopes d’activités correspondants.

Consultez le guide de création des identifiants API HubSpot pour la procédure complète.

Références techniques

• API CRM HubSpot : objets
• API HubSpot : propriétés
• API HubSpot : associations
• API HubSpot : pipelines
• API HubSpot : activités
• Exporter des données depuis HubSpot