La plupart des projets de migration CRM choisissent une plateforme avant de choisir un archétype. C'est le mauvais ordre. Que vous meniez une migration greenfield ou brownfield change le scope, le timeline, l'équipe et le profil de risque plus que le choix de plateforme. La décision de plateforme est en aval de la décision d'archétype. Trompez-vous d'archétype et vous passez les douze mois suivants à expliquer pourquoi le projet a manqué le scope, alors même que chaque workstream a techniquement livré.
Pourquoi cela compte maintenant
Les coûts de switch en CRM grimpent vite. La note de Jason Lemkin en avril dans SaaStr faisait le point sans détour , à deux ou trois agents IA, switcher de CRM est pénible ; à dix, c'est cher ; à vingt, c'est fonctionnellement impossible. L'architecture dans laquelle vous migrez, schéma propre ou dette héritée, se verrouille avec la plateforme. Une migration brownfield mal libellée greenfield expédie la dette héritée dans la prochaine décennie. Une migration greenfield qui aurait dû être brownfield brûle le funnel inbound en route vers un schéma que personne n'a demandé. La décision d'archétype, c'est là que ce verrouillage se règle.
Les trois archétypes de migration
Rebuild propre (greenfield)
Une nouvelle entité, un nouveau domaine, un nouvel ICP, ou une décision délibérée d'abandonner le système legacy. Le schéma est conçu en avant contre le modèle opérationnel actuel. Il n'y a pas de débat de source de vérité parce qu'il n'y a pas de seconde source. L'historique d'attribution marketing, s'il existe, est traité comme une archive read-only plutôt qu'une contrainte live. Le greenfield est rare dans les entreprises de plus de deux ans.
Nettoyage en sandbox (semi-greenfield)
Le système legacy reste, mais l'équipe a accepté que l'instance de production soit insauvable telle quelle. La migration se fait dans un portail construit en sandbox avec un cutover délibéré. Une partie de l'historique bouge ; la plupart de l'automatisation non. L'archétype le plus fréquent pour les équipes Series A ou B qui ont construit vite l'année un et ont besoin d'un vrai schéma pour l'année trois. Ressemble à du greenfield vu de dehors, tourne comme du brownfield à l'intérieur.
Fusion brownfield
Deux ou plusieurs systèmes live: typiquement HubSpot, Salesforce, Pipedrive, plus un outil de marketing-automation: convergent en une instance unique sans perdre l'historique, l'attribution ou les workflows sur lesquels l'équipe s'appuie actuellement. La migration est l'audit ; l'audit est le projet. Le framework keep / edit / delete pour trier une instance héritée est couvert dans un post précédent, ce travail se passe après la décision d'archétype, pas à sa place.
Les trois questions qui choisissent l'archétype
La fiche de décision est courte , trois lignes, chacune répondue honnêtement. Deux sur trois pointant la même direction suffit à s'engager.
1. Valeur de l'historique , combien des données du système legacy sont porteuses pour le travail commercial actuel ?
Si l'attribution marketing, l'historique de propriété ou les analytics de Pipeline pilotent activement les prévisions, les motions de renouvellement ou le reporting board, l'historique est porteur et vous êtes en territoire brownfield. Si le système legacy est surtout une liste de Contacts avec des workflows à moitié construits auxquels personne ne fait confiance, l'historique est archival et le greenfield est sur la table. Diagnostique , qui a lu cette donnée dans les 90 derniers jours, et quelle décision en a-t-il tirée ?
2. Pression deadline , le funnel inbound peut-il être éteint un trimestre ?
Un rebuild propre coûte typiquement au funnel inbound un trimestre de continuité d'attribution. Si vous avez le runway et la couverture du leadership pour ça, le greenfield est viable. Si les chiffres revenue, les revues board ou une levée sont ancrés au Pipeline marketing-sourced du trimestre suivant, le brownfield est forcé, peu importe à quel point un rebuild paraîtrait propre sur le papier. Personne ne devrait découvrir au quatrième mois que la prévision du CRO ne survit pas à un trimestre d'attribution éteinte.
3. Scope de la dette de schéma , combien de l'implémentation legacy est activement faux ?
Un audit sérieux d'une instance HubSpot ou Salesforce héritée flagge généralement 30 à 50 % des propriétés personnalisées en delete et encore 20 à 30 % en edit. Si le schéma legacy est majoritairement défendable: les définitions tiennent, les workflows se déclenchent sur des triggers actuels, les étapes signifient ce qu'elles disent, le brownfield est un projet plus petit qu'il n'en a l'air. Si le schéma est majoritairement indéfendable, le calcul du coût-d'historique bascule : vous payez prix d'audit brownfield pour du travail de nettoyage greenfield, et l'archétype sandbox-cleanup est la bonne réponse. Diagnostique , trente minutes de marche sur la liste de propriétés avec la personne qui l'a construite. Si elle ne peut pas défendre la moitié de ses champs, le schéma est le projet.
Pourquoi les fusions tendent par défaut au brownfield même quand le greenfield est plus propre
Les consolidations CRM post-fusion présentent presque toujours un argument greenfield propre au tableau blanc : nouvelle entité combinée, nouvel ICP, nouveau positionnement, nouveau domaine. L'argument s'effondre dans la première conversation de scoping. L'un des deux systèmes porte toujours un historique que personne n'est prêt à abandonner, des mois d'attribution marketing, un programme partenaire actif construit sur des labels d'association, une définition de lifecycle stage sur laquelle l'équipe renouvellements prévoit. Le coût de s'éteindre sur l'un d'eux un trimestre est plus haut que le coût d'hériter de la dette de schéma. Le greenfield est techniquement possible. Le brownfield est ce qui livre.
À quoi ressemble un mauvais call à 90 jours
Les deux modes d'échec sont des images miroirs l'un de l'autre.
Greenfield-quand-ça-aurait-dû-être-brownfield : le nouveau portail est propre, le schéma est correct, et personne ne fait confiance aux chiffres parce que la chaîne d'attribution s'est cassée au cutover. Les rapports nouveau-système ne matchent pas l'ancien sur la période de chevauchement. Le CRO prévoit depuis l'export legacy pendant deux trimestres pendant que l'équipe reconstruit l'attribution. Techniquement réussi et commercialement invisible.
Brownfield-quand-ça-aurait-dû-être-greenfield : le portail fusionné fonctionne, mais il porte quinze lifecycle stages là où il devrait y en avoir cinq, trois Pipelines de Deal qui veulent dire la même chose avec des noms d'étape différents, et un millier de propriétés personnalisées dont un tiers ne sont pas utilisées. Chaque nouveau workflow prend deux fois plus de temps parce qu'il faut naviguer la dette héritée. Dix-huit mois plus tard, quelqu'un d'autre est embauché pour migrer la migration.
Cas observé sur le terrain
Une équipe B2B SaaS DACH en Series B est récemment venue avec ce qui ressemblait à un cas greenfield manuel : deux entreprises fusionnant, nouveau domaine, nouvel ICP, positionnement frais. L'instinct au tableau blanc, c'était un rebuild propre: nouveau portail en huit semaines, les deux systèmes legacy retirés au jour de cutover. La fiche de décision n'était pas d'accord. Valeur de l'historique : l'un des deux portails portait environ dix-huit mois de données d'attribution marketing sur lesquelles le funnel inbound tournait activement. Pression deadline : les deux trimestres suivants avaient un chiffre de Pipeline ancré board lié à ce funnel. Scope de dette de schéma : messy mais défendable, la plupart des propriétés avaient des owners, la plupart des workflows se déclenchaient sur des triggers actuels. Deux des trois lignes pointaient sur brownfield. La décision a basculé dans la première séance de scoping. Le projet a livré comme une fusion brownfield contre le plus propre des deux portails ; le funnel inbound ne s'est pas éteint ; le nettoyage de schéma s'est fait en phase d'audit. Huit semaines plus tard, l'équipe avait une instance unique avec environ un tiers de la surface de propriétés personnalisées legacy et une chaîne d'attribution sur laquelle le CRO pouvait prévoir.
Résolution , le playbook de décision d'archétype
Avant toute décision de plateforme, avant tout mouvement de données, avant tout kickoff :
- Tournez les trois questions diagnostiques sur une seule page. Valeur de l'historique, pression deadline, scope de dette de schéma. Deux colonnes : tendance greenfield, tendance brownfield. Forcez une réponse binaire par ligne.
- Marchez la liste de propriétés avec la personne qui l'a construite. Trente minutes, pas de slides. Si elle peut défendre la plupart de ses champs, le schéma est récupérable en brownfield. Si elle ne peut pas, sandbox-cleanup est sur la table.
- Vérifiez la chaîne d'attribution contre les deux trimestres suivants de prévision. Si le chiffre du Pipeline marketing-sourced ancre une revue board ou une levée, le brownfield est forcé, écrivez ça avant la conversation plateforme.
- Nommez l'archétype à voix haute, par écrit, avec le CRO et le head of marketing dans la salle. Une migration où le leadership ne peut pas s'accorder sur l'archétype se mis-scope au troisième mois.
- Choisissez la plateforme en dernier. La bonne plateforme pour un rebuild greenfield n'est pas toujours la bonne plateforme pour une fusion brownfield. L'archétype rétrécit la shortlist plateforme.
- Re-testez l'archétype à six semaines. Si un projet brownfield produit plus de décisions delete que de décisions keep, c'est peut-être un sandbox-cleanup mal libellé fusion brownfield. Attraper ça à six semaines coûte un re-scope ; l'attraper au quatrième mois coûte le timeline.
Deux des trois lignes pointant la même direction suffit à s'engager. Un sur trois est la conversation qui mérite qu'on ralentisse. Zéro sur trois est un projet qui n'est pas encore scopé.
Là où Checkpoint intervient
La décision d'archétype est la conversation la plus à fort levier dans toute migration CRM. La réussir et le reste du projet est de l'exécution. La rater et chaque décision en aval compose le mis-scope. Checkpoint tourne la fiche de décision en trois questions sur chaque mission de migration CRM avant toute conversation de plateforme. Si vous ne pouvez pas dire avec confiance lequel des trois archétypes votre projet est, c'est la conversation à avoir d'abord.
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