La plupart des équipes qui parlent d'une « migration CRM » ne procèdent pas réellement à un changement de plateforme. Elles héritent d'une instance HubSpot ou Salesforce construite par quelqu'un d'autre, jamais entièrement documentée, et transmise en même temps que les chiffres de revenus du trimestre. L'instance fonctionne, à peine, et le modèle opérationnel est désormais contraint par elle. C'est cela, une migration CRM brownfield. C'est une catégorie de projet différente d'une installation propre, et prétendre le contraire est l'erreur la plus coûteuse que vous puissiez commettre dans les trente premiers jours.
Pourquoi cela compte maintenant
Les coûts de changement de CRM ne sont plus ce qu'ils étaient. Comme l'a formulé Jason Lemkin en avril : à deux ou trois agents IA, changer de CRM est pénible ; à dix, c'est cher ; à vingt, c'est fonctionnellement impossible. Le système que vous tolérez aujourd'hui est celui dans lequel vous serez enfermés pour la prochaine génération d'agents. La note de la Harvard Business Review en février sur les raisons pour lesquelles les investissements digitaux ne créent pas de valeur pointait la même cause sous un autre angle , l'échec n'est pas dans l'outillage. Il est dans l'incapacité à repenser comment l'organisation commerciale génère réellement de l'insight, prend des décisions et coordonne ses actions. En pratique, une migration brownfield est le moment où cette refonte se produit ou se retrouve repoussée de deux ans encore.
La règle brownfield , il n'y a pas de table rase, donc construisez l'audit avant de construire l'architecture
Une migration greenfield part d'un schéma vierge. Vous décidez quels objets existent, quels champs y vivent, quelles associations sont autorisées, ce que signifient les étapes du pipeline. Une migration brownfield part de plusieurs années de décisions prises par d'autres, gravées dans un système de revenus en production. La plupart de ces décisions avaient du sens à l'époque et n'en ont plus aujourd'hui. Quelques-unes n'ont jamais été bien réfléchies. Un nombre surprenant d'entre elles s'avèrent porteuses, d'une manière que personne n'a documentée.
La règle à laquelle nous tenons chaque mission brownfield est la suivante , ne changez rien à l'architecture des données avant d'avoir trié chaque décision existante. Le tri n'est pas optionnel, et le tri est le projet. La re-plateformisation n'est que ce qui se passe à la fin.
Le framework keep / edit / delete
Pour chaque donnée existante, chaque champ existant, chaque étape de pipeline existante, chaque automatisation existante, chaque rapport existant, la réponse est l'une de ces trois :
- Keep. Cela sert encore un cas d'usage commercial actuel. Pas besoin de retravailler. C'est documenté, correctement câblé, et le retirer casserait un rapport ou un workflow en aval que quelqu'un utilise activement.
- Edit. Cela sert un cas d'usage actuel mais l'implémentation est mauvaise, le type de donnée est mauvais, les valeurs sont incohérentes, ou le workflow est partiellement cassé. Les édits sont cadrés, attribués nominativement et planifiés avant tout merge.
- Delete. Cela servait un cas d'usage qui n'existe plus, n'a jamais été utilisé, ou duplique autre chose. Les suppressions sont vérifiées pour leur impact en aval, puis exécutées.
Le framework paraît léger sur le papier. Le coût se paie en discipline. Chaque propriété, chaque workflow, chaque type d'enregistrement passe par les trois bacs. Une instance HubSpot typique d'une entreprise B2B SaaS en mid-stage porte entre plusieurs centaines et plusieurs milliers de décisions de tri individuelles. L'équipe qui dit « on verra en route » est l'équipe qui livre la migration avec la dette intacte.
Là où le framework devient concret
Trois endroits où le cadre keep / edit / delete s'aiguise rapidement en pratique :
Étapes de pipeline et leurs définitions
La plupart des pipelines hérités ont des étapes qui veulent dire des choses différentes selon les personnes. « Closed Won » signifie parfois contrat signé ; parfois kickoff planifié ; parfois revenu reconnu. La migration est le moment de forcer la définition. Edit, pas delete, mais chaque étape obtient une définition d'une phrase, un critère d'entrée, un critère de sortie et un owner.
Propriétés personnalisées sur Deal, Contact, Company
Les instances brownfield accumulent des propriétés personnalisées à peu près au rythme où l'équipe accumule des idées. Un audit sérieux en supprime généralement 30 à 50 %. La question diagnostique pour chacune , qui l'a lue dans les 90 derniers jours, et quelle décision en a été tirée ? Si la réponse est personne et rien, on supprime.
Workflows et automatisations
La source la plus fréquente de dette brownfield, ce sont les workflows qui se déclenchent sur des triggers obsolètes, qui mettent à jour des champs que personne n'utilise, ou qui notifient d'anciens collaborateurs. Chaque workflow est lu de bout en bout, son état final cartographié et trié. Les workflows qui survivent sont renommés selon une convention ; les autres sont mis en pause avant tout déplacement de données.
Cas observé sur le terrain
Une équipe B2B SaaS basée dans la zone DACH en Series B est récemment venue nous voir avec deux portails HubSpot et une instance Salesforce qu'il fallait fusionner en un système unique. L'instinct était la re-plateformisation : tout déplacer, déposer dans un nouveau portail, livrer en huit semaines. La forme réelle du projet, après tri, était différente. Environ 38 % des propriétés personnalisées héritées ont été marquées à supprimer dès le premier passage d'audit. Encore 24 % nécessitaient des édits, changements de type, consolidation de listes de choix, recâblage de workflows. Les 38 % restants ont été conservés tels quels. L'instance fusionnée est passée en production avec environ un tiers de la surface de propriétés personnalisées des systèmes hérités combinés, et le premier trimestre de reporting dessus a été le premier en deux ans à ne pas demander une étape manuelle de nettoyage avant chaque pull. La migration n'a pas été le speed-to-platform que nous avions initialement cadré. Elle a été le nettoyage.
Résolution , un playbook de migration brownfield
Pour toute équipe sur le point d'hériter ou de fusionner une instance HubSpot ou Salesforce :
- Gelez l'architecture. Pas de nouvelles propriétés, pas de nouveaux workflows, pas de nouvelles étapes de pipeline tant que l'audit n'est pas terminé. L'audit dure plus longtemps si vous continuez d'ajouter de la surface.
- Faites le passage keep / edit / delete sur chaque objet. Propriétés, pipelines, workflows, types d'enregistrement, appartenances aux listes, libellés d'association. Documentez la décision dans un tableur que quelqu'un est prêt à défendre.
- Confrontez au système qui pilote réellement le revenu. Si vous avez des données dans deux systèmes, traitez-en un comme la source de vérité et alignez l'autre dessus. La migration n'est pas le moment de débattre quel système gagne.
- Réparez les workflows avant de déplacer les données. Des données brownfield au-dessus d'une automatisation héritée, c'est le pire des deux mondes. Mettez en pause toute automatisation qui touche une propriété que vous éditez ou supprimez ; réécrivez les survivants contre le schéma post-audit.
- Mettez en scène la fusion dans une sandbox. Les migrations en production sont d'abord testées en sandbox, validées contre une vraie charge de reporting, puis seulement planifiées.
- Formez sur le système post-audit, pas sur le legacy. Une migration brownfield est un changement de comportement pour l'équipe. La documentation écrite contre le système legacy verrouille la dette legacy.
Si vous suivez les étapes une à six, la vraie migration de données est un vendredi après-midi. Si vous les sautez, la migration, c'est les douze prochains mois.
Là où Checkpoint intervient
La raison pour laquelle le framework keep / edit / delete tient sous pression, c'est qu'il n'est pas un poster méthodologique, c'est le travail. Les migrations brownfield représentent l'essentiel du travail CRM que nous faisons chez Checkpoint, et nous avons fait tourner le cycle d'audit sur suffisamment d'héritages HubSpot, Salesforce et Pipedrive pour savoir quelles décisions reviennent à chaque fois et lesquelles sont véritablement uniques à votre stack. Si votre migration brownfield part d'une dette héritée plutôt que d'un schéma vierge, parlez-en avec nous avant de choisir la plateforme, la bonne décision de plateforme tombe de l'audit, et non l'inverse.
Sources
- Sinha, Shastri, Lorimer. « Why Your Digital Investments Aren't Creating Value. » Harvard Business Review, 16 février 2026. hbr.org
- Lemkin, Jason. « Which CRM Should You Use in 2026/2027? Follow the Agents. » SaaStr, 6 avril 2026. saastr.com