Freshdesk to HubSpot Migration

Whatever assigns and categorises a ticket the instant it lands has no path across the connector and needs writing again from nothing.

HubSpot: Workflows and routing rules

Expect to redo this rule by rule rather than as a single block, and to restructure any chain of dependent rules while doing it: Freshdesk evaluates dispatch rules in a defined order, HubSpot's workflow engine does not, so a rule that assumed an earlier one had already run needs a different design, not just a copy.

Anything that fires off a ticket event, or after a ticket has simply gone quiet for a stretch of time, needs the same ground-up rebuild.

HubSpot: Ticket-based workflows with delays

Test the delay behaviour against real tickets before trusting it with anything that auto-closes a case: a working week that runs Sunday to Thursday in one market and differently in another is exactly where a timing assumption quietly breaks.

The one-click bundle of actions an agent applies to a ticket, several field changes and a reply fired together, has no equivalent waiting to receive it either.

HubSpot: Workflows, triggered manually or by a property

HubSpot has no single-click bundle to receive it: each one becomes a workflow the agent triggers manually or by setting a property, a genuine rebuild rather than a renamed setting.

Response and resolution targets set per ticket type or per account do not transfer with anything else: SLA policies need configuring again from nothing, matching whatever commitment is actually written into the contract rather than reproduced from memory.

HubSpot: SLA settings and ticket workflows

Configure business hours before a single SLA policy goes live, or every target measures against a flat 24-hour clock regardless of when the desk is actually open. That step carries more weight for a Gulf operation running one help desk across several markets on different working weeks, since a day that is a weekend in one country is a working day in another, and the SLA clock needs to know which is which.

A macro, the saved reply text bundled with whatever field changes went alongside it, does not travel across as a single thing.

HubSpot: Snippets, templates and workflows

It has to be split apart to rebuild: the reply text becomes a snippet, and the field changes it used to trigger become a separate workflow, two HubSpot objects standing in for the one Freshdesk macro.

Freddy's suggested replies and automated triage do not carry across in any form at all.

HubSpot: HubSpot's own AI tooling

There is genuinely no migration path: those models were trained on the ticket history sitting inside Freshdesk and stay there when the account closes. Treat whatever HubSpot's own AI tooling offers as a fresh configuration starting from nothing, and set the team's expectations accordingly, since suggestion quality on day one will read as noticeably worse than what Freddy had learned over years of the same queue.

Who gets told what, and the point at which a ticket escalates to someone else, both need reconstructing from scratch.

HubSpot: Notification settings and workflows

HubSpot splits this logic across two separate places, notification settings and workflows, which makes it easy to rebuild only half of it without noticing. Check both before calling the job finished.

The whole Freshdesk Analytics suite built on top of the ticket data has no import path and needs rebuilding report by report.

HubSpot: Custom reports

Rebuild each report starting from the question it was actually answering rather than its layout, and expect some metrics to have no HubSpot counterpart at all. Say so early in the scoping conversation: a gap like that is a much smaller problem raised before sign-off than one discovered at handover.

Whatever dashboard layouts were saved for recurring reporting need building again from nothing.

HubSpot: Dashboards

Build the dashboards only once the underlying reports already exist in HubSpot, not alongside them: a dashboard assembled before its reports are finished usually needs redoing.

Reporting on which SLA targets were met and which were missed has to be rebuilt on the new side as well.

HubSpot: SLA reporting

This depends entirely on the SLA configuration described above, so sequence the reporting build after that work is finished, not in parallel with it.

Reporting on how much each agent handled, and how quickly they resolved it, needs setting up again in HubSpot's own tools.

HubSpot: Service analytics

Every agent has to map to a real HubSpot user at import time, or the activity they handled attributes to nobody once the metrics are rebuilt, a gap that is far cheaper to close before go-live than to reconstruct afterwards from ticket history alone.

Historical CSAT results and the trend built from them do not carry across as a single continuous dataset.

HubSpot: Customer feedback surveys

New surveys go out from HubSpot from day one, while the historical scores sit parked in a custom property, so any trend report has to draw from two separate sources for the better part of the first year rather than one clean line.

Every form customers actually use to raise a ticket has to be rebuilt as a HubSpot form.

HubSpot: Forms

Swap every embedded form on cutover day itself, not sometime after: leave even one page pointing at the old form and support requests keep arriving in a system nobody is watching.

The on-site chat widget customers actually see needs replacing, not just reconfiguring.

HubSpot: Live chat

Swapping the widget itself is the easy part; the real work is rebuilding the routing and availability rules behind it, the logic deciding who picks up a chat and when, especially where the desk operates across more than one working week.

Whatever automated chat flow was handling the common questions has to be rebuilt flow by flow inside HubSpot's own chatbot builder.

HubSpot: The chatbot builder

None of the bot's performance history carries across with it, so the new one starts from a blank slate: whatever tuning the old flow earned over months of real conversations has to be earned again rather than inherited.

The help articles already published in Freshdesk have an actual import path, unlike most of what sits on this list.

HubSpot: Knowledge base

HubSpot's own knowledge base importer reads Freshdesk directly, which makes this one of the cheaper items to move on the whole list. It runs in batches, and any table formatting inside an article does not survive the import, so budget a formatting pass afterwards, worth doing with care for any article that exists in both an Arabic and an English version, since a broken table reads as unfinished in either language.

The public-facing help site and the logged-in customer portal behind it are a separate build from the article import above, not a byproduct of it.

HubSpot: Knowledge base and customer portal

Permissions and branding are their own piece of work here, worth planning as such: an Arabic-language portal rendering correctly right to left is a design decision, not something the article import settles on its own.

Every standard reply template agents use gets rebuilt from nothing, not carried across with its formatting intact.

HubSpot: Email templates and snippets

It is manual, template by template, and the personalisation tokens inside each one have different names on the HubSpot side and will not carry across automatically, so every merge field needs re-checking rather than trusted on sight.

The survey that goes out automatically once a ticket closes needs rebuilding as its own piece of configuration.

HubSpot: Customer feedback surveys

Rebuild the trigger alongside the survey itself, not just the questions: the send is driven by a workflow in HubSpot rather than a simple ticket setting, so getting the trigger wrong means the survey either never goes out or goes out at the wrong moment.

Whatever access level was attached to each agent in Freshdesk needs recreating deliberately in HubSpot's own permission model, not assumed to carry across.

HubSpot: Users and permission sets

Freshdesk's occasional-agent arrangement, a lighter seat for someone who only touches tickets now and then, has no exact counterpart on the other side. Decide person by person whether they genuinely need a full seat before the licence count goes into the budget, since guessing in either direction gets expensive.

The way agents were grouped for routing purposes needs its own equivalent built in HubSpot.

HubSpot: Teams

Map the intent behind the old grouping rather than copying its structure exactly: a group that grew up around one person's habits rarely deserves to be reproduced as-is.

The operating hours and holiday calendar that drove the SLA clocks in Freshdesk both need setting up again from scratch.

HubSpot: Business hours settings

Get this configured before a single SLA is built, not after: for a desk covering more than one Gulf market with a different working week in each, business hours are the setting that decides whether the SLA clock means anything at all.

Each agent's own email signature on a ticket reply needs setting up individually in HubSpot as well.

HubSpot: User email signatures

It is configured per user rather than once centrally, so it is a short task repeated across the whole team, worth scheduling as a checklist item rather than assumed to happen by itself during onboarding.

Whatever app was extending the Freshdesk agent view has to be reconnected or replaced on the HubSpot side; none of the configuration carries over on its own.

HubSpot: App Marketplace integrations, or Zapier and Make

Inventory what is genuinely in daily use before pricing out the replacements: an app installed years ago and quietly abandoned does not need a HubSpot equivalent found for it.

Where Freshdesk sits alongside Freshsales, Freshchat or Freshcaller inside the same Freshworks account, those are not separate integrations to reconnect; they are neighbouring products the whole estate was built around.

HubSpot: The equivalent HubSpot hubs and tools

These read as integrations but function as neighbouring products built on the same platform. Where your organisation runs several of them together, this project is wider than the help desk alone, and it should be scoped as the whole Freshworks estate moving, not just one corner of it.

Every channel feeding the queue, email, phone and the social and messaging channels alongside them, needs reconnecting individually on the HubSpot side rather than assumed to follow the ticket data across on its own. Where WhatsApp is genuinely the channel customers reach for first in this market, give it the same reconnection care as email rather than treating it as an afterthought.

HubSpot: Connected channels

Check each one still actually creates a ticket after reconnection rather than merely sending a notification: that silent downgrade from ticket-creating to notify-only is a common regression, and the kind of gap that surfaces only once someone complains that nobody answered.