The migration that imported the mess

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 instead carried a little history of everything that fact had ever been - an old status sitting next to a newer one, plus a note someone left, all stacked in the same cell. You cannot filter or report on that, and you certainly cannot automate against it. It looks like data and reads like a paragraph.

Cleanup is the real work of a migration, 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 carry the debt across with the records, then 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 looked like the sensible pick, a step up from Starter without paying for Enterprise.

But the need didn’t match the shape. As the business grew, what it required were a couple of Enterprise-level capabilities, not the full breadth of Pro’s modules, most of which went untouched. The contract paid 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 going to hold and work? How many of those are marketing contacts - the ones you pay to keep? Is there any plan for engaging and re-engaging the contacts already sitting in there, some for years? Without those numbers, a licensing decision is guesswork with a purchase order attached. We put numbers to all three, so the next renewal could be decided on evidence.

3. The CRM was designed by the one person who shouldn’t have

This was the biggest of the three, and the one about people rather than data.

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. It did make sense to him, and to nobody else on the team. They ended up avoiding the CRM for the simplest possible reason: they had no idea what the many stages were supposed to mean. A pipeline built around one person’s mental model is unreadable to everyone who doesn’t share it.

The BDR didn’t get it wrong; he answered the question he was asked. The mistake sat upstream, in letting someone whose job is to sell own an architecture decision that the whole team then has to work inside.

So we simplified. We cut the 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 read the same way on a sales call and in a report, or it stops being useful. We did this before the other locations were enrolled, which was the whole point: a confusing pipeline copied to five sites just gives you five confused sites, and it gets much harder to unpick once each one has made it their own.