How to Export Data from Jira Service Management (JSM)

How to Export Data from Jira Service Management (JSM)

Jira Service Management gives you five practical ways to get data out: CSV/Excel export from the issue navigator (up to 10,000 issues), Backup Manager for full-site snapshots, the Jira Platform REST API for programmatic extraction, the JSM-specific REST API for service desk entities like organizations and queues, and the Assets export for CMDB object schemas. Each method has hard limits on volume, frequency, and what data it actually includes. This guide covers every method, the real constraints you'll hit, and the trade-offs that determine which approach fits your use case.

Scope note: This article covers Jira Service Management Cloud. Several behaviors — including Backup Manager exclusions, rate limit structure, and Assets export — differ materially from JSM Data Center. Where Cloud-specific behavior is not obvious, it is called out explicitly.

The five JSM data export methods compared

How to export JSM issues to CSV or Excel

CSV export from the issue navigator is the fastest way to pull JSM ticket data for reporting or analysis. As of March 19, 2025, Atlassian increased the export limit from 1,000 to 10,000 issues per export.

Here's the process:

1. Navigate to the issue navigator and enter a JQL query scoped to your service project (e.g., project = "IT Support" AND created >= "2025-01-01").
2. Click the Export dropdown and choose Export CSV (All fields) or Export CSV (Current fields).
3. The file downloads directly to your browser.

What the CSV export misses

When using export options like Open in Excel, Open in Google Sheets, or Export to Word, Assets custom fields will be empty. The Export to CSV feature is the exception — it does include Assets field data.

Rich text and description fields: Issue descriptions in Jira Cloud are stored in Atlassian Document Format (ADF), not plain text. In the CSV export, descriptions are typically exported as stripped plain text — formatting, embedded images, panels, and macros are lost. In the REST API, the description field returns raw ADF JSON, which requires additional parsing to produce human-readable output. This is one of the most common operational surprises when building export pipelines.

Comment threading and internal comments: The CSV export does not include comments. Internal comments (visible only to agents, not customers) are also not flagged distinctly in the CSV — they require the API.

The 10,000-issue limit is a hard cap. If your JQL query returns more results, the export silently truncates. Split large exports into batches using date ranges or other JQL criteria.

This export limit increase applies specifically to the CSV/Excel export from the issue navigator UI and does not affect the REST API. Pagination and limits for API-based exports remain unchanged.

How do you export more than 10,000 JSM issues?

In Jira Cloud, exporting up to 10,000 work items using the asynchronous Export CSV feature from the Issue Navigator is supported. Beyond 10,000, you have two options:

• JQL batching from the UI: Use date ranges to split results into chunks under 10,000. For example, project = SD AND created >= "2025-01-01" AND created < "2025-04-01", then repeat for the next quarter.
• REST API pagination: Script paginated calls using startAt and maxResults parameters. The startAt and maxResults parameters should be used to paginate the results, looping until the total number of records is reached. The total number of records is provided in the first response.

Exporting JSM data via the REST API

The Jira Platform REST API is the most flexible extraction method for JSM data. Jira Service Management is built upon the Jira platform, so you have access to the full suite of Jira platform REST APIs. This means you can use the standard /rest/api/3/search endpoint with JQL to pull all issue data, including custom fields, comments, worklogs, and changelogs.

OAuth 2.0 scopes required for API export

Before building an export script, you need the correct OAuth 2.0 scopes if you're using OAuth-based authentication (rather than API tokens with basic auth). The minimum scopes required for read-only export:

If you're using an API token with HTTP basic auth (the simpler path for personal scripts), scopes don't apply — the token inherits the permissions of the associated user account. However, for production integrations and OAuth 2.0 apps registered in the Atlassian developer console, missing scopes are a common blocker that produces 403 errors rather than 401, making them easy to misdiagnose.

A basic paginated export script

import requests
import json
 
base_url = "https://your-domain.atlassian.net"
auth = ("your-email@example.com", "YOUR_API_TOKEN")
headers = {"Accept": "application/json"}
 
start_at = 0
max_results = 100
all_issues = []
 
while True:
    response = requests.get(
        f"{base_url}/rest/api/3/search",
        params={
            "jql": "project = SD ORDER BY created ASC",
            "startAt": start_at,
            "maxResults": max_results,
            "fields": "summary,status,created,customfield_10001"
        },
        auth=auth,
        headers=headers
    )
    data = response.json()
    all_issues.extend(data["issues"])
    
    if start_at + max_results >= data["total"]:
        break
    start_at += max_results
 
with open("jsm_export.json", "w") as f:
    json.dump(all_issues, f, indent=2)

JSM-specific REST API endpoints

The JSM REST API at /rest/servicedeskapi/ exposes service-desk-specific entities that the platform API doesn't cover directly. It allows you to access and update Jira Service Management entities such as requests, organizations, queues, and request types.

Key endpoints for data extraction:

Important distinction — customer accounts vs. Atlassian accounts: The /rest/servicedeskapi/customer endpoint returns service desk customer records, which may include portal-only accounts (customers who don't have full Atlassian accounts). These differ from licensed Atlassian user accounts returned by /rest/api/3/users. When exporting customer data for migration or GDPR compliance purposes, you need both endpoints — they return different populations.

For the /rest/servicedeskapi/request endpoint, the list returned includes only requests the caller created (or were created on their behalf) or requests they are participating in. If you need all requests regardless of the caller's role, use the Jira platform search API with JQL instead:

GET /rest/api/3/search?jql=project=SD

How to export SLA and CSAT data from JSM

SLA and CSAT (customer satisfaction) data in JSM are stored as custom fields on issues. They aren't exposed through a dedicated export endpoint — you pull them via JQL.

Use a JQL query like project = "IT" AND resolved >= "2025-10-01" AND resolved <= "2025-10-31" AND Satisfaction IS NOT EMPTY, then from the search results page choose Export > CSV (All fields) or CSV (Current fields). Use Current fields for a focused dataset.

For SLA data specifically, the relevant custom fields are typically customfield_10020 (Time to resolution) and customfield_10021 (Time to first response). These field IDs are not standardized across instances — they are assigned sequentially during field creation and will differ between any two Jira Cloud sites. Before building an export script, discover your actual field IDs using GET /rest/api/3/field and filter the response for fields with schema.custom containing "com.atlassian.servicedesk". Hardcoding customfield_10020 without verification is a reliable way to export empty columns.

Understanding Jira Cloud API rate limits for data exports

Jira Cloud's rate limiting system is the single biggest constraint for API-based data extraction. Three independent rate limiting systems operate simultaneously.

Points-based quota: the hourly budget

Atlassian is evolving how they measure API usage from simple request-per-second caps to a points-based approach. Each REST and GraphQL request consumes points based on the work it performs — the data returned or operations triggered. This approach more accurately reflects the impact each request has on shared infrastructure.

Starting March 2, 2026, phased enforcement began for the new rate limits across Jira and Confluence REST APIs.

The default tier (Global Pool) gives your app or integration 65,000 points per hour shared across all tenants. Point costs work as follows:

• A simple GET /rest/api/3/issue/ABC-123 costs 2 points (1 base + 1 for the issue object)
• A search returning 100 issues costs 101 points (1 base + 100 issue objects)
• A changelog fetch for a single issue with 50 history entries costs approximately 51 points
• A comment fetch returning 25 comments costs approximately 26 points

The real point cost of a full export: This math compounds quickly. For a 50,000-issue export where you also fetch changelogs and comments per issue:

At 65,000 points/hour, a full extraction with changelogs and comments for 50,000 issues requires approximately 20 hours of spread API calls — not a one-shot overnight job. Plan accordingly by either fetching only the fields you need, or spreading the export across multiple days.

Burst rate limits: the per-second ceiling

Even with ample hourly quota, you can't fire requests as fast as your network allows. The default burst limits are:

Some JSM endpoints have much lower limits. The /servicedeskapi/servicedesk/{servicedeskid}/customer endpoint is limited to 5 requests per second — a trap for scripts that iterate over multiple service projects to export customer lists. At 5 req/sec, exporting customer data across 50 service projects with large customer lists will hit 429s immediately unless you throttle explicitly.

What happens when you hit a rate limit

If your app or integration exceeds the allowed number of API requests in a short period, you will receive a 429 Too Many Requests error. These limits are enforced on a per-tenant per-API basis.

Your export script must check for 429 responses and respect the Retry-After header. Implement exponential backoff with jitter — not a fixed delay — to avoid the thundering herd problem if you're running multiple concurrent export jobs.

import time
import random
import requests
 
def make_request_with_retry(url, auth, max_retries=4):
    delay = 2
    for attempt in range(max_retries):
        response = requests.get(url, auth=auth)
        if response.status_code == 200:
            return response.json()
        if response.status_code == 429:
            retry_after = int(response.headers.get("Retry-After", delay))
            jitter = random.uniform(0.7, 1.3)
            wait = retry_after * jitter
            time.sleep(wait)
            delay = min(delay * 2, 30)
        else:
            response.raise_for_status()
    raise Exception(f"Max retries exceeded for {url}")

Assets API rate limits are separate

The Assets REST API has its own rate limiting scheme, distinct from the Jira platform limits. All Assets endpoints are rate-limited to 1,000 requests per minute per instance, with a total limit of 10,000 requests per minute per instance. Exceptions are noted in the documentation for individual endpoints.

Exporting JSM Assets (CMDB) data

JSM Assets — the built-in CMDB — stores configuration items, services, and their relationships in object schemas. Assets export is available only on Atlassian Cloud with a Jira Service Management Premium or Enterprise subscription.

The UI-based export creates a ZIP file containing:

• The schema structure (object type hierarchy and attribute definitions)
• All object types with their configured attributes
• All objects and their attribute values
• Object type icons and schema icons

What the ZIP does not contain:

• Object-to-object reference relationships (links between objects of different types) — these must be re-established after import
• Connected Jira issue links — you'll need to recreate these manually in the target instance
• Confluence-type attributes
• Attachment files stored on Assets objects

This means Assets export is suitable for schema migration and bulk object migration, but not for preserving the full relationship graph. For complete relationship export, use the Assets REST API to query reference attributes explicitly.

Exporting Assets object relationships via API

Object references are stored as attribute values with a type of objectReference. To export them programmatically:

# Query objects by type using AQL (Assets Query Language)
curl -X GET \
  'https://your-domain.atlassian.net/rest/assets/1.0/object/aql?qlQuery=objectType="Laptop"' \
  -u 'email@example.com:API_TOKEN' \
  -H 'Accept: application/json'

The response includes attributes for each object. Attributes with objectAttributeValues containing an referencedObject field are object references — serialize these separately to reconstruct the relationship graph in the target system.

For large schemas, use AQL pagination: the endpoint supports startAt and maxResults parameters, subject to the 1,000 req/min rate limit noted above.

Using Backup Manager for full-site exports

Backup Manager is Jira Cloud's built-in full-site export tool, found under Settings > System > Import and Export > Backup manager. It creates a downloadable ZIP containing all project data, configurations, boards, sprints, comments, users, and groups.

You can create a backup at any time. However, if you include attachments, avatars, and/or logos, you must allow 48 hours between backups. The 48-hour timer applies if any prior backup — with or without attachments — included attachments. Automation flows are not automatically exported; they must be manually exported and imported separately.

What Backup Manager excludes

This is where teams get burned. Jira Cloud's Backup Manager includes work items, configuration, boards, sprints, comments, users, and groups — and optionally attachments. The following are excluded:

• Automation rules — must be exported manually via the Automation UI
• Marketplace app data — any data stored by third-party apps (e.g., external integrations, add-ons that maintain their own data stores)
• Assets/CMDB data — excluded entirely; export separately via the Assets export
• Opsgenie-powered operations data — alerts, on-call schedules, escalation policies
• Historical SLA breach data — SLA configurations are included, but the historical record of which issues breached which SLA thresholds at what times is not separately extractable from the backup file
• JSM-specific reporting metrics — time-in-status data and queue throughput history are not preserved

Starting January 22, 2026, Backup Manager limits restores from backups to those that are 30 days old or less. Older backups can still be downloaded and inspected, but they cannot be imported back into Jira Cloud.

Critical limitation: Backup Manager creates a monolithic export. There is no way to restore a single project or individual issue from it. If you need granular recovery or project-level portability, you need either a third-party backup solution or a custom API-based extraction approach.

GDPR and data residency considerations

Exporting JSM data via the REST API typically surfaces personally identifiable information (PII) including user display names, email addresses, and account IDs. For organizations subject to GDPR or similar data protection regulations, several considerations apply:

• Customer records returned by the JSM API include email addresses for all portal users. If you're exporting to an external system, this data transfer must be covered by your data processing agreements.
• Account IDs vs. email addresses: Jira Cloud REST API v3 returns accountId (an opaque identifier) by default, not email addresses. To resolve account IDs to email addresses, you must make a separate call to GET /rest/api/3/user?accountId={id} — and this call requires the read:jira-user scope (or equivalent). Be aware that exporting and storing the resolution mapping creates a new PII dataset.
• Data residency: Jira Cloud data residency (available on Premium and Enterprise plans) pins specific data types to a geographic region. However, REST API responses are served from Atlassian's global infrastructure regardless of residency settings. If your compliance requirement covers data in transit, verify whether API-based export satisfies your residency controls.
• Right to erasure: If you export JSM data and a user subsequently invokes their right to erasure in Jira Cloud, your export copy is not automatically updated. Exported datasets must be managed separately under your data retention policy.

How to build a complete JSM data export pipeline

No single method exports everything from JSM. A complete extraction pipeline combines multiple approaches:

Step 1 — Issue data: Use the Jira Platform REST API (/rest/api/3/search) with JQL to export all issues, including custom fields for SLA metrics and CSAT scores. Paginate through the full result set. Specify only the fields you need — fetching all fields on every issue significantly increases point consumption and response payload size.

Step 2 — Comments and attachments: For each issue, fetch comments via /rest/api/3/issue/{key}/comment and attachment metadata via the issue's attachment field. Download actual attachment files via their content URLs. Note that comment bodies are also stored in ADF format in API v3 responses — parse accordingly.

Step 3 — Changelogs and audit trails: Fetch issue changelogs via /rest/api/3/issue/{key}/changelog to capture the full history of status transitions, field changes, and reassignments. This is the most point-expensive step in the pipeline — budget approximately 15 points per issue for a typical changelog, more for heavily worked tickets.

Step 4 — Service desk entities: Use the JSM REST API to export organizations (/rest/servicedeskapi/organization), request types, queues, and customer lists. Use the customer endpoint carefully given its 5 req/sec limit.

Step 5 — Assets/CMDB: Export object schemas via the Assets UI (ZIP export) for the schema structure, then use the Assets REST API with AQL queries to export objects and serialize reference attributes separately to preserve the relationship graph.

Step 6 — Knowledge base articles: If you're using JSM's knowledge base (powered by Confluence), that data lives in Confluence and must be exported separately through the Confluence REST API (/rest/api/v2/pages) or Confluence's own export tools. JSM's backup does not include Confluence content even when the spaces are linked to your service project.

Step 7 — Automation rules: Export automation rules manually via Project Settings > Automation > Export, or via the site-level Automation settings. There is no REST API endpoint for bulk automation rule export.

Approximate time estimates for API-based exports

These figures assume a single-threaded script respecting rate limits, fetching issues in pages of 100, with changelogs and comments fetched per issue:

These are estimates under normal rate limit conditions. Actual times vary based on average comment count per issue, changelog depth, and whether other integrations are consuming points from the same hourly budget simultaneously.

Marketplace export apps

For non-technical users or teams that need formatted output (PDF, Word, Excel with formatting preserved), several Atlassian Marketplace apps provide export capabilities beyond the native options:

• Better PDF Exporter for Jira — generates formatted PDF exports from JQL results, preserving rich text formatting that CSV export loses
• Jira Issue Export Plugin — supports Excel export with more field control than the native CSV export, including comment threads
• Pivot Gadget & Exporter — focuses on aggregate data export for reporting use cases

These apps store their own configuration data in app-managed storage, which means their settings and templates are not included in Backup Manager exports. If you uninstall and reinstall the app, configuration must be re-entered manually.

Common pitfalls when exporting JSM data

Assuming CSV export captures everything. The CSV export only includes issue fields visible in your navigator columns (if you choose "Current fields") or standard issue fields (if you choose "All fields"). Internal comments, SLA breach details, and rich-text formatting are lost or flattened to plain text.

Ignoring the 48-hour backup cooldown. When creating a backup without attachments, you can create another immediately with no timer. However, if you want to create a backup with attachments, the 48-hour timer applies regardless of the type of previous backup. Plan migration windows accordingly.

Assuming /rest/servicedeskapi/request returns all requests. This endpoint's response depends on the caller's permissions. Use GET /rest/api/3/search?jql=project=SD instead to retrieve all issues in a service project regardless of caller role.

Hardcoding SLA custom field IDs. customfield_10020 and customfield_10021 are not standardized. Always discover field IDs via GET /rest/api/3/field before building a pipeline.

Underestimating the points cost of changelog fetches. A 50,000-issue export with changelogs and comments can consume over 1 million points — roughly 20 hours at the 65,000 points/hour default limit. Many teams discover this mid-export when their scripts start receiving 429s after the first hour.

Not accounting for ADF in description and comment fields. API v3 returns description and comment bodies as ADF JSON, not plain text. If your downstream system expects readable text, you need to either use the v2 API (which returns HTML) or implement an ADF-to-text/HTML converter. The adf-builder library (Node.js) or atlassian-python-api handle this, but it adds pipeline complexity.

Overlooking team-managed projects in Data Center migrations. Team-managed spaces do not exist in Jira Data Center. To create a usable Data Center backup from a Cloud site, you need to delete or convert all team-managed projects from your Jira Cloud site first.

Not separating Assets relationship data from attribute data. The Assets ZIP export preserves attribute values but not reference links between objects. If your CMDB has object-to-object relationships, export them separately via the API before assuming the ZIP captures your full data model.