How to export your data from Jira

Measure attachment volume before you schedule anything. Jira Cloud's backup for cloud is capped at 25 GB of total data, and any backup that includes attachments, avatars or logos must be at least 48 hours after the previous one. Those two limits interact. If your instance is close to 25 GB, a single attachment-bearing backup may leave little headroom, and a second one cannot start until the 48-hour gap has passed. Check attachment storage in your Jira Cloud administration views before you commit to a sequence, and ask Atlassian to confirm how the cap applies to your site's current totals, since the figures that count toward it are the ones Atlassian reports, not the sum of files you remember uploading.

Plan the full set of backups around the cutoff, not around a single run. Work backwards from the date you plan to stop using Jira Cloud. Each attachment-bearing backup needs its own 48-hour window, so a large instance may need several runs spread over days. Map those runs onto your project calendar, avoid running them during release freezes or audit periods, and keep a record of each run's date. Backups without attachments do not carry the same spacing requirement, so you can use them to refresh issue and configuration data between the heavier runs. Test the sequence on a non-production copy first if your organization has one.

Treat the 30-day restore window as a storage deadline. From January 22, 2026, only backups 30 days old or less can be restored. A copy you keep for compliance evidence or a fallback is only useful if it stays inside that window or if you also keep the exported files outside Jira. Store each backup and its checksum in a location you control, label it with the date and the scope it covers, and set a reminder to refresh it before it ages out. Confirm with your Atlassian administrator where the downloaded archive is held and who can access it, because the archive contains the same sensitive data as the instance.

Treat the export as unfinished until you have shown that it matches the source. Before your Jira Cloud access ends, reconcile work item counts per project against what the Jira interface reports for the same filters, then check attachment counts, user lists and project keys. Compare the number of exported CSV rows with the count returned by the issue navigator, and note any project where the CSV was split because it exceeded the 10,000 work item limit. Record the reconciliation in a simple table with the project key, source count, exported count, attachment count and the person who checked it. Gaps found here are far cheaper to chase while your administrator still has access.

Keep an offline copy of every backup and CSV file in storage that your retention policy already covers, with the same classification as the source data. Record which backup archive and which CSV files belong to which projects, and store that index with the files, not in the Jira site that is being retired. Store file checksums alongside the copies so you can show later that nothing changed. Confirm with your legal and records team how long exported project data must be kept, who may access it, and whether personal data in user fields and comments needs extra handling.

A backup that has not been restored in a test has only limited assurance, because you have not yet proven that the archive can be read and that the data is usable. Plan a restore test into a separate environment, and check the restored projects against your reconciliation table. Keep the results, the date, and the names of the people involved. Remember that backups excluding automation rules, third-party apps and Assets must be rebuilt separately, and list those gaps in the same record. DeployOpen can prepare these controls and evidence for a compliance assessment, but independent auditors and certification bodies issue any audit report or certification.

Before you plan the export, confirm the points that the published documentation leaves to your own contract and instance. Start with your current plan limits. Ask your Atlassian account team or check your administration console for the storage limits that apply to your Jira Cloud site, because the backup limit of 25 GB is a total for the site, not per project. Measure your instance's data volume, including attachments, and compare it with that figure before you rely on a single backup. If the total is close to the limit, plan a separate export route for the largest projects instead of assuming one backup will cover everything.

Next, confirm the notice period in your contract. The records that matter are the renewal date, any termination clause, and the date after which your Jira subscription stops or changes status. Ask your procurement or legal contact to state that period in writing so your migration schedule starts from a known date rather than an estimate. Also remember the backup constraints: backups that include attachments need a gap of 48 hours between them, and only backups 30 days old or less can be restored from January 22, 2026. Build your schedule so that a recent, restorable copy exists at each stage of the migration.

Finally, inventory the apps and features that hold data outside Jira's core tables. Your Jira administrator should list every marketplace app, every automation rule, and any Assets or Product Discovery content in use, then confirm with each app vendor how that data can be exported, since backup for cloud does not cover these items. Ask your own team to name the business owners of each workflow and each dashboard that must be rebuilt by hand. A short register of these items, agreed with the people who use them, is the most reliable way to avoid losing working processes during the move.