Exporting your data from Jira Service Management before a contract ends
If you face a renewal, the Data Center end-of-life deadline or a decision to leave Atlassian, you need a complete copy of your service desk before anything changes. Cloud backup and CSV exports cover work items and project configuration, but automation rules, third-party apps and Assets need separate handling. Jira Cloud's backup manager for cloud includes work items, comments, users and groups, and project configuration, and excludes automation rules, third-party apps and Assets. This guide covers only the export paths Atlassian documents, so anything outside them needs its own verification.
Start with the backup for cloud and the Export CSV from the issue navigator, which supports up to 10,000 work items. The older pager workaround is limited to 1,000 work items per batch and is being phased out, so plan the CSV export around the newer method. Backup for cloud is limited to 25 GB of total data, and attachments require 48 hours between backups. Confirm with your organization admin that exports are not blocked for particular app instances or classification levels, since admins can restrict them.
Treat the gaps as a separate inventory. Export Assets objects per object type through Bulk actions and Export objects, choosing the delimiter, encoding and the data consistent format meant for migration, which preserves references and dates. Then list every automation rule, app configuration and integration, and record how each is rebuilt in the target system, because none of them arrive in a backup. Ask Atlassian support to confirm the current export limits for your plan before you set a date, and keep a dated, verified copy of every export outside Atlassian.
Which Jira Service Management data exports, and in what format
This table compares each Jira Service Management Cloud export path by what it contains, its limits and who can switch it off. Read it to see which export covers work items, which covers Assets and where automation rules and apps still need separate handling.
| Export path | What it includes | Limits and conditions | What it leaves behind |
|---|---|---|---|
| Backup for cloud | Work items, comments, users and groups, and project configuration | Total data capped at 25 GB; attachments included require 48 hours between backups (Atlassian support) | Automation rules, third-party apps and Assets |
| Asynchronous Export CSV from the issue navigator | Work items matching the current search, as CSV | Up to 10,000 work items per export | Comments and history depend on the fields selected; confirm field choices before export |
| Legacy pager and start URL workaround | Work items in batches | 1,000 work items per batch; Atlassian is phasing this method out | Same gaps as the navigator export; plan migration away from this method |
| Assets CSV export (Bulk actions, Export objects) | Assets objects, exported one object type at a time | Comma, semicolon or tab delimiter; several encodings; a migration-format option preserves references and dates | Requires a Service Collection paid plan: Standard, Premium or Enterprise |
| Org admin export restrictions | Blocks exports for particular app instances or classification levels | Set by organization admins, so the account owner may not be able to export everything | Confirm with your admin which app data and classification levels are blocked before planning |
| Automation rules and app data | Rules and third-party app records are not in backup for cloud | Must be recorded or rebuilt manually, or exported through the app vendor if available | Confirm each app's export option with its vendor before the migration plan is fixed |
What the backup leaves behind and how to recover it
The Jira Cloud backup covers work items, comments, users, groups and project configuration, but it leaves several things out. Each card below names one gap, the workaround that fills it, and what to confirm before you rely on it.
Automation rules are not backed up
Backup for cloud excludes automation rules, so every trigger, condition, branch and approval step has to be recorded before you leave. Export the rule list from the automation settings, screenshot or document each rule, and note the owner and the projects it touches. In the new environment, rebuild the rules by hand and test each one against sample tickets. Expect the rebuild to be the largest manual task in the export, because rules often encode SLA and routing logic that agents depend on.
Third-party app data stays behind
Apps installed from the Atlassian Marketplace store their data outside the core work item tables, and the backup does not include third-party apps. Make an inventory of every app that touches requests, approvals, forms or reporting, then ask each vendor whether it offers a documented export and in what format. Do not assume the app data can be recovered from a Jira CSV. Confirm app-specific export paths with the app vendor before the cutover date.
Assets needs its own export
Assets is excluded from the cloud backup, so configuration items and their references must come out through the separate Assets export. Use Bulk actions and Export objects, one object type at a time, and pick the Data consistent format if you plan to migrate, since it keeps references and dates intact. Choose the delimiter and encoding your target platform expects, and check that object relationships still resolve after import. Assets is available on Standard, Premium and Enterprise Service Collection plans, so confirm which plan your site uses.
Backups above the 25 GB limit
Backup for cloud is limited to 25 GB of total data, and attachments count toward that total when they are included. Check your site's storage before you plan the export, and if you are over the limit, split the work by project or by date range so each export stays within bounds. Also note that with attachments included, Atlassian requires 48 hours between backups, so plan the sequence of exports in advance rather than running them back to back.
CSV exports cap at 10,000 items
The issue navigator's asynchronous Export CSV supports up to 10,000 work items. For larger projects, split the query by project, by created or updated date range, or by status so that each export returns fewer than 10,000 items. Keep a record of which ranges you exported so you can confirm that the totals match your work item count. The older pager and start URL workaround is limited to 1,000 items per batch and is being phased out, so do not build the process around it.
Organization admins can block exports
Organization admins can block exports for particular app instances or classification levels. If a site has these restrictions, a service desk lead or migration engineer may find that an export option is missing or that data is refused, even though they hold project permissions. Ask the organization admin for a list of active export restrictions before the project starts, and get written approval for any exemption needed for the migration. Record the approval in the project file, because auditors and data owners often ask who authorized the transfer.
Sequence for a complete export with verification
This sequence captures everything Jira Service Management Cloud can hand over, records what it cannot, and proves the export matches the source before any migration or cancellation decision is made.
Inventory projects, apps, rules and Assets object types
The Jira site administrator lists every project with its approximate work item count, every installed app, every automation rule and every Assets object type, and saves the list as the baseline for later checks. Automation rules and third-party apps sit outside the cloud backup, so this inventory is the only record of them. The step is complete when the list is saved and each project has a work item count recorded from the source, not from memory.
Confirm organization admin export permissions
Check with the organization admin that your account can run backups for cloud and export CSV data, and ask whether any export blocks are set for particular app instances or classification levels. Organization admins can block exports for specific apps or classifications, so a block discovered mid-export delays the whole sequence. The step is complete when the admin confirms in writing which exports are permitted and which data is blocked.
Run a backup for cloud with attachments
Start a backup for cloud from the backup manager with attachments included, then record the date and time the backup was created in your inventory. The backup covers work items, comments, users and groups, and project configuration, but excludes automation rules, third-party apps and Assets. Confirm that the total data is within the 25 GB limit for backup for cloud, and plan the next backup around the 48-hour gap Atlassian requires between backups with attachments. The step is complete when the backup finishes and its date is recorded.
Export CSV per project in batches
Run the asynchronous Export CSV from the issue navigator for each project, filtering so that no single export exceeds 10,000 work items. Split larger projects by date range or by status so each file stays within the limit, and name each file with the project key and date range. Avoid the older pager and start URL workaround, which is limited to 1,000 work items per batch and is being phased out. The step is complete when every project has its files saved and the file names match the inventory.
Export Assets object types in migration format
For each Assets object type, open Bulk actions and choose Export objects, selecting the Data consistent format meant for migration so references and dates are preserved. Choose one delimiter and encoding for the whole set and record them, because the target platform's import needs to match them. Assets is only available on Service Collection paid plans, so confirm the plan before planning this step. The step is complete when each object type has a CSV file and the export settings are written down.
Document rules and app configuration by hand
Because automation rules and third-party apps are not part of the cloud backup, record each rule's trigger, conditions and actions, and each app's configuration, in a document kept with the export files. Screenshots and written descriptions both help, and the owner of each rule should review the entries. The step is complete when every rule and app from the inventory has a matching entry and the owner has signed off on it.
Verify counts, attachments and Assets references
Compare the work item count in each CSV file with the count recorded in the inventory, and investigate any gap before continuing. Open a sample of attachments from the backup and confirm they match the originals in Jira. In each Assets CSV, check that reference columns point to object identifiers that exist in the same export, and that dates match the source. The step is complete when every project and object type passes these checks and the results are stored with the export files.
How the backup, CSV and Assets exports fit together
A complete archive is the union of three separate exports plus the records none of them cover. The Jira Cloud backup for cloud holds work items, comments, users and groups, and project configuration, but it excludes automation rules, third-party apps and Assets. The issue navigator CSV export covers work items only, and it caps a single export at 10,000 work items. The Assets CSV export runs per object type, so each object type needs its own pass. Map those three scopes against your own inventory before you call the export finished, and list everything that falls outside all three, such as automation rule logic, app-held data and any attachments you did not include in the backup.
Because the backup has a 25 GB total data limit and enforces 48 hours between backups when attachments are included, plan the sequence around those limits rather than running everything on one day. Confirm with your organization admin whether export blocks are set for particular app instances or classification levels, since a blocked app will leave its data out of every path. Keep a dated inventory of which export produced which file, because the three outputs use different identifiers and formats.
Zammad has no built-in Jira migrator, so the CSV and API-based extracts become the input to a rebuild. Your team or a partner maps exported work items, customers and users into Zammad through its API, then recreates queues, SLAs and automation logic by hand, since none of the export paths carries those rules across. GLPI needs its Assets data extracted separately from the Assets CSV export and mapped into its inventory and CMDB, so plan that mapping as its own workstream. Ask any implementation partner to show, in writing, how each export path feeds each target object before work starts.
What to plan before the renewal or termination date
Exporting from Jira Service Management is rarely a single action. The steps below depend on your contract, your Atlassian dates and the platform you are moving to, so decide them together and set the order before anyone runs an export.
Align the export with Atlassian dates
If you are on Data Center, Atlassian's dates shape the whole project. New Data Center subscriptions stop for new customers on March 30, 2026, existing customers can buy licenses or expansions until March 30, 2028, and licenses become read-only on March 28, 2029. Confirm which of these dates applies to your contract and build your export plan backward from the one that matters to you.
Confirm the Assets plan tier
Assets is available only on the Service Collection paid plans: Standard, Premium and Enterprise. Check the tier in your current contract before you plan the Assets export, because the schema, objects and references you need to move depend on it. If Assets sits in a plan you are about to drop, export it while you still have access.
Request export permissions early
Some export options depend on organization administrators, who can block exports for particular app instances or classification levels. Ask the administrator who controls these settings to confirm in writing that exports are allowed for the products and data you need. Find out who holds that role before the project starts, not on the day the contract ends.
Plan storage for the archive
Cloud backups include work items, comments, users, groups and project configuration, but exclude automation rules, third-party apps and Assets. A backup with attachments also needs a gap of 48 hours between backups, so schedule runs with that in mind. Estimate how much storage the backup, CSV files and Assets exports will need, and confirm where the archive will be kept after the subscription ends.
Record retention for regulated data
Work items often contain personal data, customer details or incident records that have legal retention periods. Record which projects hold regulated data and which retention rules apply to each. Decide whether the export is a complete archive or a subset, and document who approves the deletion of the data in Jira once the archive is verified.
Agree the import scope with the target
Before you export, agree with the GLPI or Zammad team which objects must arrive: open requests, closed history, customers, queues, attachments and Assets. Zammad has no built-in Jira migrator, so its import runs through the API, while GLPI needs a defined mapping for requests, changes and Assets. Rebuild automation rules and SLAs manually from your documentation.
Questions buyers ask before exporting Jira Service Management data
How much effort does a Jira Service Management export take?
The effort depends mostly on the size and shape of what you export, not on the export button itself. Work items are the simple part: the issue navigator's asynchronous CSV export supports up to 10,000 work items, and larger sets need a different approach. The work grows with four drivers: the number of work items and their history, the Assets schema (object types, references and attribute complexity), the number of apps whose data sits outside Atlassian's standard export, and the volume of attachments. Each driver adds mapping, testing and verification time, so ask for a scoping inventory before you agree a timeline.
Can an internal admin run the export without outside help?
Yes, for the standard parts. A Jira site administrator can run the Jira Cloud backup for cloud, and an Assets administrator can export objects per object type from Bulk actions. What internal teams usually find harder is the gap work: rebuilding automation rules, reconnecting third-party app data, reconciling references between Assets objects and work items, and checking that the export is complete and readable in the target system. If your team has done a migration before, a small internal effort may be enough. If not, a written scope with an outside partner often reduces the risk of missing data.
What does the export need from our team?
Plan for three things before work starts. First, the right administrative rights: Jira site administration, Assets administration and, where relevant, organization admin rights, since organization admins can block exports for particular app instances or classification levels. Second, storage: backup for cloud is limited to 25 GB of total data, so you need a destination with room for the full output, plus space for attachments if you include them. Third, a named verification owner from the service desk who signs off that tickets, customers, queues and Assets records look right in the new system before the old one is retired.
Is the Jira Cloud backup enough to leave Jira Service Management?
No. The backup for cloud includes work items, comments, users and groups, and project configuration, but it excludes automation rules, third-party apps and Assets. It also requires 48 hours between backups when attachments are included, which affects how you plan a cutover. Treat the backup as the base layer for ticket history, then add the Assets CSV export, a documented inventory of automation rules and app data, and a rebuild plan for workflows, SLAs and request types. Without those separate steps, a successful backup can still leave a service desk unable to operate.
Which parts of the export carry the most risk?
The highest risk sits in data that Atlassian's standard export does not carry in one file. Automation rules are the usual gap, because their logic must be read, documented and rebuilt in the target platform. App data depends on each vendor's export options, so confirm them one app at a time. Assets references and dates need care: the Assets CSV export offers a data consistent format meant for migration that preserves references and dates, and choosing the wrong format can break links between objects. Finally, confirm that the export respects your classification and retention rules before you move data outside Atlassian.
What does a fixed-scope export engagement from DeployOpen cover?
DeployOpen plans and implements self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope. A written scope usually sets out which sources are in, the export and verification steps, the target platform, the deliverables and the timeline, all agreed before work starts. Ongoing support and upgrades can follow as a retainer. DeployOpen does not publish a price list, so the cost follows from the written scope, and the drivers are the same ones described above: volume, Assets complexity, apps and attachments. Ask for a quote that lists each of these items separately.
What should we ask for in a quote for this export?
Ask for a quote that separates one-time work from recurring costs. One-time items include the scoping inventory, the export runs, the mapping of Assets and automation rules, test imports and the verification sign-off. Recurring items include hosting, any retained support and any vendor support subscription you choose for the target platform. Ask who performs each task, which of your staff must be available and for how long, and what the quote excludes, such as app-specific exports or rebuilding workflows. Asking for these details makes quotes comparable.
Verifying the export before you cancel anything
Do not cancel the Jira Service Management subscription or let the Atlassian-side data age out until you have proven that the export is complete. The first check is counts per project: compare the number of work items in each project against the issue navigator for the same project, using the same filter you used for the export. Note the totals in a short table with the date, the project key and the filter, so a later reviewer can repeat the comparison. Where the navigator count and the export differ, find the cause before you accept the archive. Typical causes are items in a project you did not include, or a CSV export run against a filter that changed after you started. For large projects, the asynchronous CSV export is limited to 10,000 work items, so split any project above that size into date-bounded or status-bounded batches and reconcile the batch totals against the navigator total.
The second check is a sample of attachments. Choose a set of issues across several projects and types, including old tickets, large files and issues with many comments, then open the attachments and confirm they render and match the original file size. The cloud backup includes attachments only when you ask for them, and it is capped at 25 GB of total data, so confirm which attachments are missing before you rely on a backup alone. For Assets, compare objects by reference rather than by name. Pick several object types, check that the exported references and dates point to the objects they should, and use the Data consistent format when the target is a migration. Assets exports are per object type, so repeat the sample for each type you care about.
The strongest test is a restore or import on the target platform. Load the export into a non-production GLPI or Zammad instance, confirm that users, groups, requests and comments arrive with the right states and timestamps, and record what did not arrive. Automation rules, third-party app data and workflow logic will not appear in the archive, so list them separately and decide whether each one is rebuilt, retired or dropped. Keep the verified archive, the test log and the decisions under your own retention rules, which are set by your legal, records and sector obligations, not by the vendor. If an assessor will review the migration, DeployOpen can prepare the evidence and controls for that review, but it does not issue audit reports or certifications. Independent auditors and certification bodies make those determinations.
How DeployOpen scopes and delivers a Jira Service Management export
DeployOpen approaches an export from Jira Service Management as a fixed-scope piece of work agreed in writing before anything starts. We plan which data sets must leave Jira Cloud, which need a separate extraction path such as the Assets CSV export, and how each one lands in your own infrastructure, with the gaps documented rather than hidden.
How we scope
- Inventory which work items, projects, customers, Assets objects, automation rules and apps your service desk depends on
- Record which items the Jira Cloud backup covers and which it excludes, so every gap has a named owner
- Agree in writing the export formats, target platform, volume limits and sign-off criteria before work begins
How we build
- Run exports against a copy of the data and check row counts, attachments, references and date formats
- Rebuild excluded logic such as automation rules and app-dependent fields as documented specifications
- Test the extracted data in the target environment and record each deviation from the source system
How we hand over
- Deliver written documentation of every extraction step, file format, mapping and known limitation
- Provide a reconciliation report comparing source and target records for the agreed data sets
- Keep export scripts and configuration in your repository so your own team can repeat the process
How we support
- Engagements are fixed-scope, and any follow-on work is quoted from a new written scope
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Ask us to confirm the Atlassian limits and plan entitlements that apply to your tenant at the time of scoping
