Two things changed for Atlassian customers in 2026: data contribution became a default rather than a choice, and the on-premises product line got a hard end-of-life date. This page is what those two changes actually say, in Atlassian own words, and what a replacement has to cover.
Atlassian began using customer data under its data contribution settings on 17 August 2026, according to its own documentation. Two classes of data are collected. Metadata covers derived signals such as readability scores, task classifications, story points, sprint dates, SLA values and Teamwork Graph similarity measures. In-app data covers the content itself: Confluence page titles and body text, and Jira work item titles, descriptions and comments, along with custom status and workflow names.
Retention is documented at up to seven years. If an organisation opts out, in-app data is removed within 30 days and the affected models are retrained within 90 days.
The part that decides the argument is not the collection. It is who is allowed to switch it off, and that differs by plan.
Atlassian documents carve-outs for customer-managed encryption keys, Atlassian Government Cloud, Isolated Cloud, and customers with HIPAA requirements. If you are on one of those, the default does not apply to you. If you are not, it does.
| Plan | Metadata contribution | In-app data contribution |
|---|---|---|
| Free / Standard | Cannot be changed | On by default; an org admin can turn it off |
| Premium | Cannot be changed | On by default; an org admin can turn it off |
| Enterprise | Can be turned off | Can be turned off |
Separately from the AI question, Atlassian has published an end-of-life schedule for its Data Center products. It is the more consequential of the two changes, because it is dated and it is not optional.
Bitbucket Data Center and Jira Align Data Center are exempt from the schedule. If your estate includes Jira and Confluence Data Center, the clock is running on both.
Most teams evaluating this are not replacing Confluence alone. They are replacing a wiki, a work tracker and the integrations between them, and the honest question is which of those you still need.
A project workspace with owners, statuses and dates is something ShimoDocs covers with tables and app sheets rather than a separate issue tracker. That is a different shape from Jira, and it is the right shape for a team that was using Jira as a shared task list rather than as a delivery pipeline. If you are running sprints, boards, epics and a release train, Jira is doing work no document platform replaces, and you should keep it.
Where a document platform is the right answer is the documentation half: a space per team, page trees, permissions inherited from the space, comments and suggestions on a page, a full page history, and search across all of it. That is the surface a wiki earns its place on.
The reason the August change is uncomfortable is not that a vendor wants to train a model. It is that the decision was made for you, on a tier you may not be able to change.
A self-hosted deployment inverts that. ShimoDocs runs in your own Kubernetes cluster, and the AI configuration layer points at a model endpoint you choose. On a self-hosted or isolated network that endpoint is a model inside your own boundary, so document context never becomes someone else training data. If you would rather switch AI off entirely, it is an addition to the suite rather than a dependency of it, and collaboration is unaffected.
One more difference is worth naming. An AI agent with delegated access to your wiki is an exfiltration path. In August 2026 two independent research teams disclosed indirect prompt injection paths in Atlassian Rovo, one of which was still unconfirmed as remediated at publication, and disabling the assistant web search did not close it because the tool that follows a dynamically constructed URL stayed available. The controls that do close it are architectural — the model inside your network, no outbound URL tool it can be talked into using, and every AI action written to your own audit log. Those are properties of where you deploy, not settings you toggle.
Confluence migration is a content problem before it is a technical one. Four things decide the schedule, and doing them in this order is what keeps the project from slipping.
Atlassian began using customer data according to its data contribution settings on 17 August 2026. In-app data such as Confluence page titles and body text is collected by default on Free and Standard plans, and an organisation administrator can turn it off. Metadata — derived signals such as readability scores, story points and sprint dates — is collected on every plan and cannot be disabled below the Enterprise tier.
Only on Enterprise. Atlassian documentation states that metadata contribution cannot be changed on Free, Standard or Premium. On those plans the setting is not a switch an administrator can reach. Atlassian also documents carve-outs for customer-managed encryption keys, Government Cloud, Isolated Cloud and customers with HIPAA requirements.
Atlassian published a hard end of life of 28 March 2029, after which the Data Center products are read-only and receive no further security fixes. New customers could not buy new Data Center subscriptions or Marketplace apps from 30 March 2026, and existing customers lose the ability to buy new subscriptions, apps or user expansions from 30 March 2028. Bitbucket Data Center and Jira Align Data Center are exempt.
It depends which half of Confluence you rely on. If you need page trees, space permissions, page history and search, a self-hosted document platform covers it. If you run sprints, boards, epics and a release train, that is an issue tracker and no document platform replaces it — keep Jira and move the documentation.
The content export is the fast part. The schedule is decided by permissions translation, attachment link repair and whether page history and comments survive. Draft the permission mapping table before any content moves, and test the import on your messiest space rather than your cleanest one.