If your organization still relies on Jira, Confluence, or other Atlassian Data Center products, the announcement is probably already on your radar. Atlassian has confirmed that Data Center will reach end of life on March 28, 2029. From that point onward, these products will no longer operate as they do today.
2029 may sound distant, but the choice ahead is difficult to postpone indefinitely. And moving directly to cloud is not the only path available.
In practice, there are three main directions: migrate, delay, or leave Atlassian altogether. Below, we look at each option, including its advantages, limitations, and the situations where it may make sense. The goal is not to push you toward one answer, but to give you enough context to choose confidently.
What is happening, and when?
Data Center is not disappearing on a single date. Atlassian is phasing it out over several years, which gives customers time to prepare while also introducing earlier deadlines that affect what they can still purchase or expand.
The key dates are:
- December 16, 2025 – New Data Center apps can no longer be added to the Atlassian Marketplace.
- March 30, 2026 – New customers can no longer purchase Data Center licenses.
- March 30, 2028 – Existing customers can no longer purchase new licenses, add apps, or expand their current setup.
- March 28, 2029 – Data Center reaches its final deadline. Licenses expire and instances become read-only.
The read-only state is particularly important. After March 28, 2029, your information remains viewable, but users will no longer be able to create tickets, edit pages, or move work through existing workflows. For an actively used system, that effectively means operations stop.
There are also a few exceptions. Bitbucket Data Center is not included in this timeline and will instead transition to a hybrid license. Atlassian will also continue providing critical security fixes until 2029, while limited extended support may be available afterward on an exception basis.
The practical point is that 2029 is not the only date that matters. Your flexibility already starts narrowing in 2026 and again in 2028. If you expect to grow your Data Center environment or introduce additional apps, those decisions need to account for the earlier deadlines as well. Mapping them against your internal roadmap now can prevent unwanted restrictions later.
Option 1: Move to Atlassian Cloud
For many organizations, Atlassian Cloud is the most obvious destination. Atlassian is concentrating new product development there, while infrastructure and day-to-day server maintenance are handled for you.
It is also worth noting that Atlassian Cloud is not a single environment. There are currently three main options:
- Commercial Cloud – the standard shared environment intended for most organizations.
- Government Cloud – designed for U.S. public-sector organizations with strict compliance requirements.
- Isolated Cloud – a dedicated, single-tenant environment for organizations with demanding security or data-control needs. In this context, “single-tenant” means your environment operates separately from those of other customers.
Cloud migration brings several clear benefits. New capabilities are typically delivered there first, infrastructure can scale without you managing it directly, and your team no longer needs to maintain its own servers.
The main trade-off is the work required to get there. A migration commonly takes between three and twelve months, with more complex environments often falling in the six-to-nine-month range. Your team will also need to assess whether existing apps and customizations can move cleanly. Some apps already provide cloud versions, while others may require a replacement or a change in how a workflow is implemented. Discovering those gaps early is far easier than encountering them midway through a migration.
This is therefore better treated as a project than as a simple technical switch. The path is established, though. Atlassian offers migration tooling for smaller environments and more hands-on programs for larger organizations, and many teams have already gone through the same transition.
Option 2: Postpone the migration
Delaying can be reasonable, provided it is a deliberate decision. Your organization may already have its budget committed, another major initiative may take priority, or you may be waiting for a particular cloud feature or Marketplace app to become available.
Those can all be valid reasons to adjust the timing. The important question is what waiting actually gives you.
In most cases, delay does not create more choices. It reduces them. As the deadline gets closer, your negotiating room decreases and the eventual migration has to happen within a tighter window. Marketplace apps illustrate this clearly: because new Data Center apps are already frozen, postponing the decision will not give you access to additional tools. It simply keeps you dependent on the environment you already have.
Relying on a future exception is also risky. Extended support beyond 2029 is limited and evaluated case by case.
For that reason, it is more useful to think of delay as deciding when to move during the remaining window, rather than as a way to avoid moving indefinitely.
Option 3: Consider alternatives to Atlassian
Some organizations may need to ask a broader question: should they remain with Atlassian at all?
There are alternatives, including other project and service-management platforms, self-hosted open-source tools, and European sovereign-cloud providers for organizations with particularly strict data-residency requirements.
Moving away from Atlassian may be appropriate if your organization chose Data Center primarily because it needed full on-premises control and none of Atlassian’s cloud offerings can satisfy your legal obligations.
The cost of leaving, however, should not be underestimated. Your current environment may contain years of workflows, automations, integrations, and established user habits. Replacing Atlassian means recreating much of that structure and retraining the people who depend on it. It is significantly more involved than exchanging one software product for another.
There is also an important issue for organizations focused on sovereignty. Even Atlassian’s most isolated cloud environment remains subject to U.S. law. If complete legal data sovereignty is a non-negotiable requirement, a fully local provider may ultimately be the only suitable option. That does not automatically make it the best choice, but it is a legitimate factor that should be evaluated carefully.
How can you choose the right path?
There is no universal answer. A ten-person startup and a regulated bank can reasonably reach very different conclusions. The following five questions can help narrow down the most suitable path:
- How demanding are your security and data requirements? Strict requirements may lead you toward Isolated Cloud or, in uncommon cases, a local provider.
- How dependent are you on Marketplace apps? The more important those apps are to your workflows, the earlier you should confirm whether equivalents exist on your target platform.
- How heavily customized is your current environment? Extensive customization generally increases migration effort regardless of the destination.
- What budget and timeline do you have available? These constraints influence whether you migrate immediately or approach the transition in stages.
- Do you have enough internal resources to manage the work? If not, a migration partner can take on a substantial portion of the process.
There is no single correct response to these questions. What matters is answering them accurately. Taken together, they can quickly reveal whether migration, postponement, or departure from Atlassian is the more realistic option.
A note for teams focused on security and compliance
Organizations that remained on Data Center because of security, privacy, or regulatory requirements deserve particular attention.
There is a certain irony here. Many of the teams most reluctant to adopt cloud are the same teams that stayed with Data Center precisely because standard cloud environments did not satisfy their requirements. For a long time, that was a legitimate obstacle.
The situation has changed. Atlassian built Isolated Cloud specifically for this type of organization. Each environment operates separately from other customers. By default, data is prevented from leaving the environment, and customers can retain control of their own encryption keys.
There is still an important limitation to consider. The number of apps available for Isolated Cloud remains smaller because each app must be rebuilt specifically for that environment. If your workflows depend on particular apps, checking their availability early should be part of your migration planning. This is also why the Marketplace-app question above matters. At the same time, more vendors (including DevSamurai) are actively developing Isolated Cloud versions of the tools these organizations rely on.
Your next step
The main point is simple: the deadline is fixed, but rushing is not the answer. A last-minute migration in 2028 would be one of the least desirable outcomes. A planned, controlled transition that begins early gives you far more flexibility.
You do not need to make every decision immediately. What you do need is a clear understanding of your current environment.
Start by auditing what you already have: the number of users, the apps you depend on, your customizations, and your key integrations. Once those pieces are documented, it becomes much easier to determine whether your best route is to migrate, delay, or move away from Atlassian.
Approach the transition gradually. The timeline still gives you room to plan, and your available options are broader than they may initially appear.
