The work, decision by decision

The second move, one decision at a time

1. Back up before touching anything. Known: the records in HubSpot were the only complete copy of the book. I asked what I would need if the move failed halfway, and the answer was a full cold export, every object and every schema, to plain files on our own disk. It was taken early that morning, before a single record moved. It changed the day from a bet into a rehearsal: anything that broke could be rerun from the backup.
2. Companies first, then people. Known: the value of the book is in who works where. I asked what order keeps those links intact, and it had to be companies first, then people pointing at companies that already existed. It produced a book where every person landed attached to their company, with the associations carried across rather than rebuilt by hand.
3. Every record keeps its old ID. Known: I might have to run the move more than once, and some day move again. I asked how to make a rerun safe, and the answer was to write each record's old identifier into the new one and match on email for people and on domain for companies. It produced a migration that could run twice without creating a duplicate, and a trail from every new record back to where it came from.
4. Map in who I actually talk to. Known: the CRM held the people who had filled out a form or been entered by hand, and missed most of the people I call. I asked what would make the book reflect real relationships, and the answer was the phone's contacts and the message history. I carried the signal only: how often, how recently, how many conversations. No message text went in. It changed the book from a list of names into a map of which relationships are active.
5. Leave the raw leads in the archive. Known: the original lead vault held far more names than anyone at the firm has ever spoken to. I asked whether a stranger belongs in a relationship book, and the answer was no. The raw list stayed archived and searchable, outside the live book. It kept the book small enough to trust.
6. Keep the old system until the counts match. Known: a migration that looks finished is not the same as one that is. I asked what proof I would accept before retiring HubSpot, and the answer was the record counts on both sides lining up. HubSpot stayed live, untouched, until they did.

What landed, and what it changed

The full book landed in one day. The counts on the cover come from the migration log, and the chart below sets each move beside the other. The highlighted bar is the one that matters most: the associations, the links between people and companies, which a funnel tool treats as an afterthought and a relationship book treats as the point.

What changed was the kind of question the firm could ask. Before the move, the CRM could tell me what stage a contact was in. After it, the book could tell me who we know at a company, who introduced them, when I last spoke to them, and what they bid the last time we asked. Those are the questions a deal or a bid actually starts from. They are also the questions our sales agents are trained on, so the shape of the book is the shape of what those agents can know.

What we kept, replaced and installed

We kept the records themselves and their history. Nothing was retyped, and every record still carries the ID it had in HubSpot.

We replaced HubSpot, and the idea behind choosing it. I put it in that April, and I chose it the way most operators choose software: on how quickly it stands up and how familiar the name is. The fault in that logic was that it judged the tool before it judged the work. A marketing-funnel CRM assumes each contact is on a path toward one sale and scores them on the way. Our book is a network where the same people come back across many deals in different roles. It had to change in May rather than later because the vendor rule of 6 May meant every week added bids, rates and call history into a shape that did not fit them, and every week made the next move more expensive.

We installed three things. A records-and-relationships CRM as the firm's single book. The migration routine itself: backup first, companies before people, keyed IDs, signal without message text, counts matched before the old system goes. And the test below, which I now run before the firm puts its records into any system.

What it cost, and what I would watch

It cost two migrations in one month where one should have done, and most of three weeks working in a tool that was already the wrong shape. It cost a paid subscription that barely got used. And it cost the small embarrassment of being the operator who installs a system and then pulls it out, which is the cost that keeps most people on the wrong tool for years.

The same rule applies to it as to anything else we run. Systems here are not precious. If a tool stops fitting the work it gets replaced, and because every record carries a key we control, the data moves with it.

What I would watch, for any firm about to move its contacts:

• The question, not the demo. A CRM demo shows the funnel because the funnel is what it sells. Bring your own questions and make the tool answer them.
• The first month. The cheapest time to admit a system is the wrong shape is before anyone has built on it. After that, every week of history is a reason to stay.
• The links, not the rows. Counting people and companies is easy. Count the associations too, because those are what a bad migration drops without telling you.
• What stays out. A relationship book gets worse as it fills with people nobody knows. Decide what belongs in the archive before you decide what goes in the book.

What it produced

The full book, 3,951 people, 2,934 companies and 3,469 associations, landed in one day on 13 May 2026, eighteen days after the first move. The migration routine itself, backup first, companies before people, keyed IDs, counts matched before the old system goes, is now the standing rule before any Common Ground record moves into a new system.

A slice of the project list

A few related projects.

• The RFP outreach workflow: a daily bid sweep, a rubric-matched proposal method, and the two-question gate that should run first
• The voice engine: teaching a model to sound like the person it is speaking for, measured by a blind test
• Credibility and the story pipeline: a claims register with a status and a source on every row
• Kinwork: the client portal, the visibility engine and the systems audit, built for our own portfolio first
• The data room pattern: one template and one access standard, now running more than ten rooms
• AI sales agents trained on our own record, held to a human gate before anything reaches a client
• The operating system itself: sessions built by type of work, a measured floor cost, and a review chain before anything ships unattended