Migrate from DeskDay to HubSpot Service Hub

DeskDay Tickets migrate to HubSpot Tickets as the primary object. We translate DeskDay's conversational thread model (inline messages per ticket) into HubSpot's Ticket object with threaded replies using the Conversations API. Ticket status (open, pending, resolved, closed), priority (low, medium, high, urgent), and the original DeskDay created_date and updated_date timestamps are preserved. Custom ticket fields migrate as HubSpot custom properties (text, number, date, or dropdown depending on content). DeskDay tags migrate to the Ticket hs_ticket_tags property as a multi-select label set.

DeskDay's MSP Client Organizations map directly to HubSpot Companies. The organization name, domain, service tier, SLA mapping, and any custom organization-level fields migrate to HubSpot Company properties. We use the domain as the Company dedupe key during import. Company is imported before any Contact or Ticket that references it so that the CompanyId lookup is satisfied at insert time.

DeskDay End-User Contacts migrate to HubSpot Contacts. Each Contact is linked to the corresponding HubSpot Company (from the MSP Client Organization mapping) via the company_id association. Full name, email, phone, and any custom contact fields migrate to HubSpot Contact properties. We resolve the CompanyId lookup before Contact insert so that the association is established at migration time rather than patched afterward.

DeskDay Agent records migrate to HubSpot User records by email match. Agent name, email, role (admin, technician), and team assignment migrate as HubSpot User properties. Any DeskDay Agent without a matching HubSpot User in the destination account goes to a reconciliation queue for the customer's admin to provision before record import resumes. Team assignments are resolved through the Teams mapping step before agent-ticket associations are created.

DeskDay Teams map to HubSpot Teams (available on Professional tier and above). Team name and any routing rules or SLA targets associated with the team migrate as Team properties. We create HubSpot Teams during schema setup before Agent migration so that User.team_id resolves correctly at import time.

DeskDay custom ticket fields require schema analysis before migration. We extract the field name, data type, and picklist values (if applicable) from DeskDay, then create equivalent HubSpot custom properties of the matching type (text, long-text, number, date, or single-select dropdown). Multi-select checkbox fields in DeskDay map to HubSpot multi-checkbox properties. Any DeskDay custom field with a type we cannot determine from the source API maps to a text property with a note to the admin to reclassify post-migration.

DeskDay SLA configurations (business hours definitions, escalation targets, and SLApolicy associations on tickets) migrate to HubSpot SLA Policies. DeskDay business hours definitions map to HubSpot Business Hours records. SLA targets tied to DeskDay custom date fields require field remapping to the equivalent HubSpot custom property created during the custom field step. SLA enforcement is configured in HubSpot Service Hub settings after migration; we provide the SLA policy definition as a written configuration guide.

DeskDay Knowledge Base articles and their category assignments migrate to HubSpot Knowledge Base articles. Article content, title, and category hierarchy transfer directly. Article view counts, feedback ratings, and internal publication status from DeskDay do not migrate because HubSpot does not store these as standard article metadata; we flag these as requiring post-migration verification. Articles are imported after Companies and Contacts but before Tickets to ensure knowledge base references resolve correctly.

DeskDay's IT-Connect portal associations (which client organizations and end users have portal access, and any ticket visibility rules) map to HubSpot's customer portal settings and Help Center visibility. Portal theming and white-label settings are plan-gated in DeskDay (Standard vs Enterprise) and do not migrate; we flag which MSP clients were using custom portal branding so the admin can configure equivalent HubSpot customer portal theming post-migration. Ticket submission settings, knowledge base access permissions, and notification preferences migrate as configuration records.

DeskDay tags applied to tickets migrate as flat label arrays on the HubSpot Ticket's hs_ticket_tags property. We preserve all tag names verbatim. If DeskDay tags include ticket-type classifications (incident, request, problem) that should become HubSpot Ticket pipelines or categories, we flag this during scoping so the customer can decide between tag preservation and pipeline-level categorization.

DeskDay stores ticket file attachments using internal cloud URLs that are not portable between platforms. We download all ticket attachments from DeskDay, re-upload them to HubSpot's CRM file storage, and update each Ticket record with the new HubSpot file reference and URL. This batch download-reupload process adds processing time proportional to total attachment volume. Attachments larger than HubSpot's file size limits are flagged for admin review. We recommend running this step during a scheduled maintenance window because ticket-write operations are locked during active attachment reprocessing.

DeskDay Reports and Dashboards are generated at query time from ticket and agent activity logs rather than stored as independent report records. Because these are not persistent data objects, they cannot be exported and re-imported into HubSpot. We deliver a written inventory of every named DeskDay report with its data sources, filters, and date ranges so the customer's admin can recreate equivalent reports in HubSpot's reporting module. Ticket history migrated via the Ticket object provides the underlying data for these recreations.