Most CRM migration projects pick a platform before they pick an archetype. That is the wrong order. Whether you are running a greenfield or brownfield migration changes the scope, timeline, team, and risk profile more than the platform choice does. The platform decision is downstream of the archetype decision. Get the archetype wrong and you spend the next twelve months explaining why the project missed scope, even though every workstream technically delivered.
Why this matters now
Switching costs in CRM are climbing fast. Jason Lemkin's April note in SaaStr made the point bluntly, at two or three AI agents, switching CRMs is annoying; at ten, expensive; at twenty, functionally impossible. The architecture you migrate into, clean schema or inherited debt, gets locked in alongside the platform. A brownfield migration mislabeled as greenfield ships inherited debt into the next decade. A greenfield migration that should have been brownfield burns the inbound funnel on the way to a schema nobody asked for. The archetype decision is where that lock-in is set.
The three migration archetypes
Clean rebuild (greenfield)
A new entity, a new domain, a new ICP, or a deliberate decision to abandon the legacy system. The schema is designed forward against the current operating model. There is no source-of-truth debate because there is no second source. Marketing-attribution history, if it exists, is treated as a read-only archive rather than a live constraint. Greenfield is rare in companies more than two years old.
Sandbox cleanup (semi-greenfield)
The legacy system stays, but the team has accepted that the production instance is unsalvageable as-is. The migration is into a sandbox-built portal with a deliberate cutover. Some history moves; most automation does not. The most common archetype for Series A or B teams that built fast in year one and now need a real schema for year three. Looks like greenfield from the outside, runs like brownfield on the inside.
Brownfield merge
Two or more live systems: typically HubSpot, Salesforce, Pipedrive, plus a marketing-automation tool: converge into a single instance without losing history, attribution, or the workflows the team is currently relying on. The migration is the audit; the audit is the project. The keep / edit / delete framework for triaging an inherited instance is covered in a previous post, that work happens after the archetype decision, not in place of it.
The three questions that pick the archetype
The decision sheet is short, three rows, each answered honestly. Two of three pointing the same way is enough to commit.
1. History value, how much of the legacy system's data is load-bearing for current commercial work?
If marketing attribution, ownership history, or pipeline analytics are actively driving forecasts, renewal motions, or board reporting, the history is load-bearing and you are in brownfield territory. If the legacy system is mainly a contact list with half-built workflows nobody trusts, the history is archival and greenfield is on the table. Diagnostic, who has read this data in the last 90 days, and what decision did they make from it?
2. Deadline pressure, can the inbound funnel go dark for a quarter?
A clean rebuild typically costs the inbound funnel one quarter of attribution continuity. If you have the runway and the leadership cover for that, greenfield is viable. If revenue numbers, board reviews, or a fundraise are anchored to the next quarter's marketing-sourced pipeline, brownfield is forced, regardless of how clean a rebuild would look on paper. Nobody should discover in month four that the CRO's forecast cannot survive a quarter of dark attribution.
3. Schema-debt scope, how much of the legacy implementation is actively wrong?
A serious audit of an inherited HubSpot or Salesforce instance usually flags 30–50% of custom properties for delete and another 20–30% for edit. If the legacy schema is mostly defensible: definitions hold up, workflows fire on current triggers, stages mean what they say, brownfield is a smaller project than it looks. If the schema is mostly indefensible, the cost-of-history calculation flips: you are paying brownfield-audit prices for greenfield-cleanup work, and the sandbox-cleanup archetype is the right answer. Diagnostic, a thirty-minute walk through the property list with the person who built it. If they cannot defend half their fields, the schema is the project.
Why mergers default to brownfield even when greenfield is cleaner
Post-merger CRM consolidations almost always present a clean greenfield argument on the whiteboard: new combined entity, new ICP, new positioning, new domain. The argument falls apart in the first scoping conversation. One of the two systems is always carrying history nobody is willing to abandon, months of marketing attribution, an active partner program built on association labels, a lifecycle-stage definition the renewals team is forecasting against. The cost of going dark on any of those for a quarter is higher than the cost of inheriting the schema debt. Greenfield is technically possible. Brownfield is what ships.
What a wrong call looks like 90 days in
The two failure modes are mirror images of each other.
Greenfield-when-it-should-have-been-brownfield: the new portal is clean, the schema is correct, and nobody trusts the numbers because the attribution chain broke at cutover. New-system reports do not match the old system's for the overlapping period. The CRO forecasts off the legacy export for two quarters while the team rebuilds attribution. Technically successful and commercially invisible.
Brownfield-when-it-should-have-been-greenfield: the merged portal works, but it carries fifteen lifecycle stages where there should be five, three deal pipelines that mean the same thing with different stage names, and a thousand custom properties of which a third are unused. Every new workflow takes twice as long because it has to navigate inherited debt. Eighteen months later someone else is hired to migrate the migration.
Pattern from the field
A B2B SaaS team in DACH at Series B recently came in with what looked like a textbook greenfield case: two companies merging, new domain, new ICP, fresh positioning. The whiteboard instinct was a clean rebuild: new portal in eight weeks, both legacy systems retired on cutover day. The decision sheet did not agree. History value: one of the two portals carried roughly eighteen months of marketing-attribution data the inbound funnel was actively running on. Deadline pressure: the next two quarters had a board-anchored pipeline number tied to that funnel. Schema-debt scope: messy but defensible, most properties had owners, most workflows fired on current triggers. Two of three rows pointed at brownfield. The decision flipped in the first scoping session. The project shipped as a brownfield merge against the cleaner of the two portals; the inbound funnel did not go dark; schema cleanup happened in the audit phase. Eight weeks later the team had a single instance with about a third of the legacy custom-property surface area and an attribution chain the CRO could forecast against.
Resolution, the archetype decision playbook
Before any platform decision, before any data movement, before any kickoff:
- Run the three diagnostic questions on a single page. History value, deadline pressure, schema-debt scope. Two columns: greenfield-leaning, brownfield-leaning. Force a binary answer per row.
- Walk the property list with the person who built it. Thirty minutes, no slides. If they can defend most of their fields, the schema is brownfield-recoverable. If they cannot, sandbox-cleanup is on the table.
- Check the attribution chain against the next two quarters of forecast. If the marketing-sourced pipeline number anchors a board review or a fundraise, brownfield is forced, write that down before the platform conversation.
- Name the archetype out loud, in writing, with the CRO and the head of marketing in the room. A migration where leadership cannot agree on the archetype will mis-scope itself by month three.
- Pick the platform last. The right platform for a greenfield rebuild is not always the right platform for a brownfield merge. The archetype narrows the platform shortlist.
- Re-test the archetype at week six. If a brownfield project is producing more delete decisions than keep decisions, it may be a sandbox-cleanup mislabeled as a brownfield merge. Catching that at week six costs a re-scope; catching it at month four costs the timeline.
Two of three rows pointing the same direction is enough to commit. One of three is the conversation worth slowing down for. Zero of three is a project that has not been scoped yet.
Where Checkpoint comes in
The archetype decision is the single most leveraged conversation in any CRM migration. Get it right and the rest of the project is execution. Get it wrong and every downstream decision compounds the mis-scope. Checkpoint runs the three-question decision sheet on every CRM migration engagement before any platform conversation. If you cannot say confidently which of the three archetypes your project is, that is the conversation to have first.
Sources
- Sinha, Shastri, Lorimer. "Why Your Digital Investments Aren't Creating Value." Harvard Business Review, February 16, 2026. hbr.org
- Lemkin, Jason. "Which CRM Should You Use in 2026/2027? Follow the Agents." SaaStr, April 6, 2026. saastr.com