Migrate from Helpdesk 365 to HubSpot Service Hub

Helpdesk 365 Tickets map to HubSpot Service Hub Tickets. We map Helpdesk 365 status (Open, Pending, Resolved, Closed) to HubSpot Ticket status values, priority (Low, Medium, High, Urgent) to HubSpot Ticket priority, and assignee to a HubSpot User lookup resolved by email match. The Helpdesk 365 ticket thread (customer and agent replies) migrates as HubSpot conversation records linked to the Ticket. Any Helpdesk 365 custom fields beyond the five-field Standard cap are flagged during scoping and either stripped or moved to custom fields on the HubSpot CRM Contact record depending on the customer's HubSpot tier.

Helpdesk 365 Contact records (name, email, phone, organization link) map directly to HubSpot CRM Contact. The email address serves as the dedupe key during import. We extract the Helpdesk 365 contact's associated organization and link it to the HubSpot CRM Company record (created before Contact import). Any Helpdesk 365 contact-level custom fields migrate as HubSpot Contact properties with equivalent field types.

Helpdesk 365 Company records map to HubSpot CRM Company. The domain and company name transfer as the Company Name and Website fields. Company records are migrated before Contact records so that the Contact-to-Company lookup relationship is satisfied at the moment of Contact insert. HubSpot's native company dedupe by domain handles any duplicates from the Helpdesk 365 company population.

Helpdesk 365 Agent profiles (name, email, role, team membership) map to HubSpot Service Hub Users. We resolve agents by email match against the destination HubSpot portal's User list. Agents without a matching HubSpot User go to a reconciliation queue for the customer to provision before record import begins. Helpdesk 365 role and team data are preserved in custom fields on the HubSpot User record for the admin to use when configuring HubSpot team hierarchies post-migration.

Helpdesk 365 team configurations (agent groupings for routing and SLA assignment) map to HubSpot Teams. HubSpot Teams are configured in Settings > Users & Teams with the team's agents assigned. Because Helpdesk 365 teams are a configuration rather than a standalone data export, we extract team membership from the agent export and build a team roster that the customer's HubSpot admin creates in HubSpot before ticket import so that ticket-to-team assignments resolve correctly.

Helpdesk 365 ticket-level custom fields map to HubSpot Ticket custom properties (Professional tier and above). For customers on Helpdesk 365 Standard with five or fewer active custom fields, mapping is direct. For Standard customers with more than five custom fields, we identify the overage during scoping and either recommend upgrading to Helpdesk 365 Enterprise before migration, strip the extras, or map surplus fields to CRM Contact properties on the linked HubSpot Contact record. Custom property data types are matched (text to single-line text, number to number, date to date-time) before import.

Helpdesk 365 knowledge base articles (title, HTML body, category, publish status) do not have a confirmed dedicated export API. We evaluate the Helpdesk 365 admin Export tab for KB article availability during scoping. If a structured export is available, we transform articles into HubSpot's Knowledge Base article schema (title, body HTML, article category, publish state). If not, we recommend the HubSpot pre-built Knowledge Base importer or manual content migration for the KB layer, which we document separately as an out-of-scope item.

Helpdesk 365 ticket tags are extracted from ticket records during the ticket export and mapped to HubSpot Ticket Tags. Tags in HubSpot Service Hub are label-based and assignable across tickets for filtering and reporting. We preserve the tag string values from Helpdesk 365 as HubSpot tag names, with tag-to-category groupings migrated as HubSpot topic associations if the customer uses the HubSpot knowledge base module.

Helpdesk 365 ticket attachments are stored as SharePoint document library URLs rather than files. We extract the attachment URLs from ticket records and migrate them as-is into HubSpot Ticket conversation records as clickable links, preserving the original SharePoint URL so agents can access the file during and after migration. If the customer holds HubSpot Professional or Enterprise and wants files re-hosted in HubSpot's file manager, we upload each file via the HubSpot Files API and replace the SharePoint URL with the HubSpot file URL in the ticket conversation. This option increases migration time and cost proportionally to file volume.

Helpdesk 365 ticket conversations (customer and agent replies with timestamps and author attribution) map to HubSpot Service Hub Ticket conversations. Each reply in the Helpdesk 365 thread becomes a conversation message in HubSpot linked to the corresponding Ticket record. The author (contact or agent) resolves to the migrated HubSpot Contact or User. Internal notes in Helpdesk 365 migrate as internal HubSpot Ticket notes with the same visibility restrictions applied.

Helpdesk 365 SLA policies (response time, resolution time, business hours) are included in the base Helpdesk 365 product but are not exported as data. We document every active SLA policy during scoping, recording its name, trigger condition, time thresholds, and target team. The customer rebuilds these in HubSpot Service Hub Professional or Enterprise under Settings > Service Level Agreements. SLA rebuild is out-of-scope as a data migration activity but is included in the automation inventory document.

Helpdesk 365 rule automations (ticket routing, status updates, auto-assignment, trigger-based actions) are configuration data and are not accessible via export API. We deliver a written inventory of every active Helpdesk 365 automation rule with its trigger event, conditions, and actions during the scoping phase. The customer or a HubSpot implementation partner rebuilds these in HubSpot Service Hub Professional or Enterprise using the workflow builder. We do not migrate automations as code and do not provide post-migration workflow rebuild as standard scope.