48 hours. That's the minimum wait Jira Cloud's own backup manager imposes between two backups if you want attachments, avatars, or project logos included in the export. If your team decided this week that it's time to evaluate life after Jira, and you want a safety copy of your sprint data before anyone starts poking at settings, that's the first wall you'll hit.
The good news: you don't need the full-instance backup tool just to protect sprint data. The bad news: the faster manual methods each drop something, and most teams don't find out what until they're already looking at the exported file.
What Jira's built-in backup actually covers
The Backup Manager, tucked into Jira Cloud's System settings under Import and Export, produces a full-instance XML backup — every project, every issue, every workflow. It's thorough, and it's also overkill for a team that just wants last quarter's sprint history in a form they can reference later. It's also slow: large instances with attachments can take hours to generate, and Atlassian's own documentation notes the 48-hour cooldown between backups that include binary content.
For a single team backing up its own sprint data rather than an admin backing up the whole instance, three lighter methods cover most of what people actually need.
Three ways to export sprint data by hand
1. Advanced Issue Search with a JQL filter. Query sprint = "Sprint 34" (or filter by board and a date range), open the results in the issue navigator, and use the Export option to get a CSV or Excel file. This is the fastest path and the one most people reach for first.
2. The sprint report's own export. Inside a closed sprint's report, "View in issue navigator" hands you the same issue list the report was built from, which you can then export the same way as above. Useful when you want the exact issue set a specific sprint report was generated from, rather than building the JQL filter yourself.
3. An automation rule that exports on a schedule. Jira's automation feature can trigger an export whenever a sprint closes, which is the only one of the three that doesn't rely on someone remembering to do it manually.
All three get you a spreadsheet. None of them get you a sprint.
> A CSV export turns "Sprint 34" into a text value sitting in one column next to three hundred other issues. It doesn't preserve which sprint an issue belonged to as a structured relationship, it doesn't carry the sprint's start and end dates as sprint metadata, and it has no idea what your team's velocity was going into or coming out of it. You get the issues. You lose the sprint.
That distinction matters more than it sounds like it should. If the reason you're exporting is "just in case," a flat CSV is a fine insurance policy — you can always reconstruct which issues were in which sprint from the exported field. But if the reason you're exporting is that your team is actually evaluating whether to keep using Jira at all, a spreadsheet isn't something you can plan a sprint from. It's an archive, not a working backlog.
When a backup is really the first step of a migration
Teams that go looking for "how do I back up my Jira sprint data" split roughly two ways. Some genuinely just want an archive before a plan or admin change. Others are backing up because they're quietly testing the water on leaving Jira altogether, and a local export feels like the low-commitment first move.
If you're in the second group, it's worth knowing that the export you're about to build by hand is close to what a direct import tool does automatically — minus the manual JQL-writing and minus the parts a spreadsheet can't represent. Spryn's own Jira import connects via OAuth, is read-only against your existing Jira instance (nothing in Jira changes, nothing is deleted or modified), and brings across issues, epics, story points, assignees, and labels with a preview step before anything is written into your workspace. If OAuth access isn't available in your setup, the same import also accepts a CSV — which means the export you just built with JQL isn't wasted even if you decide to bring in the rest of the backlog properly later.
The practical difference: a JQL export is a snapshot you did once, for a moment in time. An OAuth import lands your current backlog — priorities, labels, and all — as a working set you can plan a sprint against the same day, rather than a file you have to rebuild structure from by hand.
The honest recommendation
If you only need a safety copy: the JQL export in method one takes ten minutes and is enough. Save the CSV somewhere durable and move on.
If you're exporting because your team is seriously weighing a move off Jira — whether that's driven by Jira Data Center's end-of-sale timeline (see spryn.io/blog/agile-sprint-management/jira-data-center-end-of-sale) or just per-seat costs creeping up every renewal — don't stop at the spreadsheet. Read what actually transfers at spryn.io/migrate-from-jira, or see the full self-hosted pricing at spryn.io/pricing before deciding whether a one-time license changes the math for your team.