Une étude de cas de migration de Salesforce vers HubSpot doit prouver quatre choses : ce qui n'a pas été transféré, dans quel état se trouvait le dictionnaire de données avant et après, combien de workflows ont été reconstruits plutôt que copiés, et si les commerciaux utilisent encore le système trois mois plus tard. Un titre comme « terminé en six semaines, sans interruption d'activité » n'en prouve aucune. Il vous dit à quelle vitesse le projet s'est achevé, pas si ce qui a été mis en production fonctionne.
J'en lis beaucoup. Le témoignage en page d'accueil d'un partenaire HubSpot, par exemple, affirmera que la migration s'est terminée en six semaines sans interruption. Je le crois. Mais je sais aussi que « sans interruption » et « rien n'a cassé » sont deux affirmations différentes, et que seule la première figure dans la citation.
Pourquoi la rapidité est la preuve la plus faible d'une étude de cas de migration
La rapidité est facile à mesurer et peu coûteuse à obtenir. On peut déplacer des enregistrements très vite si l'on saute le travail qui les rend utiles : déduplication, décisions de mappage des champs, définition des étapes, permissions. Le calendrier est superbe. Le coût apparaît au troisième mois.
Ma règle empirique : une étude de cas mérite la confiance à proportion de ce qu'elle admet. Si le récit ne contient aucune perte, c'est que son auteur n'a pas regardé, ou qu'il ne voulait pas que vous regardiez. Alors, quand vous lisez une étude de cas de migration de Salesforce vers HubSpot, ignorez le calendrier et cherchez la colonne des pertes.
Ce qui n'a pas été transféré est la première chose à demander
Toute migration laisse quelque chose derrière elle. La question est de savoir si le partenaire savait quoi, l'a décidé en connaissance de cause et en a informé le client avant la mise en production.
Les candidats habituels sont l'historique d'attribution, les fichiers et pièces jointes, les automatisations qui dépendent de fonctionnalités propres à Salesforce, la logique des rapports et les structures de permissions. L'ordre des objets compte aussi : la documentation d'import de HubSpot précise que les associations dépendent de la manière et du moment où les enregistrements sont chargés, si bien qu'une mauvaise séquence supprime discrètement les relations entre contacts, entreprises et transactions.
Voici le test. Demandez au partenaire la liste de ce qui a été « laissé de côté » sur un projet passé. Pas un résumé, la liste. Une bonne liste comporte des éléments, chacun assorti d'une raison (archivé, reconstruit autrement, abandonné parce que personne ne l'utilisait) et d'un responsable qui a validé. Si la réponse est « rien d'important n'a été perdu », vous avez appris quelque chose, mais pas ce qu'on voulait vous dire.
L'état du dictionnaire de données dans une étude de cas de migration de Salesforce vers HubSpot
Le dictionnaire de données est le document qui précise ce que signifie chaque champ, qui en est responsable, quelles valeurs sont autorisées et quels systèmes y écrivent. La plupart des organisations Salesforce vieilles de cinq ans n'en ont aucun auquel quelqu'un fasse confiance. Des centaines de champs, plusieurs qui veulent dire la même chose, une poignée que personne ne sait expliquer.
Migrer ce désordre à l'identique, c'est ce que j'appelle un « lift and shift », et c'est la raison la plus fréquente pour laquelle un nouveau portail ressemble à l'ancien avec un logo différent. Une étude de cas solide indique le nombre de champs avant et après. Si une entreprise est passée de 400 propriétés personnalisées à 150, c'est la preuve que quelqu'un a pris des décisions. Si elle est passée de 400 à 400, le projet a simplement déplacé des meubles.
Les doublons racontent la même histoire en miniature. Un client avec qui nous avons échangé avait environ 1 300 enregistrements en double dans son CRM source, et des transitions d'étapes du pipeline non testées à l'approche d'une échéance imposée. Ces deux faits sont le projet. Le changement de plateforme est la partie facile. Comme les deux plateformes gèrent les doublons différemment, ainsi que l'explique le guide de HubSpot sur la déduplication, une étude de cas doit préciser quand le nettoyage a eu lieu et qui a décidé quel enregistrement conserver.
Reconstruction des workflows : comptez-les, et demandez ce qui a été retiré
Les automatisations ne migrent pas. Elles sont reconstruites, et c'est dans cette reconstruction que réside le jugement. Un partenaire qui reconstruit chaque flux Salesforce dans HubSpot a simplement transféré votre dette technique.
Demandez trois chiffres : les workflows dans l'ancien système, les workflows reconstruits, les workflows retirés. Demandez ensuite un exemple de chaque catégorie. Par exemple, une règle d'attribution des leads que personne ne sait expliquer doit être retirée, un rappel de renouvellement sur lequel tout le monde compte doit être reconstruit, et un déclencheur de changement d'étape qui alimentait un tableau de bord que personne n'ouvre doit être abandonné. Si une étude de cas ne peut pas fournir cette répartition, la reconstruction a été mécanique.
C'est aussi à ce stade que le routage et la définition des étapes sont mis à l'épreuve. Notre article sur la différence entre un portail défaillant et un devis de reconstruction aborde le même réflexe sous l'angle opposé.
L'adoption après la mise en production est le seul résultat qui compte
Les résultats de recherche sur ce sujet s'arrêtent le plus souvent à la mise en production. C'est là que s'arrête la facture, et aussi là que commence le risque. Les commerciaux retournent à leurs tableurs, les managers cessent de se fier aux prévisions, et le marketing reconstruit discrètement ses propres rapports.
Je ne dispose d'aucun référentiel sectoriel fiable sur l'adoption par les commerciaux quatre-vingt-dix jours après une migration CRM, et je me méfie de quiconque en cite un. Ce que je demanderais à une étude de cas est simple : les connexions et l'activité enregistrée par commercial à 30, 60 et 90 jours, la précision des prévisions par rapport au trimestre précédent, et la date à laquelle l'ancien système a été définitivement désactivé. Ainsi que le rapport validé à la fois par la finance et par les ventes. Si l'attribution faisait partie de l'ancienne configuration, vérifiez ce qu'elle est devenue ; une bonne part du trafic influencé par l'IA ou non balisé est déjà classée comme direct dans HubSpot, comme nous l'avons expliqué dans les recommandations de l'IA classées en trafic direct.
L'étude de cas de migration de Salesforce vers HubSpot concerne-t-elle une entreprise comme la vôtre ?
Une étude de cas n'est une preuve que si son sujet vous ressemble. Posez quatre questions : le volume d'enregistrements, le nombre d'objets personnalisés, le nombre d'intégrations actives et le nombre d'utilisateurs. Une équipe de 15 licences sans objet personnalisé et une équipe de 300 licences avec CPQ sont deux projets différents qui portent simplement le même titre.
Demandez ensuite ce que le projet a coûté au total. Le devis n'est qu'un chiffre. Ajoutez les honoraires du partenaire, le chevauchement des licences pendant que les deux systèmes tournent, le temps des commerciaux perdu en reformation, et les reprises. Exemple chiffré, fondé sur de simples hypothèses : si 40 commerciaux perdent deux heures par semaine pendant six semaines, cela représente 480 heures de vente, avant toute reprise. Les bons partenaires feront ce calcul avec vous, car c'est la version honnête du prix.
Une courte liste de contrôle pour toute étude de cas de migration de Salesforce vers HubSpot
Avant de signer, demandez au partenaire de vous montrer, à partir d'un projet réel :
- La liste de ce qui a été laissé de côté, avec les responsables
- Le nombre de champs et de propriétés avant et après
- Les workflows reconstruits par rapport aux workflows retirés
- Les chiffres d'adoption et de prévisions à 30, 60 et 90 jours
- Le coût total comparé au devis initial
Cela fait cinq documents. Une équipe qui les possède vous les remettra en quelques minutes, car nous tenons nous aussi à documenter nos projets, aussi étrange que cela puisse paraître. Une équipe qui ne les a pas vous a dit ce que vous aviez besoin de savoir.
Si vous voulez voir à quoi ressemblent ces preuves dans notre propre travail, commencez par notre étude de cas de migration CRM et par le périmètre décrit sur notre service de migration de Salesforce vers HubSpot. Jugez-nous selon la même liste. Le même principe vaut en dehors du CRM : la preuve l'emporte sur le positionnement, comme nous l'expliquons dans classements SEO contre citations par l'IA et dans pourquoi greffer l'AEO sur une société d'implémentation ne suffit pas.