Software companies
Atlassian Data Center end of life: what to do with Jira and Confluence history
By SourceX Editorial · Updated
Short answer
Atlassian Data Center end of life means self-managed Jira and Confluence are being retired on a phased schedule Atlassian has published, so each Data Center customer must move to cloud, move to another tool or keep an archive. Whichever path you choose, take a full historical export first, including change history, attachments, app data and user mappings.
Key takeaways
- Read Atlassian's official end-of-life announcement for the dates and conditions that apply to your licenses, then plan backward from the final milestone.
- A migration moves only what you choose and your tools support; closed projects and old spaces left behind vanish when the old server is switched off.
- Take a restore-tested export of the database, attachments, app data and user mappings before any cleanup.
- Issue change history and page versions are the parts of Jira and Confluence that a scoped-down migration most often drops and that auditors, acquirers and AI developers later ask for.
What has Atlassian announced?#
Atlassian has announced that its Data Center products will reach end of life on a phased schedule as it moves customers to its cloud platform. The schedule separates milestones such as the end of new sales and the final end of support, and the exact dates and conditions in Atlassian's announcement may differ by product and license.
Dates are not restated here because Atlassian's announcement is the source of record and its conditions can vary. Read the official end-of-life page, confirm the details with your Atlassian account team or partner, and work backward from the final milestone. The date that matters for planning is the one after which your instance stops receiving fixes, not the one when sales end.
The focus here is Jira and Confluence. If you also run Bitbucket or other Atlassian products on Data Center, check the announcement for each of them, because their history is linked to the issues and pages discussed below. Any instance still on Atlassian's older Server products is already past end of support, which makes its export more urgent still.
| Milestone type | What it means | What to do |
|---|---|---|
| End of new sales | New Data Center purchases stop | Confirm your current license terms and renewal date |
| Interim milestones | Conditions for renewals or expansions may change; check the announcement | Choose a target: cloud, another tool or archive |
| End of support | No security fixes or technical support | Finish the migration and the archive before this point |
| After end of life | Running the instance becomes an unsupported risk | Keep, at most, an isolated archive |
What moves in a migration, and what gets left behind#
A migration moves what you choose to migrate and what your tools support, which is rarely everything. Teams moving to cloud often leave closed projects and old spaces behind to reduce scope and user counts, and teams moving to another tool often carry only open work. Whatever stays on the Data Center server disappears when that server is switched off.
Some history is at risk even inside migrated projects. Data stored by Marketplace apps depends on whether each app vendor supports migration. Links to other self-managed systems, such as a code host or CI server, may point nowhere afterward. Former employees' work can lose its attribution if their accounts do not map cleanly.
| Record | Why it matters | What to check before migrating |
|---|---|---|
| Issue change history | Shows every status, assignee and field change over time | Whether your path carries full history or only current values |
| Comments and worklogs | Hold the discussion and effort behind each issue | Completeness for closed and archived projects |
| Attachments | Logs, screenshots and specs tied to issues and pages | Size limits and broken links after the move |
| Confluence page versions | Record how decisions and designs changed | Whether old versions and page comments carry over |
| Marketplace app data | Test cases, time tracking, diagrams and checklists | Each app vendor's migration support |
| Development links | Connect issues to commits, pull requests and builds | Whether links survive if the code host also moves |
| Users and groups | Attribute work to people and teams | Mapping for deactivated and former employees |
| Audit logs | Show administrative changes and access | Whether they need a separate export |
Take a full historical export first: a checklist#
A full historical export, taken before any cleanup or migration, is the one step that keeps every later option open. It is small work next to the migration itself, and it cannot be recreated once the server is gone.
Secrets deserve a specific pass. Engineers paste credentials into Confluence pages and Jira comments more often than anyone admits, and scanners such as TruffleHog state that they cover wikis and chats as well as Git, so scan the export before anyone outside the core team handles it.
- Back up the database and the attachment store from the Data Center instance, and record the product versions.
- Where instance size allows, also run the built-in Jira and Confluence backup exports alongside the database dump.
- Export Marketplace app data using each app vendor's instructions.
- Save the user directory mapping, including deactivated accounts, in restricted storage.
- Export audit logs and configuration: workflows, custom fields, schemes and automation rules.
- Record development links to commits, pull requests and builds.
- Scan the export for secrets pasted into pages and comments, and rotate anything found.
- Restore the export to an isolated test instance and spot-check projects and spaces.
- Write down what was excluded and why, with the date of the export.
Where should the archive live?#
The archive should live somewhere you can read it without the original server, under your own control. Each option trades cost against how easy the history will be to use later.
Many teams keep two: a raw database and attachment backup for completeness, and a structured export of the projects and spaces they expect to use. The structured export is what a new engineer, an auditor or a rights reviewer will actually open.
| Archive option | Strengths | Weaknesses |
|---|---|---|
| Frozen Data Center instance on an isolated network | Familiar interface for lookups | Unsupported software, license questions and security upkeep |
| Database dump and attachments in cold storage | Complete and inexpensive to hold | Needs a matching product version to read |
| Structured export files with an index | Readable by any tool and easy to scope | Takes effort to build and verify |
| Archived projects inside the new cloud site | Searchable next to current work | Ongoing subscription cost and possible migration gaps |
Why Jira and Confluence history is worth keeping#
Jira and Confluence history is worth keeping because it records how a software company actually decided and built things. Issue change histories link reports to fixes and releases, and Confluence page versions show designs and decisions changing as teams learned.
Those same records are what auditors and acquirers ask for in diligence, and what AI developers look for in issue resolution histories and design documents. A migration plan that treats closed projects as clutter can quietly discard the most useful years of that record.
Illustrative: a logistics software company chooses cloud plus archive#
Illustrative: a fictional logistics software company runs Jira, Confluence and Bitbucket on Data Center. Its Jira instance holds many closed projects from a retired route-planning product, and Confluence holds years of design docs and incident reviews.
The CTO decides to migrate active projects to cloud and leave the retired product behind. Before anything moves, the team takes a database and attachment backup, exports the retired product's projects and spaces to structured files with full change history, saves the user mapping in restricted storage and restore-tests the backup.
The cloud subscription covers only active work. The retired product's history stays in the company's own storage, and the CEO later has it reviewed as a possible license of records from a discontinued product.
How SourceX treats Jira and Confluence archives#
SourceX treats an exported Jira and Confluence archive the same way as a live system: the fit check asks for metadata only, such as which projects and spaces exist, how many years they cover and whether issues link to code. Archives from retired instances can qualify, and large exports stay in the company's own storage or ship on encrypted drives.
Provenance matters more for archives, so the SourceX Evidence Packet records which instance the records came from, when and how they were exported and what was excluded, alongside licensing rights, permitted use, the privacy record and release authorization.
Frequently asked questions
Can we keep running Data Center after end of life?
Check Atlassian's terms for what your license permits after the final milestone. Even where an instance keeps running, it will receive no security fixes, so treat it as an isolated, read-only archive at most, with no connection to the internet or to production systems.
Do we need to migrate closed projects?
No. Closed projects can be archived outside the new platform, which keeps them available without paying to carry them. What matters is that they are exported with full change history and attachments before the old server is retired.
What happens to records from former employees?
Their issues, comments and pages remain, but their accounts are often deactivated and may not map cleanly in a migration. Save the user mapping before the move so work can still be attributed, and treat that mapping as personal data with restricted access.
Should we move to a different tool instead of Atlassian Cloud?
That is a product and cost decision, but it raises the stakes for the export. Moves to other tools often carry less history, such as fewer field changes or no app data. A full export first means the choice of destination does not decide what history survives.
Is a database dump enough as an archive?
It is complete but hard to use. Reading it later needs a compatible product version and some engineering effort. Pair it with structured exports of the projects and spaces you expect to need, and document how both were produced.
Sources
- TruffleHog, an AGPL-3.0 open-source secret scanner from Truffle Security, scans sources including Git, chats, wikis, logs, object stores and filesystems. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.