Software companies
Jira and Confluence Cloud at shutdown: backup before the site is deleted
By SourceX Editorial · Updated
Short answer
Back up Jira and Confluence Cloud before cancelling by running the native site backups with attachments and taking a separate readable export of issues, comments, links, change history and page versions. The deciding rule: a restore-only backup is not enough once no Atlassian site exists, so keep a copy you can open without one and verify counts first.
Key takeaways
- After a subscription ends, an Atlassian Cloud site is deactivated and later deleted under Atlassian's policies, so finish and verify the backup before cancelling.
- Native site backups are built to restore into another Atlassian site; keep a second, readable copy as well.
- Issue links, change history and Marketplace app data are the parts most often missing from a quick export.
- Verify issue and page counts per project and space, open sample attachments and check that links resolve.
- Set security, HR, legal and service desk projects apart before anyone reviews the archive.
What happens to a Jira and Confluence Cloud site when the subscription ends?#
When a Jira or Confluence Cloud subscription ends, the site is deactivated and its data is later deleted on Atlassian's schedule. Atlassian's cancellation documentation says cancellation takes effect at the end of the billing period, the site stays accessible for 15 more days after the subscription period ends, and unsubscribing from all Jira products on a site deletes the Jira data immediately. Retention windows after deactivation have differed across versions of Atlassian's DPA, so check the current terms and your billing emails rather than counting on a grace period.
In a wind-down, the bigger risk is the sequence of events. Company cards get cancelled, the admin who knew the site leaves, and a renewal lapses before anyone has exported. Treat the Atlassian site as a system of record with its own shutdown plan, owned by the CTO or the last engineering lead.
Backup scope: what a complete Jira and Confluence archive includes#
A complete Jira and Confluence archive covers the work itself and the connections between pieces of work. Issues alone are not enough; comments, attachments, links and history are what show how problems were diagnosed and solved, and they are what make the archive useful to anyone later.
| Record family | Why it matters | How to capture it | Check after export |
|---|---|---|---|
| Issues and fields | Core record of each bug, task and request | Native Jira backup plus an API or CSV export per project | Issue count per project matches the live site |
| Comments | Diagnosis and discussion between engineers and support | Native backup; API export for a readable copy | Long threads read end to end |
| Attachments | Logs, screenshots and specs referenced in comments | Backup with attachments enabled, files stored alongside | Sample files from several years open |
| Issue links and epics | Tie bugs to fixes, releases and parent work | Native backup; API export keeps link types and keys | Linked keys resolve inside the archive |
| Change history | Shows status changes, reassignments and resolution | Native backup or API changelog export | History present on sampled closed issues |
| Workflows and custom fields | Needed to interpret statuses and field values | Native backup plus a written field map | Field names map to IDs in the readable copy |
| Confluence pages and versions | Specs, runbooks, postmortems and decisions | Native Confluence backup plus HTML space exports | Page tree and version history present |
| Page and inline comments | Review discussion on design documents | Native backup; check readable exports separately | Comments visible on sampled pages |
| Marketplace app data | Time tracking, test cases, roadmaps | Often stored by the app vendor; use each app's export | Every installed app accounted for |
Why a native backup alone is not enough#
A native backup alone is not enough because it is designed to restore into another Atlassian site, not to be read by people. Once the company has no site, opening the backup means setting up a new one, restoring and hoping the format still imports cleanly.
Keep two copies: the native backups as the faithful record, and a readable export that a reviewer, an acquirer or counsel can open with ordinary tools. Issues as JSON from the REST API and Confluence spaces as HTML cover most needs. Add a short readme explaining custom field names, status meanings and project keys, because nobody will remember them later.
The native tools also have limits worth planning around. Confluence Cloud's Backup manager stores only one backup file at a time, each new backup overwrites the last, and the download link lasts 14 days; Atlassian states a site backup can be up to 30 GB plus 800 GB of attachments and does not include soft-deleted spaces in the trash. Atlassian's Jira documentation describes the same one-file rule and allows a new backup only every 24 hours after the previous one finishes. Download each file to company storage as soon as it completes, restore any trashed spaces you need first, and split very large readable exports into batches.
Step-by-step: backing up before the site is deleted#
Backing up before the site is deleted is a short project with a hard end date, so work backward from the renewal or cancellation date and leave room for a second attempt if verification fails.
Plan for two rounds. Take a first full backup early to learn how long it runs and what breaks, then a final backup after the last issue is closed and the last page edited, so the archive reflects the end state of the site rather than a snapshot from mid-wind-down.
- Confirm who holds site and organization admin rights, and add a second admin who will stay through the wind-down.
- Freeze configuration changes and pause automation rules that edit, move or close issues.
- Inventory every Jira project, Confluence space and installed Marketplace app, with owners and record counts.
- Run the native Jira backup and the native Confluence backup with attachments included.
- Export a readable copy: issues with comments, links and changelogs as JSON, and key spaces as HTML.
- Export Marketplace app data through each app's own tools.
- Export the user directory so account IDs in the backup can be mapped to names and roles.
- Store everything in encrypted, company-controlled storage with checksums and an access list.
- Verify the archive against the live site, keep the verification record, and only then cancel.
What to set apart before anyone reviews the archive#
Some Jira projects and Confluence spaces should be set apart before anyone reviews the archive, even internally. Security vulnerability projects, HR and recruiting boards, legal matters, board materials and personal spaces carry risks that ordinary engineering history does not.
Service management projects need particular care. A Jira Service Management queue often holds customer messages, email addresses and pasted account details, which follow the customer contracts and any deletion obligations rather than the company's own records policy.
Mark set-apart material in the inventory with a reason and an owner. That record speeds up every later decision, whether the archive is kept for legal reasons, handed to an acquirer or assessed for licensing.
Illustrative: a freight visibility software company winds down#
Illustrative: a fictional freight visibility software company is winding down after its main product is discontinued. It runs Jira Software for engineering, Jira Service Management for customer support and Confluence for specs and postmortems, plus a time-tracking app from the Marketplace.
The CTO adds a second organization admin, pauses automation and runs both native backups with attachments. A script pulls every issue with comments, links and changelogs into JSON, and engineering spaces are exported to HTML. Time-tracking data comes out through the app's own export, and a readme maps custom fields and project keys.
The first verification fails: one project's count is short because an archived project was hidden from search. The team restores its visibility, re-exports and matches the counts. Service desk projects go into the customer deletion plan, while engineering projects and postmortems are kept as company records the board may assess later.
How SourceX treats Jira and Confluence archives#
SourceX treats Jira and Confluence archives as some of the most informative records a software company holds, because issues linked to commits, reviews and releases show how real problems were solved. The fit check needs only metadata, such as projects, years of history and whether issues link to code, so it can run before the site is cancelled.
The archive stays in the company's own storage. If a package proceeds through the SourceX five-step transaction, preparation removes personal and customer details, and the SourceX Evidence Packet records provenance and release authorization for exactly what was approved.
Frequently asked questions
Can we restore a Jira backup after the original site is gone?
Usually, by creating a new Atlassian site or a supported self-managed instance and importing the backup, subject to whatever version and format compatibility Atlassian supports at the time. That is why a readable export next to the native backup matters: it opens without buying or configuring anything. On Premium or Enterprise plans, Atlassian Backup and Restore can take scheduled backups, but they sit in Atlassian-owned storage for 30 days, so they do not replace a copy the company holds.
Should we export Jira to CSV or JSON?
Use both, for different readers. CSV suits a quick review in a spreadsheet but flattens comments, links and history. JSON from the REST API keeps nested comments, link types and changelogs intact, which matters for later analysis, migration or a licensing review. The native backup stays the authoritative copy.
Who should keep the archive after the company closes?
Whoever the board or the wind-down plan names as records custodian, often a remaining officer or the wind-down officer. The custodian needs the storage credentials, encryption keys, the readme and the list of set-apart projects, plus written instructions on retention and eventual deletion.
Do we need to keep user accounts and email addresses?
Keep enough to map account IDs in the backup to people and roles, because the history is hard to interpret without it. Store that mapping separately with tighter access, and remove personal details from any copy that leaves the company, such as a licensing package.
Is Bitbucket or GitHub history part of this backup?
No. Code repositories and pull request reviews live in the code host and need their own archive. Jira issue keys in commit messages and branch names connect the two, so archive both and keep the keys intact so the connection survives. If the team once used Bitbucket Cloud's legacy issue tracker, note that Atlassian announced its removal on August 20, 2026, with issues exportable as a zip file, and check whether that history still exists.
Sources
- Atlassian states that cancellation takes effect at the end of the billing period, the site remains accessible for 15 more days after the subscription period ends before deactivation, and unsubscribing from all Jira products on a site deletes the Jira data immediately. Source
- A Confluence Cloud site backup download link is available for 14 days, only one backup file is stored at a time, a backup can be up to 30 GB plus 800 GB of attachments, and soft-deleted spaces in the trash are not backed up. Source
- Jira Cloud's Backup manager allows a new backup every 24 hours from the time the previous one finished and stores only one backup file at a time. Source
- Atlassian Backup and Restore requires a Premium or Enterprise plan and stores backups in Atlassian-owned storage for 30 days. Source
- Atlassian announced that the Bitbucket Cloud issue tracker and wiki would be removed on August 20, 2026, with issues exportable as a zip file. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.