Migrate your Jira Service Management data

Requests are JSM's primary ticket object. We perform a direct field-to-field mapping of standard request attributes (summary, description, priority, status, created/updated timestamps) and handle status mapping between source workflow states and JSM's request statuses.

Service projects encapsulate a request type list, associated workflows, SLA definitions, and team permissions. We recreate the project configuration, including portal settings and default request types, on the destination instance.

Request types define the intake form shown to customers. We transfer the request type schema including associated fields, issue subtypes, and portal visibility flags. Custom fields on request types are handled via the customFields API endpoint.

JSM custom fields can be project-specific or global, and their schema varies by Jira instance. We discover all custom fields via the REST API metadata endpoint, map them to destination field equivalents, and create missing fields before import. Fields without a destination counterpart are flagged for manual field creation.

SLA goals, starting conditions, and pause conditions are stored per project. We preserve SLA definitions in Standard tier and above. When migrating to a destination that does not support JSM-style SLAs, we convert goals to deadline date fields or custom fields and note the conversion in the migration report.

Automation rules are exported as JSON but rule actors, audit logs, and performance insights are excluded from migration per Atlassian's documented migration scope. We transfer the rule logic and re-link Jira user references to match the destination instance's user base. Global automation configurations require manual recreation.

Articles live in Confluence spaces linked to a JSM project. We migrate articles to the destination Confluence instance and re-associate them with the migrated service project. Space permissions must be manually reviewed post-migration.

Assets uses object schemas and object types with attributes and references. We export Assets data via CSV from the source schema and import via the Assets object schema import. Critically, the CSV export does not include ticket linkage references or import configurations—we reconstruct those associations during the import job.

The customer portal configuration includes branding settings, allowed domains, and portal permissions per project. We transfer portal settings and note that portal branding may require re-application if destination is a different Atlassian organization.

JSM distinguishes agents (licensed, can resolve tickets) from customers (portal-only, uncharged). We map source users to destination users by email. Agent role assignment is preserved, but Atlassian account provisioning on the destination must be completed before the migration import job runs.

Request comments and internal notes transfer via the issue comments API. We preserve the author, timestamp, and body text. Attachments embedded in comments are handled as part of the attachment migration pass.

File attachments on requests and comments are downloaded from Atlassian's CDN and re-uploaded to the destination. Large attachment batches are chunked to avoid timeout. We preserve original filenames and content-type headers.

Labels and tags on requests are migrated as-is. We map source tag names to destination tag names and create missing tags on the destination project during the import phase.

Links between requests (blocks, relates to, duplicate) transfer via the issue links API. We validate that linked issues exist in the destination and flag any broken links where the target record was not included in the migration scope.

The full change history—field changes, status transitions, assignee updates—is exported via the issue changelog API and re-imported to preserve audit trail on the destination.