The situation
A growing B2B company had outgrown Pipedrive and moved to HubSpot. The move itself happened. The data came across. On paper, a successful migration.
In practice, three things had gone wrong before we were called in — and each one on its own would have been enough to make the CRM a place people avoided. Together they meant the platform existed, was paid for, and was barely used.
We were brought in to rework it before the company rolled HubSpot out to several more locations — which is the right time to fix it, and very nearly was the last.
What had gone wrong
1. The data was imported exactly as messy as it left
Nobody cleaned or structured the Pipedrive export before the bulk import. Whatever shape the data was in on the way out, it arrived in HubSpot the same way — only now it was the system of record.
The worst of it: single fields holding multiple historical values at once. A field that should carry one fact carried a little archaeology of everything that fact had ever been — an old status, a newer one, a note someone left, all stacked in the same cell. You cannot filter on that. You cannot report on it. You cannot automate against it. It looks like data and behaves like a paragraph.
A migration is not a data project with a cleanup at the end. The cleanup is the project, and it belongs before the import, in the old system, while the mess is still someone else’s problem to explain. Skip it and you don’t migrate your data. You migrate your debt, and pay interest on it in every report from then on.
2. The contract was the wrong shape for the actual need
The company was on HubSpot’s middle tier — Professional — with all the modules it brings. It read like the sensible middle: more than Starter, cheaper than Enterprise.
But the need didn’t match the shape. As the business grew, what it actually required were a couple of Enterprise-level capabilities — not the full breadth of Pro’s modules, most of which went untouched. Fewer modules at the right tier would have fit better than every module at the wrong one. The contract optimised for breadth the team never used and skipped the depth it was starting to need.
Underneath that sat questions nobody had answered before signing. How many contacts is this business actually going to hold and work? How many of those are marketing contacts — the ones you pay to keep? And is there any strategy at all for engaging and re-engaging the contacts already sitting in there, some of them for years? Without those numbers, a licensing decision is a guess with a purchase order attached. We sized them, so the next renewal could be a decision instead.
3. The CRM was designed by the one person who shouldn’t have
This was the largest problem, and the most human.
The build had been speced by a BDR — a salesperson, not a CRM architect — who asked for a layout and a pipeline that made sense to him. And it did make sense to him. It made sense to no one else. His own team ended up not using the CRM as they should, for the simplest possible reason: they had no idea what the multiple stages meant. Stages built around one person’s mental model are illegible to everyone who doesn’t share it.
This is not a story about a BDR who got it wrong. He answered the question he was asked. The mistake was upstream — letting an architecture decision be owned by someone whose job is to sell, not to design the system everyone else has to live in. Ask a specialist to specify their own tool and you get a tool for one specialist.
We simplified. We cut stages that carried no shared meaning and kept the few that did — the ones every rep could name without a cheat sheet. A pipeline stage has to mean the same thing on a sales call, in a report, and to a new hire in week one, or it means nothing. We did this before the other locations were enrolled, which was the whole point: a confusing pipeline copied to five sites is five confused sites, and much harder to unpick once each has made it their own.
Where it landed
The data was untangled — the stacked fields split back into single facts that filter, report and automate. The pipeline was cut down to stages people could actually use, and read the same way everywhere. And the licensing was sized against real numbers, so the platform could be matched to the need instead of the other way round.
Then, and only then, the rollout to the other locations went ahead — onto a system that was legible from day one, rather than one each site would quietly work around.
What we’d tell you before you start
Three lessons, and they’re the three problems turned around.
Clean before you import, in the old system — not after, in the new one, where every fix looks like a migration bug. Size your contacts and your licensing before you sign, not at the renewal when it’s a sunk cost. And never let the person who is best at using a tool be the person who designs it — those are different skills, and confusing them is how you end up with a CRM that one person loves and a team quietly avoids.
The migration was the easy part. It always is. What breaks is everything nobody decided on purpose.
