Migrate from Freshservice to HubSpot Service Hub

Freshservice Tickets migrate to HubSpot Tickets via the HubSpot Tickets API. Subject, description, status, priority, type, group, and agent assignments map directly. Custom ticket fields migrate as HubSpot custom ticket properties. Freshservice's requester_id maps to HubSpot's contact_id through a pre-resolved contact lookup table. Ticket attachments migrate as HubSpot file attachments linked to the ticket.

Freshservice Agents (licensed users) map to HubSpot Users. We resolve by email address as the dedupe and match key. Role, group membership, and skill assignments are documented for rebuild in HubSpot's User roles and team structure. If a Freshservice Agent has no HubSpot User counterpart, they go to a provisioning queue for the admin to address before the user migration phase begins.

Freshservice Requesters (end users who submit tickets) map to HubSpot Contacts. We preserve first name, last name, email, phone, organization, and location. Freshservice's organization_id maps to HubSpot's company_id through a pre-built company lookup table. Requesters are free in Freshservice licensing but are counted as contacts in HubSpot's CRM.

Freshservice Assets (hardware, software, network items in the CMDB) map to a HubSpot Custom Object named IT Asset. All standard Freshservice asset fields (name, type, state, serial number, vendor, purchase date, cost) migrate as Custom Object properties. We pre-create the Custom Object schema in HubSpot before migration. Asset-to-Ticket associations are stored as a text property containing the related HubSpot ticket ID rather than a native association, because HubSpot does not support bi-directional lookups from Custom Objects to standard Tickets by default.

Freshservice Changes have no native HubSpot equivalent. We map Changes to a HubSpot Custom Object (Change Request) with fields for change type, risk level, impact, approvers, planned start/end dates, and associated CI. The approval workflow logic is documented for rebuild in HubSpot's Workflows (Automation) or a separate approval tool post-migration. This is a documented gap, not a code migration.

Freshservice Problems (root-cause tracking behind incidents) map to a HubSpot Custom Object (Problem Record). Problem description, status, priority, and linked incident ticket IDs migrate as custom properties. The Problem-to-Incident relationship is stored as a text field with comma-separated ticket IDs, as HubSpot does not support native many-to-many ticket linking. The customer's admin rebuilds this relationship logic in HubSpot's Workflows or a custom app post-migration.

Freshservice Releases group Changes and Assets into deployable units with scheduled dates and approval workflows. We map Releases to a HubSpot Custom Object (Release Record) with fields for planned date, status, associated Change Request IDs (text), and associated IT Asset IDs (text). The release approval workflow is documented for rebuild. Release-to-Change associations are preserved as text lookups rather than native relationships.

Freshservice Service Catalog items with multi-step request forms and approval chains have no direct HubSpot equivalent. We document the full catalog item structure (form fields, approval rules, associated SLA policy) in a written catalog. The customer's admin rebuilds this as HubSpot Forms with Workflow approval chains. Request items submitted before migration are migrated as Tickets with the original catalog item name stored as a custom property.

Freshservice SLA Policies define response and resolution time targets tied to ticket priority or type. We document SLA Policy assignments per ticket and deliver a written inventory mapping each Freshservice SLA Policy to a HubSpot SLA configuration for the admin to rebuild. SLA enforcement logic (automatic escalation, reminder actions) is not migrated as code; we describe the Freshservice SLA rules in detail for HubSpot recreation.

Freshservice Solutions (knowledge base articles) migrate to HubSpot Knowledge Base articles. Article title, body content, categories, and status migrate. Article-to-ticket associations are stored as a custom property on the HubSpot article containing the related ticket IDs. Published status maps directly; draft articles migrate as drafts for review before publishing.

Freshservice CSAT and CES surveys attached to tickets migrate to HubSpot Customer Feedback Surveys. Survey responses link to the migrated ticket via a custom property storing the original Freshservice ticket ID. Survey configuration (question text, response scale) migrates as HubSpot survey properties.

Freshservice Locations migrate as HubSpot Locations, used for routing and organizational context. Location-to-ticket assignments migrate as a custom ticket property rather than a native HubSpot association.

Freshservice Departments map to HubSpot Teams. We use department names as team names during migration. Agent-group assignments that used Freshservice department scoping are documented for rebuild in HubSpot's team-based routing configuration.

Freshservice Custom Object records (Forest and Enterprise plans) migrate to HubSpot Custom Objects of matching name. We pre-create the destination schema in HubSpot (including all custom properties and lookup fields to other Custom Objects). Note that Freshservice does not support Custom Object-to-native object associations; if the Freshservice custom object references a ticket or asset, we store the related record ID as a text field. HubSpot's lookup fields from Custom Objects to standard objects are supported on Professional and Enterprise.