La plupart des migrations Salesforce-vers-HubSpot sont scopées comme un exercice de mapping. Quelqu'un exporte la liste de champs Salesforce, la colle à côté de la liste de propriétés HubSpot, trace des lignes entre les deux, et bookte une fenêtre d'import. Ce n'est pas une migration ; c'est une traduction de la dette technique existante dans un nouveau dialecte. Le vrai travail de passer de Salesforce à HubSpot est un triage au niveau champ , décider, une ligne à la fois, si un champ obtient un home HubSpot, est transformé d'abord, ou ne survit pas au cutover. Le tableur de mapping est la sortie de cette décision. Ce n'est pas la décision elle-même.
Pourquoi cela compte maintenant
Les instances Salesforce au stade Series B et au-delà portent des centaines de champs custom, et le compte de champs est la plus petite partie du problème. La plus grande est que moins de la moitié des données structurées sur ces champs est activement utilisée dans une décision, un constat documenté dans le travail de stratégie de données de la Harvard Business Review et qui a bien vieilli depuis. Un lift champ-par-champ vers HubSpot porte la moitié inutilisée avec la moitié utile, et l'équipe traîne ensuite le poids mort en avant dans la nouvelle plateforme. La fenêtre de migration est le seul moment dans le cycle de vie du CRM où supprimer un champ est bon marché. Sautez-le, et la prochaine personne à toucher au schéma combat l'héritage, ne construit pas en avant.
Le tableur de triage, pas le doc de mapping
L'artefact qui pilote une migration Salesforce-vers-HubSpot est un tableur avec une ligne par champ Salesforce et trois colonnes de décision : keep, edit, delete. C'est le même cadre keep / edit / delete qui gouverne l'audit brownfield plus large sur une instance héritée, mais pointé vers une cible plus étroite, le champ, pas le workflow ou le rapport. La version niveau-instance du même cadre vit dans notre pièce compagne sur l'héritage d'une instance HubSpot ou Salesforce. Pour chaque champ la ligne enregistre le nom d'API Salesforce, le type de champ, le taux de population sur les records modifiés dans les quatre-vingt-dix derniers jours, la propriété HubSpot proposée, le transform, et l'owner nommé qui signe la ligne.
Une instance Salesforce mid-stage typique se trie à environ un tiers supprimé, un quart édité, et le reste conservé tel quel. Les chiffres comptent moins que la discipline , chaque champ est une décision, et chaque décision a un nom à côté.
Types de champs Salesforce vs types de propriété HubSpot
Les deux systèmes ne partagent pas un système de types, et les mismatches sont là où la plupart des erreurs de migration au niveau champ se font. Les catégories qui comptent vraiment :
Picklists vs dropdown / radio / checkbox
Les picklists multi-select Salesforce n'ont pas d'équivalent HubSpot propre. Les propriétés multi-checkbox HubSpot couvrent le cas structurel, mais les valeurs de picklist spécifiques à un record-type dans Salesforce s'étendent souvent en propriétés séparées sur HubSpot quand les valeurs ne sont pas réellement de la sémantique partagée. Le moment de la migration est le moment de consolider. Les picklists avec plus de vingt valeurs, dont la moitié n'a pas été sélectionnée dans les six derniers mois, sont éditées vers les valeurs qui apparaissent sur de vrais records.
Formula fields
Les formula fields Salesforce ne migrent pas. Ils sont déroulés en l'une de trois choses dans HubSpot , une propriété calculation si la formule est une fonction pure d'autres propriétés sur le même record, un workflow qui écrit dans une propriété régulière sur trigger, ou une suppression si la logique sous-jacente n'est plus nécessaire. Le diagnostic, c'est si la formule lit depuis des champs qui sont eux-mêmes keeps, edits ou deletes. Un formula field dont les inputs vont tous au delete est un delete par transitivité.
Lookup et relations master-detail
Les lookups Salesforce se traduisent en associations HubSpot, mais la traduction n'est pas 1:1. Les labels d'association HubSpot portent une sémantique, « primary signer » vs « economic buyer » vs « champion », que Salesforce encode souvent comme un champ lookup custom avec une picklist de rôle à côté. La migration propre consolide le pattern lookup-plus-rôle en une seule association labelée, plus courte à maintenir et moins fragile à reporter. Les relations master-detail flaggent une question différente , si l'objet enfant doit être un objet custom HubSpot du tout, ou si les records appartiennent à un objet standard différent avec le parent comme association.
Champs Owner, queue et sharing-rule
Les sharing rules et l'ownership de queue Salesforce cachent souvent une logique de visibilité à l'intérieur de champs qui paraissent inoffensifs sur le papier. « Account Region », « Deal Pod » et « Owner Role » existent fréquemment non pour reporter, mais pour piloter une sharing rule trois couches plus bas. Avant de supprimer l'un d'eux, tracez le rayon d'impact de la sharing rule. Le modèle de permission HubSpot est plus plat et plus déclaratif ; certains de ces champs disparaissent dans l'appartenance à une équipe et dans des règles de partition dans le nouveau système, mais seulement après que la dépendance est mappée.
La question des données historiques
Chaque migration Salesforce-vers-HubSpot tombe sur la question de combien d'historique faire passer. La réponse honnête est rarement tout. Le défaut auquel nous tenons est les quatre-vingt-dix derniers jours d'historique d'activité, le cycle de vie complet de toute opportunité ouverte indépendamment de l'âge, et le record Closed Won de tout deal encore sur un cycle de renouvellement. Le reste reste dans une archive Salesforce read-only que l'équipe peut référencer mais ne peut pas éditer. La raison de tracer la ligne serrée est que la donnée d'activité historique est le plus grand contributeur au temps de migration et le plus petit contributeur aux décisions tournées vers l'avenir. Une équipe qui importe cinq ans de tâches d'activité d'anciens reps obtient une instance HubSpot plus lente et à peu près la même précision de forecast.
Cas observé sur le terrain
Une équipe B2B SaaS en EMEA au stade Series B est venue nous voir en pleine migration avec une instance Salesforce portant un peu plus de six cents champs custom à travers les objets Account, Contact et Opportunity. Le périmètre original avait été un mapping de champs 1:1: chaque champ Salesforce reçoit une propriété HubSpot, l'import tourne, l'équipe se reforme. La première passe de triage a marqué environ trente-cinq pour cent des champs pour suppression directe, la plupart d'entre eux des champs custom peuplés sur quelques centaines de records il y a des années pour une campagne dont personne dans l'équipe actuelle ne se souvenait. Vingt-cinq pour cent supplémentaires étaient des édits, consolidations de picklists, déroulés de formula fields, traductions lookup-vers-association, et une poignée de champs date qui devaient atterrir dans le handling de fuseau horaire plus strict de HubSpot. Les quarante pour cent restants ont été conservés tels quels. Le portail HubSpot est passé en production avec environ deux cent quarante propriétés custom, une surface que l'équipe pouvait réellement maintenir, et le premier trimestre de forecasting dessus a été le premier en deux ans qui n'a pas eu besoin d'une passe manuelle d'intégrité de données avant l'appel.
Résolution , le playbook de triage
Pour toute équipe sur le point de mener une migration Salesforce-vers-HubSpot :
- Tirez l'inventaire de champs avant de tracer une ligne de mapping. Une ligne par champ custom Salesforce sur chaque objet standard et custom. Incluez nom d'API, type de champ, taux de population sur records modifiés dans les quatre-vingt-dix derniers jours, et les métadonnées dépendantes : workflow rules, validation rules, références de formule, sharing rules.
- Faites tourner la passe keep / edit / delete. Chaque ligne reçoit une décision et un owner nommé. Les champs avec une population sous dix pour cent sur les records récents défaultent au delete sauf si quelqu'un les défend par écrit.
- Consolidez les picklists avant le mapping. Éditez les valeurs de picklist vers ce qui apparaît sur de vrais records, puis mappez la liste consolidée vers HubSpot. N'importez pas les valeurs mortes.
- Déroulez les formula fields en calculations, workflows ou deletes. Aucun formula field ne migre tel quel. Chacun est ré-implémenté, ré-routé ou laissé tomber.
- Traduisez les lookups en labels d'association HubSpot. Les patterns lookup-plus-rôle se replient en associations labelées. Les objets custom ne gagnent le voyage que si le modèle de données en a vraiment besoin côté HubSpot.
- Mappez le rayon d'impact des sharing rules avant de supprimer tout champ porteur de visibilité. Owner, region, pod et champs role qui pilotent les sharing rules Salesforce ne peuvent pas juste disparaître ; ils se traduisent en équipes HubSpot, règles de partition ou permissions role-based, et la traduction est documentée par champ.
- Signez le tableur avant que l'import ne tourne. Le tableur de triage est l'artefact de cutover. L'import HubSpot est une fonction de ce tableur, pas un exercice parallèle. Si un champ n'est pas signé, il ne bouge pas.
Les étapes une à sept sont quatre-vingts pour cent du projet. L'import réel est un vendredi après-midi.
Là où Checkpoint intervient
Le triage au niveau champ est le travail qui détermine si une migration Salesforce-vers-HubSpot livre propre ou livre la même instance sous un nouveau logo. Nous lançons cet exercice sur chaque migration CRM que nous touchons, et c'est l'épine dorsale de la façon dont nous abordons les implémentations HubSpot en aval d'un système legacy. Si le triage est le projet, le modèle opérationnel qui utilise l'instance résultante est ce qui le rend durable, c'est le travail revenue operations qui suit. Si vous scopez un mouvement Salesforce-vers-HubSpot et que la conversation démarre depuis un tableur de mapping, parlez-nous avant que la fenêtre d'import ne soit booktée.
Sources
- « What's Your Data Strategy? » Harvard Business Review, mai–juin 2017. hbr.org
- Lemkin, Jason. « Which CRM Should You Use in 2026/2027? Follow the Agents. » SaaStr, avril 2026. saastr.com