Service Cloud to HubSpot Service Hub Migration: What Moves and What You Rebuild

When teams move from Salesforce to HubSpot, support is almost always the part that gets planned last. Sales data gets the workshops and the field mapping sessions. Then, a week before cutover, someone asks how cases will come in on Monday morning. That's when the trouble starts.

If you're moving support from Salesforce Service Cloud to HubSpot Service Hub, the data is the easy part. The hard part is the plumbing around it: how requests arrive, who they go to, and what clock is running on them. This post covers what maps cleanly, what you rebuild, and how to switch without losing a single customer email. It builds on my Salesforce to HubSpot migration work, where the support piece comes up on almost every project.

Why support migrations go wrong

In Salesforce, support logic is spread across a lot of places: Email-to-Case settings, case assignment rules, escalation rules, entitlements and milestones, queues, auto-response rules, and often a few flows someone added later. None of it lives on the case record itself. So when you export cases and import them into HubSpot as tickets, the history comes across but the behavior doesn't.

The result is a HubSpot portal that looks right on day one, with all the old tickets there, and then quietly drops new ones. Emails land in an inbox nobody watches. Tickets have no owner. Nobody gets alerted when something urgent sits too long.

What maps cleanly

• Cases to tickets. Subject, description, status, priority, owner, created and closed dates, and the related contact and company all have a natural home on the HubSpot ticket.
• Case status to ticket pipeline stages. Salesforce case statuses become stages in a HubSpot ticket pipeline. This is a good moment to cut statuses nobody uses.
• Record types to pipelines. If you used case record types for different support lines, separate ticket pipelines usually work better than one pipeline with a type field.
• Custom case fields to ticket properties. Map only the fields someone reports on or routes by. The rest can go in an archive.

What you have to rebuild

• Intake. Email-to-Case addresses don't move. You connect each support inbox to HubSpot's help desk or inbox and test it with a real email from outside the company. If Salesforce was forwarding from your mail server, that forwarding rule has to change at cutover.
• Routing. Case assignment rules and queues become ticket workflows or inbox routing rules in HubSpot. Write down every rule before you start, including the catch-all, because the catch-all is usually where tickets get lost.
• Response clocks. Entitlements and milestones don't have a one-to-one match. HubSpot has SLA settings for tickets, but they work differently, so decide which promises you actually make to customers and rebuild only those.
• Escalations and alerts. Escalation rules become workflows that notify a person or reassign the ticket after a set time.
• Knowledge. Salesforce Knowledge articles need to be exported and rebuilt in HubSpot's knowledge base. Plan for cleanup, since old article formatting rarely survives as is.
• Surveys and reports. CSAT or other feedback surveys, and the support dashboards leadership uses, get rebuilt. Agree on the three or four numbers that matter before you rebuild anything.

How to cut over without losing cases

1. Inventory first. List every inbound channel (email addresses, web forms, chat, phone logging) and every rule that touches a case. I usually find at least one inbox nobody remembered.
2. Decide on history. Bring over open cases plus the history your team really looks back on. Older closed cases can live in an export or an archive.
3. Build and test routing with fake tickets. Send test emails to every support address and submit every form. Confirm each one creates a ticket, lands in the right pipeline and gets an owner.
4. Freeze, migrate open cases, then switch intake. Pick a quiet window. Stop new case creation in Salesforce, move open cases, then point the inboxes at HubSpot. Do it in that order, so nothing arrives in the gap.
5. Run a short overlap. Keep Salesforce read-only for a few weeks so agents can look up old context. If you're moving in phases, my phased Salesforce to HubSpot migration post covers running both systems side by side.
6. Watch the catch-all. For the first two weeks, check every day for tickets with no owner or in the default stage.

If cases were already going missing in Salesforce, fix the cause before you rebuild it. My post on Email-to-Case not creating cases walks through the usual causes, and most of them apply to any help desk.

How to tell if this is you

• Your migration plan has a detailed sales section and one line for support.
• Nobody can list every email address that currently creates cases.
• You use entitlements or milestones, and nobody has decided what replaces them.
• Your support team doesn't know which day they start working in HubSpot.
• Knowledge articles aren't in the plan at all.

If two or more of these sound familiar, add a support workstream to the plan now. It's a lot cheaper to do it before cutover than to find out from an unhappy customer.

FAQ

Can you migrate Salesforce cases to HubSpot tickets?

Yes. Cases import as tickets with their status, owner, dates and related contacts and companies. The routing rules, entitlements and escalations around them don't migrate and have to be rebuilt in HubSpot.

Does HubSpot Service Hub replace Salesforce Service Cloud?

For many growing B2B support teams, yes. Teams with complex entitlements, field service or heavy omni-channel routing should test those processes in HubSpot before they commit.

What happens to Email-to-Case when we move to HubSpot?

It stops working at cutover, so each support address has to be connected to HubSpot and tested with real emails. Switch intake only after open cases have moved.

Should support move at the same time as sales?

Not always. Many teams move sales first and support in a second phase. That works well as long as both systems share the same contact and company data during the overlap. My migration planning checklist covers how to sequence it.

If you're planning a move from Service Cloud to Service Hub and want a second set of eyes on the support side, I'm happy to talk it through. Let's talk.