Migrate from Jira Service Management to Intercom

JSM Requests map to Intercom Conversations. The Request summary becomes the Conversation subject, description becomes the initial message body, and status (Open, Pending, Resolved, Closed) maps to Intercom's open, closed, or snoozed states. We preserve the original created_at and updated_at timestamps from Jira. Request priority (Low, Medium, High, Critical) migrates as a custom conversation attribute. Linked SLA status migrates as a custom attribute if the destination Intercom plan includes SLA tooling.

JSM customers (portal users who submit requests) map to Intercom Contacts by email. The customer's display name, email, and any Jira user properties (department, organization) migrate as Contact attributes. JSM agents who are also customers (dual-role) are set as Intercom Users first, then added as Contacts if their contact identity is needed for customer-initiated conversations.

JSM agents (licensed resolvers) map to Intercom Users. We resolve by email match and assign to the corresponding Intercom Inbox. Agent role hierarchy (Admin, Agent, Requester-only) maps to Intercom's admin, agent, and viewer roles. The agent's Jira group membership is preserved as an attribute for inbox routing configuration post-migration.

JSM comments on requests map to Intercom Conversation parts. Public comments become Intercom user messages; internal notes become Intercom internal notes. Author attribution migrates by resolving the Jira user email to an Intercom User or Contact. Timestamps are preserved to maintain conversation sequence. Attachments within comments migrate as part of the attachment batch.

File attachments on JSM requests and comments are downloaded from Atlassian's CDN and re-uploaded to the corresponding Intercom Conversation part. Large attachment batches (over 500 files or 10 GB total) are chunked and processed in parallel to avoid timeout. We preserve original filenames and detect file type from MIME headers.

Each JSM Service Project maps to an Intercom Inbox. The project's portal settings, request type list, and team permissions map to the Inbox's routing rules and team membership. Multi-project JSM instances create multiple Intercom Inboxes, which the Intercom admin consolidates or routes between post-migration. The Inbox name and visibility settings are configured before conversation import begins.

JSM Request Types define the intake form shown to customers. Intercom has no direct equivalent object type, so we map Request Type to a Conversation tag (for routing and reporting) and optionally to a custom Contact attribute (for segmentation). The customer chooses the tag strategy during scoping. Form field mappings that depend on Request Type-specific custom fields are documented as a configuration step.

JSM SLA goals, starting conditions, and pause conditions are written to a structured JSON inventory document. If the destination Intercom plan includes SLA tooling, we configure inbox-level SLA targets matching the JSM definition. SLA breach timestamps from JSM history migrate as conversation attributes (slab_first_response, sla_resolution) rather than as native SLA records, because Intercom's SLA product applies forward-looking targets, not historical breach records.

Confluence articles linked to a JSM project migrate to Intercom Articles. Article title, body (migrated as rich text with image references re-pointed to Intercom's CDN), and publication status transfer. Section and collection hierarchy in Confluence maps to Intercom Collections and Sections. Space permissions from Confluence cannot transfer; articles inherit the Intercom workspace visibility settings post-migration.

JSM custom fields on Requests (project-specific or global) map to Intercom Custom Attributes on Conversation or Contact. Field type mapping: JSM text fields map to String attributes, date fields to Date attributes, number fields to Number attributes, dropdown fields to String attributes with documented value sets. Custom fields that reference JSM Assets or linked Issues are flagged for a separate attribute mapping pass because Intercom has no native asset linking.

JSM automation rules (triggers, conditions, and actions) are exported as a structured JSON inventory. We do not migrate automation logic as Intercom Workflow Builder code because the trigger and action models differ. The inventory documents each rule's Jira trigger type, conditions, and Jira-specific actions (transition issue, send email, create sub-task) with recommended Intercom Workflow equivalents. The Intercom admin or implementation partner rebuilds rules post-migration.

The JSM issue change log (status transitions, assignee changes, field updates) migrates as Intercom conversation parts with a system event attribution. The Jira user performing the action maps to an Intercom User by email. Change log entries that reference Jira-specific fields (Sprint, Fix Version, Component) that have no Intercom equivalent are flagged as skipped with a count in the migration report.