Most teams describing a "CRM migration" are not actually re-platforming. They are inheriting a HubSpot or Salesforce instance that someone else built, never fully documented, and then handed over alongside a quarter of revenue numbers. The instance works, barely, and the operating model is now constrained by it. That is a brownfield CRM migration. It is a different category of project from a clean install, and pretending otherwise is the most expensive mistake you can make in the first thirty days.
Why this matters now
Switching costs in CRM are not what they used to be. As Jason Lemkin put it in April, at two or three AI agents, switching CRMs is annoying; at ten, it is expensive; at twenty, it is functionally impossible. The system you tolerate today is the system you will be locked into for the next agent generation. The Harvard Business Review's February brief on why digital investments fail to create value pointed at the same root cause from a different angle, the failure mode is not the tooling. It is the failure to redesign how the commercial organization actually generates insight, makes decisions, and coordinates action. A brownfield migration is, in practice, where that redesign either happens or gets deferred for another two years.
The brownfield migration rule, there is no clean slate, so build the audit before you build the architecture
A greenfield migration starts from a blank schema. You decide what objects exist, what fields live on them, what associations are allowed, what the pipeline stages mean. A brownfield migration starts with several years of someone else's decisions baked into a live revenue system. Most of those decisions made sense at the time and do not now. A few were never well-considered. A surprising number turn out to be load-bearing in ways nobody documented.
The rule we hold every brownfield engagement to is, do not change anything in the data architecture until you have triaged every existing decision. The triage is not optional, and the triage is the project. Re-platforming is just what happens at the end.
The keep / edit / delete framework
For every existing data point, every existing field, every existing pipeline stage, every existing automation, every existing report, the answer is one of three things:
- Keep. It still serves a current commercial use case. It does not need rework. It is documented, it is wired correctly, and removing it would break a downstream report or workflow that someone is actively using.
- Edit. It serves a current use case but the implementation is wrong, the data type is wrong, the values are inconsistent, or the workflow is partially broken. Edits get scoped, owned by name, and scheduled before any merge.
- Delete. It served a use case that no longer exists, was never used in the first place, or duplicates something else. Deletes get reviewed for downstream impact, then go.
This framework looks lightweight on paper. The cost is in the discipline. Every property, every workflow, every record type goes through the three buckets. A typical mid-stage B2B SaaS HubSpot instance carries somewhere between several hundred and several thousand individual triage decisions. The team that says "we will figure it out as we go" is the team that ships the migration with the debt intact.
Where the framework gets concrete
Three places where the keep / edit / delete frame sharpens fast in practice:
Pipeline stages and stage definitions
Most inherited pipelines have stages that mean different things to different people. "Closed Won" sometimes means contract signed; sometimes means kickoff scheduled; sometimes means revenue recognized. The migration is the moment to force the definition. Edit, do not delete, but every stage gets a one-sentence definition, an entry criteria, an exit criteria, and an owner.
Custom properties on Deal, Contact, Company
Brownfield instances accumulate custom properties at roughly the rate the team accumulates ideas. A serious audit usually deletes 30–50% of them. The diagnostic question for each, who has read this in the last 90 days, and what decision did they make from it? If the answer is nobody and nothing, it goes.
Workflows and automations
The single most common source of brownfield debt is workflows that fire on now-deprecated triggers, set fields nobody uses, or notify former employees. Every workflow gets read end-to-end, end-state mapped, and triaged. Workflows that survive get renamed to a convention; the rest are paused before any data moves.
Pattern from the field
A B2B SaaS team in DACH at Series B recently came to us with two HubSpot portals and a Salesforce instance that needed to merge into a single system. The instinct was to re-platform: lift everything, drop into a new portal, ship in eight weeks. The actual project shape, after triage, was different. Roughly 38% of the legacy custom properties were marked delete in the first audit pass. Another 24% needed edits, type changes, picklist consolidation, workflow wiring. The remaining 38% kept as-is. The merged instance went live with about a third of the custom-property surface area of the legacy systems combined, and the team's first quarter of reporting on it was the first in two years that did not require a manual pre-pull cleanup step. The migration was not the speed-to-platform we initially scoped. It was the cleanup.
Resolution, a brownfield migration playbook
For any team about to inherit or merge a HubSpot or Salesforce instance:
- Freeze the architecture. No new properties, no new workflows, no new pipeline stages until the audit is complete. The audit takes longer if you keep adding to the surface area.
- Run the keep / edit / delete pass on every object. Properties, pipelines, workflows, record types, list memberships, association labels. Document the decision in a spreadsheet that someone is willing to defend.
- Match against the system that actually drives revenue. If you have data in two systems, treat one as the source of truth and conform the other to it. The migration is not the moment to debate which system wins.
- Fix the workflows before you move the data. Brownfield data on top of inherited automation is the worst of both. Pause every automation that touches a property you are editing or deleting; rewrite the survivors against the post-audit schema.
- Stage the merge in a sandbox. Production migrations are tested in sandbox first, validated against a real reporting workload, and only then scheduled.
- Train on the post-audit system, not the legacy one. A brownfield migration is a behavior change for the team. Documentation written against the legacy system locks in the legacy debt.
If you do steps one through six, the actual data migration is a Friday afternoon. If you skip them, the migration is the next twelve months.
Where Checkpoint comes in
The reason the keep / edit / delete framework holds up under pressure is that it is not a methodology poster, it is the work. Brownfield migrations are most of the CRM work we do at Checkpoint, and we have run the audit cycle on enough HubSpot, Salesforce, and Pipedrive inheritances to know which decisions show up every time and which ones genuinely are unique to your stack. If your brownfield migration is starting from inherited debt rather than a blank schema, talk to us before you choose the platform, the right platform decision falls out of the audit, not the other way around.
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