Migrate from Jira Service Management to HubSpot Service Hub

Jira Service Management Requests map directly to HubSpot Tickets. Summary becomes ticket subject, description body migrates as ticket description, priority (Low/Medium/High/Critical) maps to HubSpot priority property, and status (Open/In Progress/Resolved/Closed) maps to the HubSpot pipeline status field. Custom fields on the JSM request are discovered via the REST API metadata endpoint and mapped to HubSpot custom ticket properties by type (string, number, date, dropdown). Jira issue key is stored in a custom property jira_issue_key__c for cross-reference.

Each JSM Service Project becomes a HubSpot ticket Pipeline. Portal settings, request type list, team permissions, and SLA definitions from the JSM project are preserved as pipeline configuration in HubSpot. Jira project key is stored in a custom property jira_project_key__c for audit. If multiple JSM projects share a single SLA policy, we create a HubSpot pipeline that references the SLA in its configuration notes.

JSM Request Types (the intake form definition per project) map to HubSpot ticket properties. We create a picklist property request_type__c with values matching the JSM request type names. Associated custom fields on the request type become HubSpot ticket custom properties. Form visibility flags from JSM (who can submit which request type) are noted in the mapping document for the admin to apply as HubSpot property visibility rules.

JSM SLA goals, starting conditions, and pause conditions are exported from the project-level SLA configuration and documented in the migration deliverable. HubSpot Service Hub Professional includes an SLA add-on with goal-based SLA policies tied to ticket properties. We map JSM SLA metric names and goal durations to HubSpot SLA policy names and first-response and next-response deadlines, and flag any JSM pause conditions that have no HubSpot equivalent (e.g., customer awaiting response on JSM versus HubSpot's response due time). If the destination HubSpot tier lacks SLA support, SLA data is preserved in a custom property for reporting purposes.

JSM Assets stored in object schemas export as CSV but critically omit issue linkages, import configurations, and cross-schema references per Atlassian documentation. We query the issue-to-asset relationship API before CSV export to capture every asset-to-request linkage, then re-apply those linkages during HubSpot import by creating HubSpot Custom Object records of type Asset and associating them with the migrated Ticket via a custom association property. Object schema attributes map to custom properties on the HubSpot Asset object. This reconciliation pass is a dedicated migration step not included in standard CSV-based migrations.

JSM agents (licensed resolvers) map to HubSpot Users with the agent role. We resolve by email match against the HubSpot destination User table. Jira service desk agents without a matching HubSpot User are placed in a reconciliation queue for the customer's admin to provision before record import. Agent group memberships from JSM are mapped to HubSpot team structures.

JSM customer portal users map to HubSpot Contacts. We explicitly set the customer_type field on every imported user to customer to prevent HubSpot from assigning agent licensing to portal-only users. Jira users who appear only as requesters (not agents) in the source become Contacts, not Users. Email address is the dedupe key during import.

JSM request comments and internal notes migrate as HubSpot ticket conversations. Author, timestamp, and body text transfer. Public versus internal visibility from JSM maps to HubSpot conversation visibility flags. Attachments embedded in comments are handled as part of the attachment migration pass and re-linked to the conversation record on HubSpot.

File attachments on JSM requests and comments are downloaded from Atlassian's CDN and re-uploaded to HubSpot. Large attachment batches are chunked to avoid timeout. We preserve original filenames and re-associate attachments with the migrated ticket or contact record. If the attachment count exceeds 10 GB total volume, the migration plan includes a dedicated attachment transfer window with delta verification.

JSM Knowledge Base articles live in Confluence spaces linked to the service project. We export articles from the linked Confluence instance and import them as HubSpot Knowledge Base articles. Space permissions, internal links within Confluence, and article-to-request-type associations are documented in the migration deliverable for manual recreation in HubSpot's Knowledge Base builder. Confluence article body HTML is converted to HubSpot's article format.

JSM's full change history — field changes, status transitions, assignee updates — exports via the issue changelog API and is re-imported to HubSpot as activity timeline entries. Each change is stored as a timestamped note on the ticket with the field changed, old value, and new value. Jira issue key is preserved on the ticket for cross-referencing.

JSM automation rules are exported as JSON but rule actors, audit logs, and performance insights are excluded per Atlassian's documented migration scope. We deliver a written inventory of every active JSM automation with its trigger conditions, action blocks, and Jira user references, mapped to equivalent HubSpot Workflow trigger-action pairs. The customer's admin rebuilds the automation logic in HubSpot's workflow builder. We do not migrate automation rules as executable code.

JSM labels and tags on requests migrate as HubSpot ticket tags. Tag names are preserved as-is. New tags encountered during migration are created on the destination pipeline before the ticket import phase.