Atlassian Data Center EOL: What Enterprises Should Prepare Now
28 March 2029. That is the date Atlassian Data Center reaches end of life.
Two and a half years away, which is why in most organisations this sits on the "look at it next year" list. But if you plan around that date alone, you will be late. The dates that actually constrain an administrator are different ones, and one of them has already passed.
There are three dates, not one
Atlassian's Data Center end-of-life announcement has three milestones.
| Date | What happens |
30 March 2026 (passed) | New customers can no longer purchase Data Center subscriptions or Marketplace Data Center apps.
|
30 March 2028
| Existing customers can no longer purchase new Data Center subscriptions or Marketplace apps, or expand existing subscriptions. Existing subscriptions can still be renewed at the current user count. |
28 March 2029
| All affected Data Center subscriptions and Marketplace app licenses expire and go read-only. Technical support ends the same day |
All three fall at 23:59 PST. Through 28 March 2029 Atlassian continues to provide technical support, security fixes for critical vulnerabilities, and Data Center to Cloud connectors.
In scope: the Data Center editions of Jira Software, Jira Service Management, Confluence, Bamboo and Crowd, their companion mobile apps, and third-party Marketplace apps for those products. Bitbucket Data Center is not in scope. Existing Bitbucket Data Center customers will instead gain access to a Bitbucket Hybrid License covering both Data Center and Cloud.
The real deadline is not 2029
The more important date to plan around is 30 March 2028.
After March 2028 you cannot grow your licence. If the organisation expands, an acquisition adds users, or a new business unit picks up Jira, there is no lever to pull. Staying on Data Center while headcount grows stops being an option on 30 March 2028.
Now work backwards through the constraints that actually govern a change like this.
Budget cycles — most enterprises lock the next fiscal year one or two quarters ahead. To execute a migration in 2028, the line item has to be in the 2027 budget, and that conversation starts in the first half of 2027.
Security and legal review — in regulated industries, cloud approval can add months to the timeline.
The migration itself — large or complex instances often require multiple rounds of testing, validation and cutover planning. Heavy app dependencies can stretch the timeline further.
Change freezes — you cannot touch the system during close, peak season or audit windows. The usable window is narrower than the calendar suggests.
Stack those four in sequence and the practical starting line for an unhurried organisation is early 2027. Count the time in front of that line, not the time to 2029.
The work to do now is cleanup, not migration
This is not a call to open a migration project tomorrow. There is a set of work that pays for itself regardless of when you move.
1. Count your real users.
The user count on the licence and the user count that actually signs in are rarely the same. Leavers, contractor accounts from finished projects, and accounts nobody has touched in years all sit in there. Cloud is priced per user, so moving without cleaning up means paying every year for people who left.
2. Define what "inactive" means.
Ninety days without a login, or one hundred and eighty? Does a manager confirm, or is the licence reclaimed automatically? Without that definition, cleanup turns into a series of individual judgement calls and never finishes. Writing the rule down and getting it approved once matters more than the cleanup itself. The goal is not just a one-time cleanup before migration, but a repeatable licence governance policy that works on Data Center today and continues after you move to Cloud.
3. Inventory your app dependencies.
Third-party Marketplace apps are in scope for end of life. For each installed app, establish whether a Cloud version exists, whether it is functionally equivalent, whether there is an alternative, or whether you can drop it. This is a common reason migration projects slip.
4. Settle your data requirements early.
Data residency, audit trail retention, access control model. Confirming what security and legal will ask for now prevents losing months right before cutover.
5. Review your space and project structure. Users are not the only thing that moves. Confluence spaces and Jira projects come too. Migrate abandoned spaces and ownerless projects as they are, and you arrive in the new environment with the same problem you had in the old one.
What these five have in common is that none of them depend on when you migrate. They reduce cost and operational load while you are still on Data Center. And when the migration does start, a significant part of the preparation is already done.
Three things people get wrong
"Nothing changes until 2029." It does. License expansion stops in March 2028. If headcount is going to grow, the decision has to come before then.
"Our apps aren't Atlassian's, so this doesn't apply." Third-party Marketplace app licences installed on in-scope products expire on 28 March 2029 as well.
"Security patches will stop first." Technical support and security fixes for critical vulnerabilities continue through 28 March 2029. For most customers, after that the products become read-only, so doing nothing until then is not really a strategy.
Look at the dates again. 28 March 2029 is an end date, not a target date. The target is 30 March 2028, and once you work back through budget and review cycles, preparation starts in early 2027.
There is also work you can do before you reach that starting line. Clean up users and licenses, map app dependencies, confirm data requirements. None of it requires having decided to migrate — and doing it first tends to make the decision easier.
How is your organization scheduling this? I would be curious to know when the budget conversation starts on your side.
Sources
Atlassian Data Center EOL: What Enterprises Should Prepare Now
28 March 2029. That is the date Atlassian Data Center reaches end of life.
Two and a half years away, which is why in most organisations this sits on the "look at it next year" list. But if you plan around that date alone, you will be late. The dates that actually constrain an administrator are different ones, and one of them has already passed.
There are three dates, not one
Atlassian's Data Center end-of-life announcement has three milestones.
30 March 2026 (passed)
30 March 2028
Existing customers can no longer purchase new Data Center subscriptions or Marketplace apps, or expand existing subscriptions. Existing subscriptions can still be renewed at the current user count.
28 March 2029
All three fall at 23:59 PST. Through 28 March 2029 Atlassian continues to provide technical support, security fixes for critical vulnerabilities, and Data Center to Cloud connectors.
In scope: the Data Center editions of Jira Software, Jira Service Management, Confluence, Bamboo and Crowd, their companion mobile apps, and third-party Marketplace apps for those products. Bitbucket Data Center is not in scope. Existing Bitbucket Data Center customers will instead gain access to a Bitbucket Hybrid License covering both Data Center and Cloud.
The real deadline is not 2029
The more important date to plan around is 30 March 2028.
After March 2028 you cannot grow your licence. If the organisation expands, an acquisition adds users, or a new business unit picks up Jira, there is no lever to pull. Staying on Data Center while headcount grows stops being an option on 30 March 2028.
Now work backwards through the constraints that actually govern a change like this.
Budget cycles — most enterprises lock the next fiscal year one or two quarters ahead. To execute a migration in 2028, the line item has to be in the 2027 budget, and that conversation starts in the first half of 2027.
Security and legal review — in regulated industries, cloud approval can add months to the timeline.
The migration itself — large or complex instances often require multiple rounds of testing, validation and cutover planning. Heavy app dependencies can stretch the timeline further.
Change freezes — you cannot touch the system during close, peak season or audit windows. The usable window is narrower than the calendar suggests.
Stack those four in sequence and the practical starting line for an unhurried organisation is early 2027. Count the time in front of that line, not the time to 2029.
The work to do now is cleanup, not migration
This is not a call to open a migration project tomorrow. There is a set of work that pays for itself regardless of when you move.
1. Count your real users.
The user count on the licence and the user count that actually signs in are rarely the same. Leavers, contractor accounts from finished projects, and accounts nobody has touched in years all sit in there. Cloud is priced per user, so moving without cleaning up means paying every year for people who left.
2. Define what "inactive" means.
Ninety days without a login, or one hundred and eighty? Does a manager confirm, or is the licence reclaimed automatically? Without that definition, cleanup turns into a series of individual judgement calls and never finishes. Writing the rule down and getting it approved once matters more than the cleanup itself. The goal is not just a one-time cleanup before migration, but a repeatable licence governance policy that works on Data Center today and continues after you move to Cloud.
3. Inventory your app dependencies.
Third-party Marketplace apps are in scope for end of life. For each installed app, establish whether a Cloud version exists, whether it is functionally equivalent, whether there is an alternative, or whether you can drop it. This is a common reason migration projects slip.
4. Settle your data requirements early.
Data residency, audit trail retention, access control model. Confirming what security and legal will ask for now prevents losing months right before cutover.
5. Review your space and project structure. Users are not the only thing that moves. Confluence spaces and Jira projects come too. Migrate abandoned spaces and ownerless projects as they are, and you arrive in the new environment with the same problem you had in the old one.
What these five have in common is that none of them depend on when you migrate. They reduce cost and operational load while you are still on Data Center. And when the migration does start, a significant part of the preparation is already done.
Three things people get wrong
"Nothing changes until 2029." It does. License expansion stops in March 2028. If headcount is going to grow, the decision has to come before then.
"Our apps aren't Atlassian's, so this doesn't apply." Third-party Marketplace app licences installed on in-scope products expire on 28 March 2029 as well.
"Security patches will stop first." Technical support and security fixes for critical vulnerabilities continue through 28 March 2029. For most customers, after that the products become read-only, so doing nothing until then is not really a strategy.
Look at the dates again. 28 March 2029 is an end date, not a target date. The target is 30 March 2028, and once you work back through budget and review cycles, preparation starts in early 2027.
There is also work you can do before you reach that starting line. Clean up users and licenses, map app dependencies, confirm data requirements. None of it requires having decided to migrate — and doing it first tends to make the decision easier.
How is your organization scheduling this? I would be curious to know when the budget conversation starts on your side.
Sources
Data Center End of Life | Atlassian
Reminder: Upcoming changes to Data Center products | Atlassian Community