Quitter HubSpot : exporter, remapper, reprendre l'historique

Quitter HubSpot revient à sortir trois jeux de données distincts, et un seul sort en un clic. Les fiches et leurs propriétés s'exportent depuis l'index de chaque objet, en CSV, XLS ou XLSX. Les associations sont des relations entre identifiants, pas des colonnes. Les activités, emails journalisés et appels, sont des objets à part avec leurs propres points d'accès d'API.

La migration ne se joue donc pas sur l'export, mais sur la table de correspondance : quelle propriété devient quel champ, laquelle est calculée et n'a pas d'équivalent, quel identifiant sert de clé de jointure. Puis sur l'ordre d'import : sociétés, contacts, transactions, activités, associations. Comptez deux à quatre semaines de double run, HubSpot restant ouvert en lecture seule.

Faits relevés au 6 septembre 2026 sur knowledge.hubspot.com, developers.hubspot.com et les pages tarifaires publiques de l'éditeur. Les mécaniques d'export et la grille tarifaire évoluent : chaque point ci-dessous se revérifie à sa source avant d'entrer dans un plan de bascule.

Ce qui déclenche un départ n'est pas le produit, c'est l'assiette de facturation

Un compte HubSpot facture sur deux assiettes en même temps. La page hubspot.com/pricing/marketing pose que les contacts marqués comme contacts marketing comptent dans le palier de contacts payant, et que les contacts non marketing se stockent gratuitement jusqu'à quinze millions de fiches. La page hubspot.com/pricing/sales facture, elle, les plans Sales Hub payants par siège.

La facture suit donc la taille de la base autant que le nombre d'utilisateurs : cinq commerciaux qui importent quarante mille contacts changent de palier sans connexion supplémentaire. Le réglage qui l'évite est gratuit, mais il suppose de trier une base héritée de campagnes d'achat de fichiers. Cette structure de prix ne produit pas un mécontentement fonctionnel mais un coût qui augmente avec l'inventaire, et ce coût décide de ce qui doit sortir.

Ce qu'un export HubSpot rend vraiment, et en combien de fichiers

Depuis l'index d'un objet, contacts, sociétés, transactions ou tickets, l'export produit un fichier CSV, XLS ou XLSX. La documentation d'export de knowledge.hubspot.com précise qu'il arrive par un email portant un lien de téléchargement expirant au bout de 30 jours. C'est le jeu numéro un, une ligne par fiche, celui que tout le monde croit suffisant.

Jeu numéro deux, les associations. La même page documente deux options : le nom de l'enregistrement associé, qui remonte jusqu'à mille identifiants d'enregistrements associés par colonne d'association, ou l'ensemble des enregistrements associés, réservé au format CSV. Au-delà de mille associations sur une même fiche, la colonne cesse d'être exhaustive et la reconstruction passe par l'API.

Jeu numéro trois, les activités. Sur developers.hubspot.com, appels, emails, réunions, notes et tâches sont des objets d'engagement à part entière : un appel se crée par une requête POST sur /crm/v3/objects/calls, puis s'associe explicitement à une fiche. Un export d'index de contacts ne contient donc ni le corps d'un email ni la durée d'un appel.

Remapper : une propriété HubSpot n'est pas un champ

La table de correspondance est le vrai livrable de la migration. Une ligne par propriété, cinq colonnes : nom interne HubSpot, libellé affiché, type, champ cible, transformation à appliquer. Elle se construit avant l'export, parce qu'elle détermine quelles colonnes sortir et quelles propriétés ne pas migrer du tout. Trois familles y résistent, et chacune casse différemment.

Les propriétés de type Calcul d'abord. La documentation des propriétés de knowledge.hubspot.com indique qu'un type de champ ne peut être basculé ni vers Calcul ni depuis Calcul : la formule ne se convertit pas en valeur avant l'export. Elle sort figée, et dans la cible il faut soit la recréer, soit assumer une photographie datée du jour de l'extraction.

Les propriétaires ensuite. Sur developers.hubspot.com, l'identifiant d'un propriétaire est la valeur à employer pour affecter un responsable à une fiche ou à une activité, et ces points d'accès sont en lecture seule. Les étapes de transaction enfin : définies à l'intérieur d'un pipeline, leur nom ne suffit pas à les replacer, il faut aussi le pipeline d'origine.

Reste la clé de jointure. La documentation d'import de knowledge.hubspot.com liste, pour rapprocher une ligne d'une fiche existante, le Record ID, l'email pour les contacts, le nom de domaine pour les sociétés et une propriété à valeurs uniques. Le Record ID, ajoute-t-elle, prime sur tout autre identifiant unique de l'import : conservez-le dans un champ texte de la cible.

L'historique : ce qui se reprend, ce qui se re-capte, ce qui se perd

Cette table décrit l'état présent des fiches, pas leur passé, et c'est le passé que l'équipe ouvrira le premier lundi. Il se range en trois catégories, et les confondre est la confusion la plus coûteuse après la bascule. La question est de séparer ce qui doit être importé de ce qui se reconstruit seul une fois les canaux reconnectés.

• Ce qui se reprend : notes, tâches, comptes rendus de réunion, corps des emails journalisés, dates et durées d'appels. Ce sont des objets d'engagement rattachés à un identifiant, importables comme tels si le Record ID a été conservé.
• Ce qui se re-capte : le fil email. Reconnecter la boîte Gmail ou Outlook au nouveau CRM reconstruit les échanges depuis la messagerie, qui redevient la source de vérité à la place de la copie du CRM précédent.
• Ce qui se perd : ouvertures et clics, scores prédictifs, statistiques de workflow, journal de modification propriété par propriété. Ces données sont dérivées, aucun import ne les recalcule.

Le droit ne rattrape pas cette troisième catégorie, et pas de la même façon des deux côtés de l'Atlantique. L'article 20 du RGPD n'ouvre un droit à la portabilité que sur les données personnelles que la personne concernée a fournies au responsable de traitement, dans un format structuré et lisible par machine. Un score prédictif est déduit, pas fourni.

Aux États-Unis, la logique diffère. Le California Consumer Privacy Act range au paragraphe 1798.140(v)(1)(K) les inférences tirées d'autres informations pour construire un profil parmi les données personnelles. Et l'avis 20-303 du procureur général de Californie, du 10 mars 2022, conclut qu'un consommateur a le droit de connaître les inférences générées en interne à son sujet.

Dédupliquer avant la bascule, jamais après

La re-capture écrit des interactions au même endroit que l'import, et le croisement fabrique des doublons. Or knowledge.hubspot.com documente une déduplication native étroite : à la création d'une fiche, HubSpot cherche une correspondance sur la propriété Email pour un contact, et sur le nom de domaine de l'entreprise pour une société. La base source est donc propre selon ces deux clés, sale selon les autres.

Le même interlocuteur avec deux adresses fait deux fiches, deux filiales qui partagent un domaine n'en font qu'une, et la cible n'aura pas les mêmes clés : un numéro en E.164 y devient une clé de rapprochement là où HubSpot n'en fait pas une. L'ordre n'est donc pas négociable : fusionner dans le fichier ne supprime qu'une ligne perdante, quand une fusion après import oblige à rediriger toutes les associations vers la survivante.

Ce que HubSpot fait mieux, et quand ne pas partir

Le coût de l'opération chiffré, la question se retourne : que perd-on en partant ? Le marketing automation de HubSpot est un produit complet, formulaires, pages d'atterrissage, emails de masse, workflows, scoring, attribution. Un CRM qui couvre la vente ne le remplace pas. Et si le marketing vit dedans, migrer la seule partie commerciale coupe le lien entre le formulaire rempli et la fiche mise à jour, celui-là même qui alimente le pipeline.

Il existe donc des cas où l'on reste. Si la facture est portée par les sièges plutôt que par les contacts, si les workflows marketing tournent vraiment, si trois exercices de reporting reposent sur ces données, renégocier au renouvellement coûte moins cher qu'une migration. Ce n'est qu'une fois cet arbitrage tranché qu'un plan de bascule a un sens.

Le plan en quatre étapes et la fenêtre de double run

Première étape, geler le modèle. Aucune propriété nouvelle, aucun pipeline nouveau dans HubSpot pendant la préparation. Une colonne créée après l'export n'existe pas dans la table de correspondance, et personne ne s'en apercevra avant qu'un commercial la cherche dans le nouvel outil, trois semaines après la bascule.

Deuxième étape, importer dans l'ordre des dépendances : sociétés, puis contacts, puis transactions, puis activités, puis associations. Chaque étape se valide sur un compte. Si l'export annonce 12 480 contacts et que l'import en crée 12 106, l'écart se documente immédiatement, ligne par ligne, et pas à la fin du projet.

Troisième étape, le double run. Les deux outils tournent en parallèle deux à quatre semaines : écriture dans le nouveau, lecture seule dans HubSpot. C'est le seul dispositif qui rend une erreur de mapping visible, parce qu'elle apparaît sur une opportunité en cours de négociation et non sur un jeu de test que personne ne relit.

Quatrième étape, la sortie contractuelle, qui se compte à rebours de la fin du double run et non de la décision. Le règlement européen sur les données, applicable depuis le 12 septembre 2025, plafonne à deux mois le préavis de changement de fournisseur à son article 25, paragraphe 2, et fixe à 30 jours calendaires la période de transition maximale.

Deux réserves. Son article 29 n'interdit toute facturation du changement qu'à compter du 12 janvier 2027. Et son article 30 réserve l'équivalence fonctionnelle aux fournisseurs de ressources d'infrastructure : en logiciel applicatif, l'obligation se réduit à exporter les données exportables dans un format lisible par machine.

Les six questions à régler avant de cliquer sur Export

La bascule se prépare sur six réponses écrites. Aucune ne demande d'outil, toutes se traitent en une demi-journée avec un administrateur HubSpot et la personne qui portera le nouveau CRM. Elles valent pour n'importe quelle cible, y compris celle qui n'est pas encore choisie.

• Le volume réel : combien de fiches par objet, combien de propriétés sont vraiment remplies, et sous quel seuil de remplissage une propriété se supprime au lieu de se migrer.
• Les propriétés calculées : lesquelles redeviennent une formule dans la cible, lesquelles restent une valeur figée portant sa date de calcul.
• La clé de jointure : dans quel champ du nouveau CRM atterrit le Record ID, et qui vérifie qu'il a survécu à l'import.
• Le partage de l'historique : quelles activités sont importées, lesquelles seront re-captées, à quelle date de coupure.
• La déduplication : sur quelle clé, appliquée au fichier avant l'import, avec une règle écrite pour la fiche survivante.
• La fin du double run : cette date déclenche le préavis contractuel de deux mois, et elle seule coûte de l'argent.

Ces six réponses comptent plus que le choix de l'outil : elles rendent la migration réversible, y compris vers un troisième CRM dans deux ans. Une équipe qui sait où vit son Record ID, ce qui se re-capte et ce qui se perd ne redéménage jamais à l'aveugle.

Kasar est un CRM AI-natif. Son agent, Léo, capture les interactions par email, LinkedIn, WhatsApp, calendrier et appels, ce qui déplace une partie de l'historique du côté re-capté plutôt qu'importé, et le produit expose un serveur MCP. Les six questions ci-dessus valent pour Kasar comme pour toute autre cible.