Une migration de Salesforce vers HubSpot se juge à ce que vous décidez de ne pas copier. Les enregistrements, les automatisations et les rapports se répartissent en trois catégories : copier, archiver ou reconstruire. Les équipes qui font ce tri de façon délibérée obtiennent un CRM en lequel leurs utilisateurs ont confiance, tandis que celles qui s'en dispensent déplacent leur désordre en six semaines.
Je ne suis pas contre la rapidité. Un partenaire HubSpot annonce un transfert en six semaines sans interruption d'activité, et c'est une promesse raisonnable pour la partie mécanique. Le problème, c'est que ce calendrier mesure la partie la plus facile à mesurer.
Pourquoi le délai de six semaines mesure la mauvaise chose
Un calendrier vous indique quand les données arrivent dans le nouveau système. Il ne dit rien de leur signification une fois arrivées. Une migration de Salesforce vers HubSpot peut se terminer dans les temps et vous laisser pourtant avec une année de reporting défaillante.
Les deux plateformes reposent sur des modèles de données différents. Salesforce permet d'empiler au fil des ans des objets personnalisés, des types d'enregistrement et des règles de validation, et la documentation développeur de Salesforce montre à quel point cette structure est configurable. HubSpot adopte un modèle plus plat d'objets, de propriétés et d'associations, décrit dans la documentation développeur de HubSpot. Tout ce qui dépendait d'une structure propre à Salesforce doit être traduit ou repensé.
Un client avec qui nous avons échangé faisait face à environ 1 300 doublons et à des transitions d'étapes du pipeline que personne n'avait testées, alors que la fenêtre de migration était déjà fixée. La date n'était pas le problème. Les questions sans réponse constituaient le risque.
Le tri d'une migration de Salesforce vers HubSpot : copier, archiver ou reconstruire
Voici le cadre que j'utilise. Pour chaque objet de données, chaque automatisation et chaque rapport, nous posons une seule question : l'entreprise agit-elle encore sur cet élément ? Si oui et qu'il est propre, copiez-le. S'il a une valeur historique mais que personne n'agit dessus, archivez-le. Si l'on agit dessus mais que son fonctionnement relève du contournement, reconstruisez-le.
| Élément | Décision par défaut | Raison |
|---|---|---|
| Comptes, contacts, transactions ouvertes | Copier après déduplication | Les commerciaux les utilisent au quotidien |
| Transactions perdues et anciennes activités | Archiver | Utiles pour l'analyse, du bruit dans le CRM actif |
| Étapes du cycle de vie et étapes de transaction | Reconstruire | Les anciennes étapes reflètent d'anciennes habitudes |
| Automatisations de type workflow | Reconstruire | La plupart étaient des rustines sur des rustines |
| Attribution des sources et des campagnes | Copier avec soin | Les horodatages sont coûteux à recréer |
Pour le meilleur et pour le pire, c'est dans la colonne « reconstruire » que le temps se dépense. C'est aussi là que se trouve la valeur.
Données : dédupliquez avant de migrer, archivez plutôt que de tout copier
Le doublon le moins coûteux à corriger est celui que l'on corrige avant l'import. Un autre client nous a expliqué que sa base Salesforce était difficile à nettoyer à cette échelle, faute d'effectifs et de crédits d'enrichissement. La migrer telle quelle aurait transformé un problème de données en problème HubSpot, avec une tarification par contact en prime.
Voici donc une règle empirique. Si un enregistrement n'a eu aucune activité ni aucune association ouverte sur une période cohérente avec votre cycle de vente, archivez-le en dehors du CRM. Vous pourrez le récupérer si un usage apparaît. En revanche, il est difficile de dépolluer un portail actif une fois que les commerciaux y ont pris leurs habitudes.
L'attribution fait exception. Les données de source et les horodatages de premier contact sont très difficiles à reconstituer après coup, et les champs mal traités ressortent souvent plus tard sous forme de trafic classé en direct, un schéma que nous décrivons dans comment les références issues de l'IA finissent en trafic direct dans HubSpot.
Automatisations et logique de facturation : reconstruire à partir du résultat attendu
Copier une automatisation Salesforce dans HubSpot revient à en copier les bizarreries. L'échéancier de facturation d'un client en est un bon exemple : les ventes conclues le 15 étaient facturées pour moitié à cette date et pour moitié le premier du mois suivant, ce que Salesforce gérait de manière maladroite. La bonne démarche n'est pas de recréer ce contournement maladroit. Elle consiste à décider du résultat attendu côté finance, puis à construire le chemin le plus court pour l'obtenir dans le nouveau système.
Mon sentiment est qu'environ un tiers des automatisations anciennes d'une organisation mature n'existent qu'en raison d'une contrainte révolue. Ce chiffre est ma propre estimation de travail issue de projets, et non le résultat d'une étude. Lorsque vous dressez la liste des automatisations, notez à côté de chacune le résultat qu'elle produit. Toute automatisation sans résultat encore pertinent est candidate à la suppression.
Rapports : reconstruire à partir des questions posées par la direction
Un rapport migré à l'identique repose sur une ancienne définition d'une étape, d'une source ou d'un lead « qualifié ». Partez des cinq ou six questions que votre direction pose chaque semaine, et reconstruisez-les d'abord sur le nouveau modèle de données. Comparez ensuite les résultats aux anciens chiffres et consignez chaque écart que vous pouvez expliquer.
Cette comparaison compte plus que le tableau de bord lui-même. Si le nouveau chiffre du pipeline est inférieur de 8 % à l'ancien, vous voulez savoir si la cause est la déduplication, une définition d'étape modifiée ou un bogue. Sans cela, la première réunion de prévision après la mise en service tourne à la querelle sur l'outil.
Ce que coûte vraiment une migration de Salesforce vers HubSpot au-delà des licences
Les résultats de recherche que je vois sur ce sujet s'arrêtent le plus souvent aux calendriers et à la correspondance des champs. Ils laissent de côté le coût total. Voici un exemple chiffré, fondé sur mes hypothèses et non sur une référence du marché : une équipe de 12 commerciaux perd deux heures par semaine chacun pendant six semaines, le temps de réapprendre le système et de corriger les enregistrements. Cela représente environ 144 heures, avant toute intervention de consultant ou tout retravail d'intégration. Ajoutez une reconstruction du reporting que personne n'avait chiffrée, et la facture de ce qui n'a pas été transféré dépasse celle du transfert.
L'adoption durant les 90 premiers jours suit la même logique. Les commerciaux utilisent le nouveau CRM lorsque les étapes correspondent à leur façon de vendre et que les données des fiches sont fiables. C'est un résultat de la reconstruction, pas de la formation.
Quand rester sur Salesforce
Je n'ai pas de règle nette pour ce point. Les hiérarchies de territoires complexes, les modèles de permissions approfondis et les objets très personnalisés sont des domaines où HubSpot peut ne pas égaler ce que vous avez. Parfois, la recommandation honnête est de rester, ou de migrer par phases. Si un partenaire ne le dit jamais, demandez-lui pourquoi.
La liste de contrôle d'étude de cas pour une migration de Salesforce vers HubSpot détaille les preuves à exiger avant de signer, et notre grille d'évaluation des partenaires d'implémentation HubSpot explique comment noter ceux qui feront le travail. Si vous avez déjà migré et que le portail vous semble défaillant, distinguer un portail défaillant d'un devis de reconstruction est la lecture suivante. Pour découvrir notre manière de conduire ces projets, consultez notre service de migration de Salesforce vers HubSpot et l'ensemble de notre pratique de revenue operations.
Ma recommandation : dans toute migration de Salesforce vers HubSpot, considérez les six semaines comme la partie facile, et consacrez votre attention au tri.