Skip to content

Issue tracking and projects

How to find and size your Jira data.

Find how many work items Jira Cloud holds, and how a full-history export works through Backup manager, CSV batches and the REST API.

Find how much you have

  1. Sign in as someone who can see every project you plan to count. Jira search returns only work items where you have the Browse projects permission and, where issue-level security is set up, permission to view that item. If you cannot see a project, ask a site admin to run the counts. Atlassian now calls issues work items and projects spaces, so you may see either word.

  2. Open Search (or Filters in the sidebar), then View all work items. If basic search appears, switch to JQL. Enter created >= "2000/01/01" and run it. Atlassian says a large result shows at the bottom as 1000+, and selecting that label replaces it with the exact total. JQL needs the date in quote marks.

  3. Split the total so it means something. Add project = KEY for each main project, or add a created range such as created >= "2022/01/01" AND created < "2023/01/01", and note each count. The yearly totals show where the activity was heaviest.

  4. Check archived projects. Atlassian says that when a space is archived its work items stop appearing in basic and advanced search, so an archived project is missing from the totals above. Archiving is a Premium and Enterprise feature, and Jira and site admins can open the archive to see which spaces are archived and restore them. The REST search takes an includeArchivedProjects parameter to bring those items back.

  5. A developer can count through the API instead. Send POST /rest/api/3/search/approximate-count with a JSON body such as {"jql": "created >= \"2000/01/01\""}. Atlassian says the older search endpoint is being removed and its replacement does not return a total. The count endpoint gives an estimate, needs a bounded JQL query (one with a search restriction), and can lag recent changes, so mark the figure Estimated.

  6. Find the start date by sorting oldest first. Run created >= "2000/01/01" ORDER BY created ASC and read the Created date of the first result. If you imported from another tracker, say so in your description.

What to put on your intake

Your intake has five boxes for each system. Here is what goes in each one for Jira.

What does it hold?
Work items with descriptions, comments, status history, sprint and epic links, and attachments if you want them in scope. Name the main projects, and say whether Jira Service Management requests are included.
Data types
Text for descriptions and comments and Structured records for fields and status history. Add Image only if screenshot attachments are in scope.
How big is it?
Issues, from the JQL total across the projects in scope, including archived projects if you would license them. Put the number of projects and attachment storage, if you know it, in the description.
Verified or estimated
Verified when it is the total from a search run by someone who can see every project. Estimated when it came from the approximate count endpoint, or from one project scaled up.
Records start
The Created date of the oldest work item, from the ORDER BY created ASC search. Mention it if the early history was imported from another tool.

Exporting the full history

If a buyer licenses your records, this is how the full history comes out of Jira.

  1. Nothing is exported until a buyer licenses the data and the scope is agreed: which projects, which dates, and whether comments, change history and attachments are in. The steps below show what to expect.

  2. A whole-site backup comes from Backup manager. Go to Settings, then System, then Backup manager under Import and export, and select Create backup for cloud. Tick the option to include attachments, avatars and logos if the scope calls for it, and select Download backup file when it finishes.

  3. Atlassian strongly recommends staying within 25 GB of total data and 50 to 100 GB of attachments for exports to succeed. If a backup includes attachments, avatars or logos, you must allow 48 hours before the next backup. Backups without them can run at any time.

  4. A backup leaves things out. Atlassian lists automation flows (which can be exported manually), third-party apps and their data, Assets for Jira Service Management, features powered by Opsgenie, app access settings, and the views, insights and vote fields of Jira Product Discovery.

  5. For a narrower export, run the search you want and export it from the work item search. Atlassian says the asynchronous CSV export supports up to 10,000 work items at a time. For larger sets, split the query with JQL into batches under 10,000, using created date ranges, then export each batch and merge the files. Atlassian suggests checking that the batch counts add up to the total and that no item appears twice. Choose only the fields you need, because the all-fields options slow the export and produce large files.

  6. For full text and history, a developer can use the REST API. POST /rest/api/3/search/jql pages with a nextPageToken and returns up to 5,000 items a page, fewer when many fields are requested. Each work item's change history is at GET /rest/api/3/issue/{issueIdOrKey}/changelog, oldest change first. Under the license, names, email addresses and customer details are removed before delivery.

We only ask for an export after you sign a license and agree the scope. Sizing your data for the intake never needs one.

Limits to know

  • Atlassian describes the backup as work items and field content, boards and sprints, users and groups, comments, space configuration, Advanced Roadmaps data and, if selected, attachments. Unzipped, the database data sits in two XML files, activeobjects.xml and entities.xml, with attachments, avatars and logos in their own folders. It is built for restoring into Jira, so have an engineer open a small one before you promise a buyer a particular format.
  • Your organization may have blocked exports. Atlassian says organizations can choose to prevent people from exporting data, so a missing menu option may be a policy, not a bug.
  • Anything kept by an app, such as test management, time tracking or custom reporting add-ons, is outside the backup. If that is where the value sits, the app's vendor is the place to ask.
  • Archived projects drop out of search by default, and archiving is only available on Premium and Enterprise plans. If a site moved to a Standard plan after archiving, admins can still view the archive and restore spaces, but cannot archive new ones.
  • Atlassian says it cannot use its own database backups to roll back changes such as deleted issues, projects or sites. Anything deleted for good is gone, so do not count on Atlassian to recover history that is years old.
  • Canceling does not keep your data forever. Atlassian says that after a subscription period ends you keep access for 15 days, then the site is deactivated and the data is held for a retention period that is 60 days on the Free, Standard, Premium and Enterprise plans and 15 days for trials. After that it is permanently deleted. Export before you cancel.
  • API use is metered. Going over a limit returns HTTP 429, and the Retry-After header says how many seconds to wait. Apps built on Forge, Connect or OAuth 2.0 (3LO) also have an hourly points quota, while scripts that use an API token stay under the per-second burst limits. A developer should back off and retry rather than hammer the endpoint.
  • This guide covers Jira Cloud. Jira Data Center runs on your own infrastructure, and the Cloud steps above do not apply to it, so say which one you use in your description.

This guide isn't legal advice. Check your contracts, and any recording-consent rules that apply, with your own lawyer.

Why buyers value it

A Jira site is where a software team writes down what it meant to build and why it changed course. Each work item records a problem in the author's own words, the discussion that shaped the fix, every status change, and who reviewed it. Where a ticket also names the pull request that closed it, you get a problem paired with its solution, which is the pattern buyers building coding and bug-triage agents look for.

Over years the same site also shows how estimates compared with reality, which bugs kept coming back, and how priorities moved. That planning trail rarely exists anywhere outside the company that did the work.

What stays private

Buyers receive de-identified operating records. Under the license, the de-identification step before delivery removes or excludes:

  • People: reporter, assignee and commenter names, email addresses and account IDs, plus @mentions inside text.
  • Customer details: customer names, account and contract numbers, and ticket numbers from outside systems that people pasted into descriptions and comments.
  • Credentials: passwords, tokens and keys pasted into tickets or attachments. Anything found is yours to rotate.
  • Sensitive work: unpatched vulnerability reports, security incidents, and hiring or performance tickets.
  • Attachments: screenshots, logs and exports, which often show customer data, unless a specific package is agreed.

Common questions

Atlassian's search shows 1000+ when a result set is large. Select that label and Jira calculates the real total. If you count through the REST API instead, the replacement search endpoint does not return a total, so use the approximate count endpoint and mark the number Estimated.

Not in one file on a large site. Atlassian says the asynchronous CSV export supports up to 10,000 work items at a time. For more, split the search by created date into batches under 10,000, export each one and merge them, then check the batch counts add up to your total.

Requests in a Jira Service Management space can be searched as work items, so a site-wide search includes them. Decide whether you want them in scope. Atlassian also lists Assets for Jira Service Management among the things a site backup leaves out.

Sources

Vendor documentation, checked . Screens and plans change, so if a step looks different in your account, check with Jira.