Software companies
Atlassian Data Center end of life for Marketplace app vendors: timeline and options
By SourceX Editorial · Updated
Short answer
Atlassian Data Center end of life means Marketplace app vendors must decide, app by app, whether to port to cloud, sunset, sell or keep a support-only version until the final date. Plan against the milestones in Atlassian's published schedule, not memory, and export your Data Center support, bug and licensing records before you shut anything down.
Key takeaways
- Vendor milestones can arrive before customer milestones, such as any cutoff Atlassian sets for new Data Center app listings.
- Treat each app as a separate decision; a portfolio of Data Center apps rarely deserves one answer.
- Porting to cloud is usually a rebuild, because cloud apps run on a different architecture and security model.
- A Data Center app with a loyal install base can be sold to another vendor rather than retired.
- Archive support tickets, bug history and release records before cancelling the tools that hold them.
What Data Center end of life means for an app vendor#
Atlassian Data Center end of life means the self-managed Jira, Confluence and related products your apps extend are being retired on a phased schedule Atlassian has published, and each phase removes a source of Data Center revenue. Customers lose new purchases first, then renewals, then support, and your Marketplace income follows the same curve.
Atlassian's developer blog and partner communications are the source of record for the dates, and the conditions can differ by product and license type. This guide does not restate them; pull the current dates into your own plan and recheck them each quarter, because schedules and conditions can change.
For a vendor, the end of life is not one decision but several: what to do with each app, what to promise customers in the meantime and what to keep from years of Data Center operations.
Milestones to plan against#
The milestones to plan against are Atlassian's dates plus the dates you set for your own apps. Fill in the second column from Atlassian's official announcement and agree the fourth column internally.
| Milestone | Date from Atlassian's announcement | What changes for vendors | What to have done by then |
|---|---|---|---|
| Any cutoff for new Data Center app listings | Check Atlassian's developer blog and partner notices | New Data Center listings or versions may be restricted | Decided which apps you will still maintain |
| End of new Data Center sales | Check the official end-of-life page | Only existing customers can buy or extend | Pricing and messaging for existing customers |
| Last renewals and license extensions | Check partner communications | Data Center revenue stops growing | Customer notices and support end dates set |
| Final Data Center end of life | Check the official end-of-life page | Atlassian support ends | Your own end-of-support date announced |
| Your record archive deadline | Set internally, before any tool is cancelled | Exports become harder after cancellation | Support, code and licensing records exported and verified |
Four options for each Data Center app#
Each Data Center app has four realistic options: port it to cloud, sunset it, sell it or keep it in support-only mode until the final date. The right answer depends on the app's install base, how much of its value survives a cloud rebuild and whether a cloud equivalent already exists.
Many vendors mix options across their portfolio. A flagship app is ported, a niche app with loyal customers is sold to a vendor that specializes in maintenance, and a small utility is sunset with a clear notice.
| Option | Fits when | Main cost | What happens to records |
|---|---|---|---|
| Port to cloud | Customers are migrating and the core feature works in cloud | A rebuild on Atlassian's cloud platform | Data Center history stays as reference for the rebuild |
| Sunset | Few customers and no viable cloud equivalent | Notice, refunds where owed, support until the end date | Archive before tools are cancelled |
| Sell to another vendor | A stable install base with steady renewals | Diligence and a listing transfer | Transfer or copy, as the sale agreement sets out |
| Support-only until the final date | Customers will stay on Data Center to the end | Engineers kept on old code | Keep collecting, then archive at the end |
Why porting is usually a rebuild, not a migration#
Porting a Data Center app to cloud is usually a rebuild because cloud apps run outside the host product, call published APIs and pass Atlassian's cloud security requirements. Features that relied on direct database access, server-side hooks or file system access often need a different design or cannot be reproduced at all.
Customers moving from Data Center to cloud also need their app data moved. Plan the data migration path as carefully as the app itself, and document which settings, history and configuration will not survive, so support teams can answer questions before migration weekends rather than during them.
Price the rebuild honestly against the cloud install base you expect. A port that recovers only part of the Data Center audience may still be worthwhile, but the decision should be made with numbers from your own Marketplace reporting.
Archive Data Center records before you cancel anything#
Data Center records, including support tickets, bug reports, compatibility notes and licensing history, are the part of an app business that is easiest to lose. Vendors often run support desks, issue trackers and wikis on subscriptions that are cancelled as the app winds down, and cancellation starts deletion clocks.
Atlassian's documentation states that after a cloud site is deactivated, data is retained for 15 days on trials and 60 days on Free, Standard, Premium or Enterprise plans, and reactivating within that period restores it. Export before you cancel, not after. Atlassian also announced that the Bitbucket Cloud issue tracker and wiki would be removed on August 20, 2026, with issues exportable as a zip file or migratable to Jira, so check whether any public issue trackers for your apps lived there.
Large Jira exports need batching: Atlassian states that its asynchronous CSV export from the Jira Cloud issue navigator supports up to 10,000 work items and recommends splitting larger exports into JQL batches, for example by date range.
- Support tickets from Data Center customers, with internal notes and resolutions.
- Bug reports and feature requests, with links to the commits that addressed them.
- Source code, tags and release notes for every Data Center version you shipped.
- Compatibility matrices across host product versions and database platforms.
- Documentation and knowledge base articles, including retired versions.
- Marketplace licensing and transaction reports, kept within the limits of your partner agreement.
Selling a Data Center app to another vendor#
Selling a Data Center app to another vendor works when the app has a stable install base that will stay on Data Center for a while, or when the buyer already has a cloud equivalent and wants the customers. Buyers diligence renewal history, support load, code quality and how close the final end-of-life date is.
Transferring a Marketplace listing involves Atlassian's partner processes, so confirm the requirements early. Agree in the sale document who keeps the support history and customer communications, and whether you may retain a copy of your own engineering records for internal use.
Illustrative: a vendor with three Data Center apps#
Illustrative: a fictional Marketplace vendor sells a Jira time tracking app, a Confluence export macro and a Bitbucket merge check, all on Data Center. Its records sit in Jira Service Management for support, a self-managed GitLab instance for code and Confluence for documentation.
The vendor ports time tracking to cloud, because most of its customers are migrating. It sells the merge check to a vendor focused on development tooling, keeping a copy of its own engineering history under the sale agreement. It sunsets the export macro with notice, honoring support until the date it announced.
Before cancelling its support desk subscription, the team exports every Data Center ticket with internal notes, links tickets to the GitLab merge requests that fixed them and stores the archive in its own cloud storage with a written inventory.
How SourceX looks at a retired app's records#
SourceX looks at a retired app's records the same way as an operating product's: support conversations linked to bug fixes and releases can be useful to AI developers working on coding and support assistants. The fit check collects metadata only, such as record types, systems and years covered, and no files are shared.
The Rights step matters more than usual here. Support tickets for Atlassian apps often contain screenshots and pasted content from customers' own Jira or Confluence instances, which belong to those customers and are excluded or removed during preparation. The SourceX Evidence Packet records what was kept, what was removed and who authorized release.
Frequently asked questions
Can Data Center customers keep using my app after the final end-of-life date?
That depends on your license terms and the app's technical design. Some apps keep working on an unsupported instance; others depend on services you will shut down. Tell customers plainly what will stop, what will keep working and what support, if any, you will provide.
Should my end-of-support date match Atlassian's final date?
Not necessarily. You may need to stop earlier if a small install base cannot fund engineers, or you may offer support until Atlassian's final date to customers who renew. Whatever you choose, check existing contracts and announce it with enough notice for customers to plan.
Can I reuse Data Center code in a cloud app?
Business logic, algorithms and tests often carry over. Code tied to server-side APIs, the host product's database or file system usually does not. Expect to reuse ideas and some libraries, and to rewrite integration layers and the user interface.
Is the customer content in my support tickets mine to keep?
Not in the sense of owning it. Screenshots and pasted issues from customers' instances remain their information, governed by your terms and privacy commitments. Keep it only as long as your policies allow, and exclude it from any use beyond support.
What if a large customer refuses to migrate off Data Center?
Decide whether you will offer paid extended support, a code escrow or a source license, or simply honor your existing contract and stop. Put the decision in writing, because one customer's arrangement can become everyone's expectation.
Sources
- Atlassian's support documentation states that after a cloud site is deactivated, data is retained for 15 days for trials and 60 days for Free, Standard, Premium or Enterprise plans, and reactivating within this retention period restores the product's data and preferences. 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 or migratable to Jira and wikis exportable by cloning their separate repository. Source
- Atlassian states that exporting up to 10,000 work items using the asynchronous Export CSV feature from the Jira Cloud Issue Navigator is supported, and recommends splitting larger exports into JQL batches of fewer than 10,000 work items each. Source
Related resources
- InsightCan property management companies sell their data to AI companies?
- InsightCan e-commerce brands sell their data to AI companies?
- InsightCan call centers and BPOs sell their data to AI companies?
- SolutionData licensing: granting defined rights to use your data
- SolutionData monetization: earning revenue from data you already have
- IndustryBPO & contact centers data
See if your company qualifies
A short company assessment. No data uploads are needed.