CRM Cleanup & Rebuild
Deleting half a CRM is a nerve question, not a scripting question. I inherited a 4-year-old HubSpot instance that several different leaders had run in and out of, and in about 30 days I cut it down to what was actually real.
Nothing went out on a hunch. Most of the junk traced back to one identifiable source, every record got classified before anything moved, and the deals, the part you cannot rebuild, were reclassified instead of deleted.
The problem
Four years of data, several leaders in and out, and nobody fully trusting what was in there. The CRM was bloated with duplicates, dead records, and junk auto-creates.
Roughly 65,000 contacts, 30,000 companies, and over 1,200 deals sitting in the active pipeline, with no clean way to tell what was real from what was noise.
A CRM in that state is not just messy, it is actively misleading. People stop trusting the numbers, and then they stop using it.
What I did
Over roughly 30 days I worked it down to what held up:
- ~65,000 contacts down to around 20,000 to 25,000.
- ~30,000 companies down to around 10,000 to 12,000.
- Over 1,200 pipeline deals reclassified: a few hundred kept as historical, roughly 100 truly active.
All in, that is more than half the records gone, tens of thousands of dead or duplicate entries cleared out of the system.
Why that was safe to do
Half a database in a month is a lot to remove. The scripting is the easy half. The question anyone sensible asks is how you knew.
- The junk had a source. Most of it was records auto-created by email tracking, not people anyone had ever worked. Once you can name where bad records come from, you can find all of them instead of eyeballing rows.
- Classification came before removal. A workflow tiered every company first. Cutting then meant acting on a label the whole team could see, not on a feeling about a record.
- The deals were never deleted. Over 1,200 got reclassified. A few hundred stayed as history, roughly 100 stayed active. The pipeline number came down. The record of what the team had actually done did not.
are the one thing you cannot rebuild. Contacts and companies can be re-enriched from outside. A deal is a thing your own team did, so deleting one deletes history nobody can get back. That is why none were.
Keeping it from rotting back
A cleanup you do once is a cleanup you do again next year. So the rules matter more than the purge.
The instinct is to lock the front door and control who gets to import. I went the other way. Imports stay open from any source and the classification workflow is the quality gate instead. Gate the import and people keep their real list somewhere else, and then you have two lists and neither one is true.
Then I built the hygiene rules and automation to keep it clean, so it would not quietly rot back to where it started.
What keeps it clean now
Deduping, junk suppression, and consistent tagging, baked into the system instead of done by hand.
Auto-created junk gets flagged as it arrives and lands on a standing suppression list, so a bad record can sit in the database without ever reaching a send. Suppressing a record is reversible. Deleting it is not.
The payoff
Once I had a CRM I could trust, I used it.
I pulled the historical outbound sales and marketing attempts, the years of campaigns sitting in the data, and analyzed how they actually performed.
Then I took what worked and used it to rewrite the messaging and build a net-new outreach framework.
So the cleanup was not just tidying up. It became the foundation for smarter outbound, grounded in what had really moved the needle before.
Why it matters
This is the unglamorous work that everything else depends on. You cannot score leads, forecast, or run good campaigns on data you do not trust.
Getting a four-year-old CRM back to clean, and keeping it there, is what makes the rest of RevOps possible.
The hard part was never writing the queries. It was knowing which records are recoverable, which are somebody's history, and which rule you have to leave loose so people keep using the system instead of working around it.