Migrate from Desk365 to HubSpot Service Hub

Desk365 Tickets map directly to HubSpot Service Hub Tickets. The source Status (Open, Pending, Resolved, Closed), Priority (Low, Medium, High, Urgent), and Created/Updated timestamps preserve. Assignee resolves via email match to HubSpot User; Requester resolves to a HubSpot Contact. We migrate both open and closed historical tickets in date order. If the customer specifies a cutover date, tickets created after that date remain in Desk365 for delta migration.

Desk365 Customer records (name, email, company association, portal access status) map 1:1 to HubSpot Contact. The source Customer type (End User vs. External) influences the Contact's HubSpot lifecycle stage default. Any Desk365 Customer without an email address is flagged for the customer's admin to review because HubSpot requires an email for Contact creation.

Desk365 Agent records (display name, email, department membership, Admin/Agent role) map to HubSpot Users. Active/inactive status preserves as HubSpot User active flag. We match Agents by email to resolve HubSpot User IDs for ticket assignment. Agents without a matching HubSpot User land in a reconciliation queue for the admin to provision before ticket migration proceeds.

Desk365 Departments with access-level controls (global, department-only, agent-only) map to HubSpot Teams. Multi-level department hierarchies flatten into HubSpot Teams with naming conventions that preserve the hierarchy path. Department-level email routing addresses require the customer to configure HubSpot Inboxes post-migration; routing rules are documented for the admin to rebuild.

Articles migrate with publish status and content preserved. Desk365's Agent-only visibility flag has no direct HubSpot equivalent — Agent-only articles land as Draft in HubSpot and require a manual review before publishing. Folder structures in Desk365 map to HubSpot knowledge base categories. Inline images extract and re-upload to HubSpot's file hosting.

Desk365 SLA Policies with First Response and Resolution time targets by Priority level and Business Hours schedule map to HubSpot SLA Policies. We extract the policy name, time thresholds, business hours definition, and priority associations, then recreate them in HubSpot's SLA configuration UI. Desk365's Priority-to-SLA mapping matrix becomes the HubSpot SLA policy conditions.

Desk365 macros trigger on Ticket create/update events with conditions (field values, customer events) and fire actions (reply templates, field updates, assignments). We export macro definitions as structured JSON including trigger logic, conditions, and action sequences. Macros do not execute in HubSpot — they document for the customer's admin to rebuild as HubSpot Workflows and macros post-migration.

Desk365 flat string tags on Tickets migrate to HubSpot Ticket Tags. No hierarchical or color metadata carries over since neither platform stores that on the tag itself. Tags are re-applied during ticket import using HubSpot's tag association API.

Each Desk365 Ticket's Conversation records (public replies, internal notes, system-generated status changes) migrate in chronological order. Public replies land as HubSpot Ticket Replies; internal notes land as HubSpot Ticket Internal Notes. The original author resolves to the matching HubSpot User or Contact. System-generated status-change entries from Desk365 are skipped as HubSpot generates its own status log.

File attachments on Desk365 Tickets and inline in conversations are stored at URLs pointing to Desk365 blob storage. We download each attachment and re-upload to HubSpot's file manager, then attach to the corresponding HubSpot Ticket record. Attachments without a valid source URL are flagged for manual re-upload by the customer.

Desk365 custom fields (text, number, dropdown, date, boolean) on Tickets extract with their definitions and values. We map field types to HubSpot ticket property types during scoping. If the destination HubSpot portal already has custom properties with matching names and types, values map directly. New custom properties are created in HubSpot before ticket import. Any Desk365 custom field with no HubSpot equivalent goes to a field reconciliation list for the customer to decide on type and placement.

Desk365 Premium IT Asset Management records (hardware/software assets linked to Tickets) extract as a separate dataset. Assets and their Ticket associations migrate to a HubSpot Custom Object with a lookup relationship back to the parent Ticket. Asset-to-asset relationships and dependency trees are documented as a separate data map for the customer to rebuild in HubSpot's Custom Object schema or a dedicated ITSM tool if asset dependency tracking is a compliance requirement.