How to rebuild Zendesk-style support workflows in HubSpot Service Hub without blowing up your queues.
What you should migrate from Zendesk — and what to leave behind
Every Zendesk-to-HubSpot conversation starts the same way: someone exports a giant list of ticket fields, views, macros, and triggers, and asks, "How do we bring all of this over?"
That's the wrong question. The right one is: What parts of this setup actually keep customers happy and agents sane?
The artifacts in Zendesk are the residue of years of patching. Old brands, legacy SLAs, one-off triggers somebody wrote for a single enterprise client — it's all in there. If you treat that as a spec instead of an archaeological site, you'll drag every bad habit straight into HubSpot Service Hub.
Start smaller. Pull a sample of the last 100 tickets from Zendesk and look at:
That's your real requirement list for HubSpot, not whatever's in the admin UI.
You do not need every comment on every ticket since 2014 to run good support next quarter. For most mid-market B2B teams, a pragmatic pattern is:
That keeps HubSpot fast and usable while preserving the audit trail for the handful of accounts where history matters. It also keeps migration costs and risks within mid-market reality.
The migration mechanics themselves — pulling tickets from Zendesk's API, mapping fields to HubSpot's ticket schema, preserving associations to the right contacts and companies — are where most projects either land cleanly or drag for months. We've done enough of these to have strong opinions about which migration paths are worth fighting for and which to abandon.
If an automation in Zendesk exists only because "the system used to be bad at X," don't bring it. HubSpot handles some things differently: shared inbox behaviors, conversation routing, and how tickets relate to contacts and companies. Recreating every quirky workaround will just confuse your team.
Before you commit to any trigger, macro, or automation as "must migrate," ask:
Being ruthless here is the difference between a clean move and a decade of cruft following you into the new platform.
If you want help thinking through that cut line with someone who has done it before, this sits squarely in how we work with service teams evaluating HubSpot: Who We Help: Service Teams.
The most common mistake we see is trying to rebuild Zendesk's exact configuration in HubSpot. Different platform, different assumptions. If your HubSpot ticket pipeline ends up with a dozen stages like New, Open, Pending, On Hold, Solved, and Reopened, you've recreated the clutter without the parts of Zendesk that made it tolerable.
A cleaner pattern for most B2B mid-market teams is to decouple workflow state from ticket status. Use a small number of pipeline stages for where the ticket actually sits in the resolution journey. Use custom properties for edge cases like "waiting on customer" or "blocked by vendor." That gives you better reporting and less micro-drag for reps.
The same logic applies to pipelines as to deal stages — a ticket stage means "the work has progressed." A status means "the work is stuck, in a specific way we should track." When you blur the two, your reporting blurs with it.
HubSpot lets you run multiple ticket pipelines. That doesn't mean you should spin them up for every customer or product line.
A defensible baseline is one primary support pipeline per distinct motion:
Within each, keep stages focused on where the work happens: New, In Progress, Customer Review, Resolved, Closed. Use assignment and custom fields for team-specific routing instead of stages that read like "Tier 2 – UK" or "Escalation Queue 3."
For mid-market teams with limited admin capacity, this is also how you avoid running three separate help desks by accident. A small number of pipelines, wired cleanly into views and SLAs, is easier to govern than a zoo of one-off boards.
Zendesk SLAs tend to grow like ivy: layered conditions and exceptions that no one person can fully explain. When you move into HubSpot, take the opportunity to rewrite SLAs as plain statements of expectation before you touch a settings screen.
A few examples that work for many B2B support teams:
Once you agree on those human-readable rules, configure HubSpot SLAs and workflows to support them. The documentation for the mechanics is straightforward — search HubSpot's Knowledge Base for "set up SLA" and "configure help desk." The hard part isn't the click path. It's the negotiation across Support, Sales, and Customer Success about what "high severity" actually means, and who's allowed to declare it.
This is where we often get pulled in through Service & CS engagements: as the neutral third party who can translate between what the platform can do and what frontline teams are actually willing to sign up for.
A lot of migrations fail because there's no shared definition of success for the first week on HubSpot. You don't need every historical macro migrated and every report rebuilt. You do need three things working cold: tickets coming in, agents replying inside HubSpot, and leadership seeing enough reporting to know nothing's on fire.
Write that down. Literally — a one-page "Day One Readiness" checklist with:
If something isn't on that list, it belongs in Phase Two.
For most mid-market teams, a 2–4 week parallel run is the sweet spot. Too short and you won't catch edge cases. Too long and agents will keep defaulting back to Zendesk because it feels safer.
During that window:
We use this parallel pattern at Pivot when we're on the hook for both the migration and the cutover. It gives the team enough muscle memory that, when Zendesk finally goes read-only, HubSpot isn't a stranger.
Once you're live, the temptation will be to immediately layer on "nice to have" automation — CSAT popups everywhere, complex triage rules, AI summaries on every ticket. Hold that impulse for one quarter.
Use the first 90 days to stabilize:
After that, you can have a more honest conversation about where to invest: AI summaries, better knowledge base hooks, or deeper integrations with Sales and CS. The team that goes live on Monday and rolls out three new automations on Friday is the team that's still untangling them at Christmas.
If you want a comparative take on where HubSpot wins and loses against Zendesk for your specific motion, this post is a good companion read: HubSpot vs. Zendesk: Which Customer Support Platform Is Right for You?
After the first 90 days of stabilization, the natural next conversation is AI — and specifically, HubSpot's AI Customer Agent. It's a real tool, it's genuinely useful, and we use it ourselves at Pivot. But the sequence matters, and most teams get it wrong.
Get the migration done first. Then get everyone comfortable. Then accelerate.
A team that's still relearning HubSpot's ticket layouts, second-guessing the new SLA logic, and exporting to Excel because they don't trust the dashboards yet is not a team that's ready to add an AI agent to the mix. Customer Agent will surface every gap in your KB, every fuzzy ticket category, and every undefined escalation path — all at once. That's useful information if your team has the bandwidth to act on it. It's a frustration generator if they're still finding their footing.
The right sequence looks like this:
At Pivot, we run our own AI Customer Agent — Oscar — for retainer client questions about points balances and project status. We didn't turn him on the day we set up the workspace. We turned him on after we'd run the basics ourselves for long enough to know what good looked like. The point isn't that Oscar's setup is right for you. It's that AI agents amplify whatever system they sit on top of. If the system is solid, they make it better. If the system is shaky, they make the shakiness visible to your customers.
Get the foundation right. Get the team comfortable. Then accelerate.
If you do this well, your agents should feel like the move to HubSpot removed tools from their stack, not added them. If the team feels like they're running two systems in parallel six months later, something in the design or cutover planning needs another look.