What is the Data Center end-of-life timeline?
Atlassian announced the end of Data Center in 2024. Unlike the earlier Server end-of-life, which let customers keep running unsupported instances indefinitely, Data Center has a hard shutdown. Instances go read-only on the EOL date.
The timeline has three milestones:
- March 30, 2026: No new Data Center subscriptions or marketplace app purchases for new customers. Existing customers can still renew and expand. No new features after this date, only critical security patches.
- March 30, 2028: Last day for existing customers to renew Data Center licenses, buy new apps, or expand user tiers. After this date, no commercial transactions for Data Center products.
- March 28, 2029: End of life. All Jira, Confluence, Bitbucket, and JSM Data Center instances transition to read-only. No exceptions, no extensions, no unsupported self-hosting option.
This affects every Data Center product: Jira Software, Jira Service Management, Confluence, Bitbucket, Crowd, and all marketplace apps. The marketplace apps follow the same timeline because their licensing is tied to the Data Center platform.
Why this is different from the Server end-of-life
When Atlassian ended Server in February 2024, customers could keep running their Server instances indefinitely without support. The software still worked. Many government programs chose to accept the risk and continue running unsupported Server instances rather than migrate.
Data Center does not offer that option. The read-only cutoff is enforced through licensing. When the license expires, the instance locks. There is no workaround, no community fork, no way to keep running Data Center software past March 2029.
This matters for government programs because the planning horizon for a platform migration in a federal environment is typically 12 to 18 months when you account for procurement, security authorization, data migration, user training, and parallel operation. Teams that wait until 2028 to start planning will be under severe time pressure.
What is Atlassian Government Cloud?
Atlassian Government Cloud is Atlassian's offering for U.S. government customers. It achieved FedRAMP Moderate authorization in March 2025, covering Jira, Confluence, and Jira Service Management.
FedRAMP Moderate covers the majority of federal civilian agency use cases. It satisfies NIST 800-53 Moderate baseline controls and allows processing of controlled but unclassified information at lower sensitivity levels. For many programs, FedRAMP Moderate is sufficient.
Atlassian has committed to pursuing FedRAMP High authorization and Impact Level 5 (IL5) compliance on their roadmap, though no firm dates have been published. FedRAMP High would cover high-impact systems and is required by some defense and intelligence community programs. IL5 authorization would allow processing of CUI and National Security Systems data in DoD environments.
Atlassian is also developing Atlassian Isolated Cloud, expected in 2026, which provides additional isolation for enterprises managing sensitive data. This is a separate offering from Government Cloud.
What should government teams evaluate right now?
The first step is understanding your compliance requirements precisely. Not what you assume they are, but what the contract, the ATO boundary, and the data classification actually require.
If your program processes only unclassified, non-CUI data and your agency accepts FedRAMP Moderate, Atlassian Government Cloud is the straightforward path. Atlassian is investing in migration tooling and dedicated migration support through their Ascend program. For organizations under 1,000 users, self-service tools are available. Over 1,000 users qualifies for the FastShift Program with dedicated migration support.
If your program handles CUI, IL4 or IL5 data, or operates in a classified environment, Atlassian Government Cloud is not yet an option. FedRAMP High and IL5 are on the roadmap but have no published dates. For these programs, the question is whether to wait for Atlassian to achieve those authorizations or to begin evaluating alternative platforms now.
Waiting carries risk. If FedRAMP High arrives in 2027, that leaves less than two years to migrate before DC goes read-only. If it slips to 2028 or later, the window closes entirely. Programs with strict compliance requirements should be evaluating alternatives in parallel, even if the preferred outcome is staying on Atlassian.
What are the alternative platforms for government teams?
Several platforms serve the project management and service management space for government customers at higher compliance levels.
GitLab is self-hosted and available on government infrastructure. It covers issue tracking, CI/CD, and project management in a single platform. GitLab has a FedRAMP authorization for its SaaS offering and the self-managed version can be deployed in any environment the customer controls.
GitHub Enterprise Server is self-hosted with strong issue tracking, project boards, and CI/CD through GitHub Actions. GitHub's cloud offering has FedRAMP authorization. The self-managed version runs on customer infrastructure.
ServiceNow has FedRAMP High authorization and IL5 deployment options. It covers ITSM, project management, and workflow automation. ServiceNow is a common choice for programs that need both project management and IT service management in a single compliant platform.
Microsoft Azure DevOps is available in Azure Government (IL5 authorized) and covers project tracking, repos, pipelines, and boards. For programs already on the Microsoft stack, this is often the path of least resistance.
Open source options like Redmine, Taiga, or OpenProject can be self-hosted on any infrastructure. They lack the ecosystem depth of commercial tools but satisfy the requirement for data sovereignty and can run in any environment including air-gapped networks.
The platform choice depends on what you actually use Jira for. If the primary use case is agile project management and issue tracking, most alternatives cover that well. If you are heavily invested in JSM service desks, Confluence knowledge bases, and marketplace app integrations, the migration scope is larger and the alternatives may require more customization.
How to plan the migration
Regardless of the destination, the migration planning process follows the same structure.
Start with a complete inventory of your current Data Center environment. Document every project, every automation rule, every marketplace app, every integration, every permission scheme, and every custom field. You cannot scope a migration without knowing what you have. Most teams undercount their automations and integrations by 30 to 50 percent because some were set up years ago and nobody remembers them.
Classify your data. Know exactly what data classification levels exist in your Jira instance. If you have been running mixed-classification data in a single instance, you may need to split projects across different target platforms based on classification.
Evaluate target platforms against your actual requirements, not the vendor feature matrix. Set up a pilot with your two most complex projects and see what breaks. Automations never port cleanly between platforms. Custom fields require mapping. Integrations need to be rebuilt.
Build the migration timeline backward from March 2029. Allow 12 to 18 months for a full migration with parallel operation. That means migration planning should start no later than late 2027 for a comfortable timeline, and earlier is better. If your target platform requires a separate ATO, add 6 to 12 months for the security authorization process.
Budget for dual licensing during the parallel operation period. You will be paying for Data Center and the new platform simultaneously for at least two to four months, possibly longer. This is a real cost that procurement needs to plan for.
Open source migration tooling
If you are planning a migration from Jira to GitLab or another platform, the migration-kit project on GitHub provides open source tooling for the full lifecycle. It includes scripts to extract issues from Jira DC or Cloud with full metadata (comments, attachments, links, custom fields), transform them into the target platform format, import into GitLab with labels and state mapping, and validate the results with automated count and spot-check verification.
The toolkit also covers Jira DC to Cloud migrations, ServiceNow to JSM, and other ITSM platform moves. For the CMDB and Assets portion of a migration, the companion cmdb-kit project provides schema-as-code patterns and JSM Assets adapters.
FAQ
Q: What happens to our data after Data Center goes read-only? A: Your data remains in the instance in read-only mode. You can still access and export it, but you cannot create or modify records. Atlassian has not announced a date when read-only access ends, but you should plan to have your data fully migrated before the March 2029 deadline, not after.
Q: Can we keep running Data Center without a license after EOL? A: No. Unlike Server, Data Center instances enforce license validation. When the license expires, the instance goes read-only. There is no unsupported self-hosting option.
Q: Should we wait for Atlassian Government Cloud to get FedRAMP High? A: If your program requires FedRAMP High, you can monitor Atlassian's roadmap, but you should evaluate alternatives in parallel. Depending on a single vendor's future authorization for a migration with a hard deadline is a risk that should be documented and accepted at the program level, not assumed away.
Q: What about Atlassian Isolated Cloud? A: Atlassian Isolated Cloud is a separate offering designed for enterprises with additional data isolation requirements. It is expected to launch in 2026 but is distinct from Government Cloud and its compliance posture is still being defined. It may serve some government use cases but should be evaluated on its own merits once available.
Q: How does this affect marketplace apps? A: Marketplace apps follow the same Data Center EOL timeline. Cloud versions of the same apps may exist but often have different feature sets, different pricing, and different APIs. Some Data Center marketplace apps have no Cloud equivalent at all. Audit your app dependencies early.
Q: What is Atlassian's Ascend program? A: Ascend is Atlassian's migration support program. Under 1,000 users get self-service migration tools. Over 1,000 users qualify for FastShift, which provides dedicated migration support and claims to reduce migration timelines from 12 to 16 months down to 2 to 6 months. Over 5,000 users get Solution Design Acceleration with additional strategic support. The program is designed to move customers to Cloud, not to alternative platforms.
Q: Our contract requires data to stay on government-controlled infrastructure. What do we do? A: If your contract mandates government-controlled infrastructure and Atlassian Government Cloud does not meet that requirement at its current authorization level, your options are self-hosted platforms (GitLab, GitHub Enterprise Server, Azure DevOps in Azure Government, or open source tools) or renegotiating the infrastructure requirements with the contracting officer if Cloud hosting with appropriate FedRAMP authorization would satisfy the intent.