Migrate from Jira Service Management to Zendesk

JSM Requests map directly to Zendesk Tickets. The JSM Request summary becomes the Ticket subject, description migrates as the Ticket comment body, priority maps to Zendesk priority (urgent/high/normal/low), and status (Open, In Progress, Pending, Resolved, Closed) maps to Zendesk ticket status. Request key (e.g., JSM-1234) is stored in a custom Zendesk field for traceability. Custom fields on the JSM Request Type are discovered via the metadata API, typed, and created as Zendesk custom fields before import.

JSM Service Projects encapsulate Request Type lists, team permissions, portal settings, and SLA definitions. We split each Service Project into a Zendesk Group (for agent routing and permissions) and one or more Views that filter Tickets by the relevant Request Type tags we apply during import. Portal branding and allowed-domain settings from the JSM project are documented in the rebuild handoff for the customer's Zendesk admin to reconfigure in Guide settings.

JSM Request Types define the intake form shown to customers. Zendesk has no direct Request Type equivalent; instead we apply a tag per Request Type (e.g., tag: hardware-request, password-reset) during import and create Views that filter by those tags to replicate the Request Type routing logic. If the customer needs mandatory fields per Request Type, we recommend Zendesk's Ticket Forms (available from Suite Growth) as the equivalent.

JSM SLA goals, starting conditions, and pause conditions (available in Premium and Enterprise) map to Zendesk SLA Policies (Suite Team and above includes limited SLA; Suite Growth and above includes full SLA goals with business hours configuration). We translate JSM's Calendar-based start conditions and pause conditions to Zendesk's first_reply_time and next_reply_time metric definitions, preserving the original goal hours in a custom field for audit. If the source JSM is Standard tier with no SLA data, this mapping step is skipped.

JSM public comments and internal notes both migrate to Zendesk ticket comments. Internal notes in JSM are flagged with a public: false attribute; we set the Zendesk comment visibility to internal by placing it in the comments array with author_id pointing to the agent. Public comments migrate as public Zendesk comments. The original author, timestamp, and body text are preserved. Attachments embedded in comments are handled in the attachment pass after the parent ticket is created.

File attachments on Requests and comments are downloaded from Atlassian's CDN and re-uploaded to Zendesk via the Zendesk Attachments API. Large attachment batches (exceeding 20 MB or 100 attachments per batch) are chunked to avoid timeout. Original filenames are preserved. If an attachment was attached to an internal note in JSM, it is re-attached to an internal comment on the Zendesk ticket to maintain visibility semantics.

JSM agents (licensed resolvers) map to Zendesk agents. JSM customer portal users map to Zendesk end-users. We match by email address and set the user_type field explicitly to prevent portal-only users from landing as billable agents. JSM users without email are assigned a generated placeholder email and flagged in the reconciliation report for the customer's admin to link to a real account post-migration. Role and group membership from JSM project permissions translate to Zendesk Agent permissions and Group membership.

JSM labels on Requests migrate as Zendesk tags. Tag names are normalized to Zendesk's lowercase-with-hyphens format during transform. Tags used for Request Type identification are preserved as-is; all other tags migrate directly. Zendesk tag limits (max 200 tags per ticket) are enforced during import, and any tags exceeding the limit are logged for the customer's admin to consolidate post-migration.

JSM issue links (blocks, relates to, duplicate) reference other Jira issues. Within a Zendesk-only destination there is no native Jira-style issue link. We store the linked JSM issue key in a custom text field on the ticket and add a public comment referencing the linked item, preserving the relationship for cases where both systems will coexist temporarily or permanently. If the customer has migrated to Zendesk exclusively, linked items without a Zendesk equivalent are flagged as reference-only records.

JSM's full change history including field changes, status transitions, and assignee updates is exported via the issue changelog API and written as internal Zendesk comments with a standardized audit format (field: old value > new value, timestamp, actor). This preserves the audit trail for compliance and for teams that rely on the full history for SLA breach investigation.

JSM Assets object schema data (objects, object types, attributes, lifecycle statuses, ownership, and location) has no direct Zendesk equivalent. Zendesk does not include a native CMDB. We export Assets data from JSM via CSV, reconstruct the issue-to-asset linkage using JSM's relationship API (because the CSV export excludes ticket linkage), and migrate asset data as Organization-level custom fields or as a separate Zendesk custom object (using a data import with a custom record type). Asset ownership maps to Zendesk Organization assignments. The customer should evaluate Zendesk Explore or a third-party asset management integration if CMDB functionality is required post-migration.

JSM Knowledge Base articles live in Confluence spaces linked to a service project. We export articles from the linked Confluence space via the Confluence REST API, transform Confluence storage format (XHTML) to Zendesk Guide HTML, and import into Zendesk Guide sections. Space permissions from Confluence do not transfer; the customer re-applies article permissions in Zendesk Guide post-migration. Article attachments migrate as Zendesk article file attachments. If the source JSM has no linked Confluence space, this step is skipped and documented in the handoff as a Guide rebuild requirement.