Atlassian Data Center End of Life: What Happens to Search

Most of the writing about Atlassian ending Data Center is about the migration project: how long it takes, what it costs, which vendor will run it for you. Almost none of it is about what happens to the thing your employees actually touch every day, which is the search box. That is the part that tends to surprise people in month three, because content migration tools are good and configuration migration tools mostly do not exist.

This piece sticks to what Atlassian has published, and then to the search consequences that follow from it. If you are three years out and wondering whether this is urgent, the honest answer is that the deadline is not urgent and the planning is, for a reason that has nothing to do with 2029.

When is Atlassian Data Center end of life?

There are three dates, and conflating them is the most common mistake in the coverage. Taken from Atlassian's own licensing page:

Between now and the 2029 date, Atlassian says it will continue to provide technical support and security bug-fixes for critical vulnerabilities. What it does not promise is product development, which is the quiet part of the announcement: innovation happens in Cloud, so the gap between what your Data Center instance does and what Cloud does widens every quarter until 2029, whether or not you have moved.

Which Atlassian products are affected?

Jira Software Data Center, Jira Service Management Data Center, Confluence Data Center, Bamboo Data Center and Crowd Data Center, along with their associated Marketplace apps. Bitbucket Data Center is the exception; Atlassian is offering it a hybrid license instead of putting it on the same timeline.

The two that matter for internal knowledge are obviously Confluence and Jira, because between them they hold most of the written record of how a company works: the runbooks, the decisions, the incident history, the specs and the arguments about the specs.

What happens after March 28, 2029?

Atlassian's wording is that after your Data Center subscription expires, "your data will continue to be available in a read-only state. However, product updates and support will no longer be available." So this is not a shutdown that deletes anything, and there is no cliff where the servers stop. It is a slow freeze: your content stays where it is and stays readable, and everything around it stops moving.

Read-only has a specific consequence for search that is easy to miss. A frozen Confluence is still a place people look for answers, and it is now a place where nobody can correct anything they find. Documentation that was merely stale becomes permanently stale. If part of your estate ends up parked in read-only Data Center while active work moves to Cloud, you have quietly created two sources of truth, and the search problem gets harder rather than easier.

Can we still renew Data Center subscriptions?

Yes, up to a point. Renewals are permitted but cannot extend beyond March 28, 2029, and Atlassian prorates them where necessary. Practically that means a renewal signed in 2028 buys you a partial term rather than a full one, so the finance question and the engineering question converge somewhere in 2027 for most companies.

What happens to Confluence and Jira search when you migrate to Cloud?

The content comes across well. Atlassian's migration tooling has had years of investment and moves pages, attachments, issues, comments and history reliably. What does not come across is the layer your teams built on top of search, and that layer is usually invisible until it is missing.

Four things to inventory before you plan a date:

Saved filters and CQL. Confluence Query Language exists in both, but the queries your teams saved are tied to spaces, labels, users and custom fields whose identifiers change during migration. Anything embedded in a dashboard or a page macro needs checking one at a time. It is also worth knowing that CQL through the REST API is capped: Atlassian documents that searching for content with the REST API and CQL always returns a maximum of 50 results regardless of the limit parameter, so any internal tooling built on it is paginating whether the author realized it or not.

Archiving behavior. Atlassian states plainly that "In Confluence Server, you could archive a space to exclude pages in that space from search." Cloud handles archiving differently, at the page level as well as the space level. If your team used space archiving as a housekeeping tool to keep dead content out of results, that habit needs replacing rather than porting.

Marketplace search apps. Third-party apps that improved search, added federated results or built a better index are a separate migration each. Some have a Cloud equivalent, some have a different data model in Cloud, and some do not exist there at all. Because Marketplace apps are explicitly in scope for the same end-of-life timeline, a Data Center app that never gets a Cloud version is not a problem you can defer past 2029.

Permissions. Space permissions and issue security schemes migrate, but the mapping between your identity provider, your groups and the resulting access is the piece worth verifying by hand. Search is where a permissions mistake becomes visible, because search is what surfaces the document somebody should not have seen.

Is Cloud search better than Data Center search?

In several ways, yes, and it would be dishonest to pretend otherwise. Cloud search adapts to your recent activity and projects, and through Rovo it can pull in results from third-party tools like Google Drive and SharePoint, which is something no Data Center instance does. Rovo comes bundled in eligible paid Cloud plans rather than as a separate line item, with Chat and Agent usage drawing on monthly credit allowances. For a company that lives almost entirely inside Atlassian, that combination is a real upgrade and a genuine reason to move sooner rather than later.

The limit is scope. Rovo is very good at the Atlassian-shaped part of your world and increasingly capable at the edges of it, but the answer to a question like "what did we agree with this customer about the renewal" is frequently not in Confluence or Jira at all. It is in a Slack thread, an email, a Drive doc and a Salesforce note, and only one of those is somewhere Atlassian sits. That is the boundary to test during your migration pilot, not after it.

Should the migration change how you think about search?

It is a good moment to separate two problems that usually travel together. One is where your Atlassian instance runs, which is what the 2029 deadline forces you to decide. The other is whether people can find answers across every system your company uses, which the migration does not address in either direction. Companies routinely spend a migration budget and then discover the search complaint they had in 2025 is unchanged, because the complaint was never about Confluence hosting.

The useful test is to write down the last ten questions somebody asked in a team channel that should have had a documented answer, and mark where each answer actually lived. If most of them are in Confluence and Jira, migrating to Cloud and turning on Rovo will genuinely help. If most of them are spread across four systems, you are looking at a unified search problem, and moving Confluence from one data center to another does not touch it. The market for ready-made AI agents has grown fast enough that most teams now shop for one rather than build it, which is a reasonable route for narrow, repeatable workflows, though it is a different exercise from making the whole corpus searchable.

There is also a timing argument for doing the search work first. A migration is the one period when your teams are already auditing spaces, cleaning up permissions and deciding what to keep. Knowing which content actually gets searched, and by whom, makes those decisions much easier, and it is far cheaper to answer that before you move ten years of pages than after.

A practical sequence

Inventory your Data Center estate now, including Marketplace apps, and mark each app with whether a Cloud equivalent exists. Export the list of saved filters, dashboards and CQL-driven macros, since that is your real configuration backlog. Run a pilot with one large space and one busy Jira project, and compare search results before and after rather than assuming parity. Verify permissions against a handful of real people, not against the schema. Then set your date, working backwards from March 2028 if you might still need to expand your license, rather than from 2029.

If, along the way, the pilot shows that the questions people ask cross out of Atlassian more often than they stay inside it, that is worth knowing before you scope anything else. Search across Confluence, Jira, Slack, Drive, Notion and Gmail in one place is what InSearch does, with each person's existing permissions enforced at query time, and it works the same whether your Confluence is in Cloud or still on Data Center. The enterprise search tools comparison covers sixteen products if you want the wider view first.

The short version

Atlassian Data Center end of life is March 28, 2029, new sales to new customers ended March 30, 2026, and existing customers lose the ability to purchase new subscriptions on March 30, 2028. After the 2029 date, products and apps go read-only. Content migrates well; search configuration, saved filters, CQL macros and Marketplace search apps do not. Cloud brings a genuine search upgrade through Rovo for Atlassian-native content. Whether that solves your actual search problem depends entirely on how much of the answer lives outside Atlassian, and the migration pilot is the cheapest place to find out.