Migrate the Dormant Accounts First

"How do you handle the delta?"

The client's systems lead asked it halfway through a Salesforce-to-HubSpot migration planning call last week, and it's the question that decides how the whole migration runs. The customer list we're about to move is live. Sales is still closing. Billing is still issuing credits. Whatever count we agree on today is wrong by tomorrow morning.

He'd done this a few times before, with other systems, and his answer was the one most operators land on: a cutover day. Shut the business down for six to ten hours, move everything at once, bring the new system up. He's right about the problem. Two live systems means two sources of truth, and every week you run both you spend time chasing stragglers.

A cutover day has its own failure, though, and it's the expensive one. Your first look at real customer data in HubSpot happens the morning you go live.

Split the customer list by last activity date

The textbook options are trickle or big bang. Trickle: migrate now, pick a date to start working in HubSpot, sweep for new records every week or two until the old system is empty. Big bang: one downtime window, everything at once.

We're doing neither. We're splitting the customer list in two by last activity date.

Dormant accounts go first, weeks before go-live: customers nobody has touched in months, with their contacts, closed opportunities, contracts and credit history. Closed-lost opportunities can go early too. Nothing is changing on them.

Active accounts wait for cutover day: open opportunities, recent closed-won deals, and the leads the sales team is working right now. That set is small, so the downtime window shrinks from most of a day to a few hours.

Just before switch-off, we re-check the dormant list for anything that woke up during the build. If a dormant customer called in while we were building, they move with the active set.

Users can't test against sample data

Moving dormant accounts early is for UAT, and it changes what UAT can be.

There are two kinds of user testing, and clients usually plan for one. The first is process testing: run a lead through the new qualification pipeline, book a meeting, watch the deal get created. Made-up records are fine for that.

The second is recognition. A rep opens a customer she knows and checks: are the contacts here, is the last order form attached, is the credit memo from March where I'd expect it. She compares it to Salesforce side by side. That test only works with real accounts, and it's the one that decides whether the team trusts the new system on day one.

Dormant accounts are perfect for it. They're real, they're complete, and nobody is editing them while you test.

Rebuild one ugly account by hand before you script anything

Before any bulk import, we asked for one account, and we asked for a messy one: multiple contracts, several service activations, four credit memos against it, exported with every related object as CSVs. Our lead consultant is rebuilding it in HubSpot by hand this week. Then we sit with the client and check it against the Salesforce record field by field.

That one account does three jobs. It shows which fields are missing from the design (there will be some). It proves the associations survive the trip. And it writes the plan for every other account, because the bulk migration is that rebuild, repeated.

It also shows what shouldn't move at all. On this call, the billing account object turned out to hold a handful of fields that belong on the company record, so it won't exist in HubSpot. The credit memo object turned out to be a credit memo request, with the issued credit living in the billing system, so it's being rebuilt under its real name. Twenty-six legacy service-activation processes came out as eight. Cases aren't coming over.

The archive is what makes "don't migrate it" a safe answer

Every "we're not bringing that" decision above is only safe because of the last step. In the final month, once Salesforce is read-only, the client exports a full snapshot to their data warehouse. Every object, including the ones HubSpot never sees.

If someone needs an old case or invoice next year, it's in the warehouse. If we find in January that a field mattered after all, we pull it from the snapshot and import it. Without that export, every scoping decision becomes permanent, and teams respond by migrating everything, which is how a greenfield build turns into a Salesforce clone with a HubSpot logo.

One more thing. The export is the client's job, with a hard deadline, because the day the Salesforce contract ends there is no recovery path.

If you're planning a move off Salesforce: how are you handling the delta? And if you've run a single cutover day and it went fine, I'd like to hear what your UAT looked like, because that's the part I think most plans skip.

This came out of a client project. The story behind it, and what to check in your own portal, goes to subscribers on Thursdays. Get Thursday's note.