Zendesk Sell to HubSpot Migration

Whatever rule in Sell used to spin up a task or fire an action the moment a record changed has to be rebuilt from nothing; none of that logic travels with the record it used to watch.

HubSpot: Workflows

Sequence it deliberately: get the pipelines and properties in place first, then rebuild each rule one at a time against a system that is actually ready to hold it.

The rules that decided which rep a new lead landed with have no path across either; routing has to be designed again from scratch inside HubSpot.

HubSpot: Workflow rotation actions

Create the users and teams before a single routing rule is built, then test the distribution against real records rather than trusting it from the configuration screen alone.

A Sell list that updated itself against a saved rule has no equivalent that carries the rule across with it; only the idea of the list survives the move, not the logic behind it.

HubSpot: Active lists and saved views

Treat it as a rule to rebuild, not a membership to import: recreate the actual criteria in HubSpot, because carrying the list across as it stands simply freezes it at whatever it held on migration day.

A multi-touch outbound sequence built in Sell needs reconstructing step by step in HubSpot; nothing about the sequence logic imports along with the records it was sending to.

HubSpot: Sequences

HubSpot enrols a sequence per rep and per connected mailbox rather than at the account level, and the sending limits are not the same as Sell's, both worth checking before promising the rebuilt sequence will run exactly as it did before.

Any action that used to fire the moment a deal moved stage in Sell needs its own rebuild; stage-change automation is not something the migration carries across on its own.

HubSpot: Deal stage workflow enrolment

Get the sequence right: the pipeline stages need to exist in HubSpot before a single workflow can be built to trigger on them.

Where Support is part of the same move, its one-click macros carry the same rebuild burden as everything on the Sell side, one more reason to scope the two products as a single project rather than two separate ones.

HubSpot: Snippets, templates and workflows

This only applies if Support is genuinely part of the migration, and where it is, budget for the multiplication: a single Zendesk macro tends to become several HubSpot objects at once, against a help desk macro cap worth checking early rather than discovering it at the limit.

Performance reporting broken down by rep and by team has to be rebuilt rather than carried over with the records it measures.

HubSpot: Custom reports and dashboards

Every owner has to resolve to a real HubSpot user on import, or the reporting built on top of it attributes everything to nobody rather than to the rep who actually did the work.

Pipeline forecasting has to be rebuilt on the HubSpot side, not carried across as a finished report.

HubSpot: Deal reports and forecasting

Treat this as configuration first and reporting second: amount, close date and stage probability all need setting deliberately before a forecast built on top of them means anything.

Activity volume reporting, calls, emails and meetings together, restarts at zero on the new platform unless the history behind it is deliberately carried across.

HubSpot: Activity reports

It genuinely resets at migration unless the activity history is extracted first, which is the same expensive step already flagged above for calls and meetings, not a separate cost on top of it.

Whatever targets were set for reps and teams in Sell have to be entered again in HubSpot; nothing about the numbers themselves carries across.

HubSpot: Goals

This is configured per user rather than once for the account, so budget it as a repeated task, not a single setup step.

A saved report in Sell is a definition, not an object that transfers, so it needs recreating in HubSpot's own reporting tool from scratch.

HubSpot: Custom reports

Rebuild it from the question the report was actually answering rather than copying the old layout, since HubSpot's reporting tool rarely lines up filter for filter with Sell's.

Sell's deal pipelines and their stages are the first thing to rebuild in HubSpot, because everything downstream of them depends on the structure already being there.

HubSpot: Deal pipelines and stages

Build this before anything else on the list: every other rebuild, workflows, reports, goals, assumes the pipeline is already in place.

Whatever scoring logic Sell used to rank an incoming lead has no path across and needs designing again from the signals HubSpot actually records.

HubSpot: Score properties

Build it from scratch against what HubSpot itself tracks, rather than trying to reproduce Sell's exact scoring rules on a system that measures different things.

Message templates and the sequences built on top of them need rebuilding together, since neither carries across on its own.

HubSpot: Email templates and sequences

This is manual work: personalisation tokens are named differently between the two platforms and will not carry across, so every template needs checking rather than a straight copy-paste.

The saved segments a team actually works from day to day have to be rebuilt as HubSpot lists rather than assumed to transfer with the records inside them.

HubSpot: Active lists and saved views

Prioritise whichever segments are used daily and have those rebuilt before go-live; the rest can follow afterwards without anyone noticing the gap.

Revenue and activity targets set in Sell need re-entering in HubSpot's own goals tool; the numbers do not travel with the rest of the data.

HubSpot: Goals

Set these per user, and only once the users themselves already exist in HubSpot, or the target has nobody to attach to.

Email templates and the call scripts reps actually work from both need rebuilding, and neither is a given on every HubSpot plan.

HubSpot: Templates, snippets and playbooks

Confirm playbooks are actually included on the plan under consideration before promising the call-script side will have anywhere to live; it is a tier question, not a given.

The product catalogue and its pricing, wherever it is attached to a deal, needs rebuilding directly in HubSpot rather than carried across with the deal record.

HubSpot: Products and line items

Import the catalogue before the deals themselves, or the line items will have nothing to attach to and every deal total lands as a flat, unexplained number instead of a priced breakdown.

Every login and the access level attached to it needs recreating in HubSpot; none of that structure carries across from Sell.

HubSpot: Users and permission sets

Create the users before a single record is imported, so record ownership actually has somewhere to resolve to rather than failing silently.

However reps were grouped in Sell needs rebuilding as HubSpot teams; the grouping itself does not carry over.

HubSpot: Teams

Map what the grouping was actually meant to achieve rather than copying its literal structure, since a straight copy tends to carry old habits across along with it.

Territory assignment, whether it runs by geography or by account, has no direct HubSpot object to land in and needs designing from the ground up.

HubSpot: Properties plus workflow-based assignment

There is no territory object on the HubSpot side at all: a territory becomes a property, and the rules that used to enforce it become workflows built on top of that property, so design the property itself before writing a single workflow against it.

Visibility rules, who can actually see which record, need reconfiguring in HubSpot rather than assumed to inherit from Sell's settings.

HubSpot: Record access settings

Confirm what genuinely still needs to stay hidden before reproducing the old restrictions wholesale; a visibility rule copied out of habit is usually broader, or narrower, than what the business actually needs today.

Wherever Sell and Support are connected today, that link itself is one more thing the migration touches, not just the two products sitting either side of it.

HubSpot: Tickets in the same portal

Move Support across in the same project and this integration does not need rebuilding at all: it simply disappears, because both sides land in the same HubSpot database. That is a genuine simplification worth putting in front of whoever is weighing whether to migrate Support now or leave it for later.

Every app connected to Sell through the Zendesk Marketplace earns its own line in the migration plan, not a blanket assumption that it will simply carry over.

HubSpot: App Marketplace integrations

Inventory what is genuinely still in use before pricing out replacements, since a marketplace app connected years ago and never removed costs nothing to leave off the list.

The calendar connection, Google or Microsoft, has to be rebuilt on the HubSpot side rather than assumed to carry across with the rest of the account.

HubSpot: Calendar integration and the meetings tool

This gets done per user, not once for the whole account, so budget the time accordingly rather than treating it as a single setup task.

Whichever voice provider sits behind Sell's calling feature needs its own migration decision, since that connection does not carry across with the record data.

HubSpot: HubSpot calling or a marketplace provider

Confirm the provider actually has a HubSpot integration before signing anything, and build in the lead time for number porting: it is rarely instant, and a go-live date set without it tends to slip.

The mailbox connection responsible for logging conversations against a record needs reconnecting on the HubSpot side individually.

HubSpot: Connected inbox

This is a per-user task, and it should happen before cutover rather than after, so the logging of conversations never actually stops.

Any external automation scenario wired into Sell through Zapier or Make needs editing before it can point at HubSpot instead.

HubSpot: Updated scenarios or native workflows

Each of those scenarios needs editing on both ends, and some are genuinely better replaced with a native HubSpot workflow than simply repointed at the new address.