In brief
Atlassian Data Center will reach end-of-life on March 28, 2029. The first restriction has already taken effect: as of March 2026, no new DC licenses can be sold to new customers. For an Atlassian admin who manages their instance alongside other responsibilities, the real challenge isn’t “why migrate” but “how to avoid having to handle this alone, on short notice, between sprints.”
The biggest risk of an Atlassian Cloud migration isn’t the technical complexity. It’s starting too late to have the option to do it right.
We’ve been supporting migrations since the Atlassian Ascend program was announced. And the pattern we see most often isn’t that the team underestimates the technical difficulty. It’s that the team knows exactly what it needs to do—and even has a clear vision of its instance—but keeps putting off getting started because day-to-day tasks always take priority.
The result: we end up launching the project in 2027 or 2028, with less time for testing, fewer available partners, and a transition window that we no longer really get to choose. The migration still takes place, but under conditions that could have been avoided.
This guide isn’t meant to convince you that migrating is a good idea. You already know that. It’s here to help you structure the project so that it remains manageable, even when you don’t have a dedicated team to carry it out.
Atlassian Data Center Roadmap: Key Dates to Know Before 2029
The end-of-life schedule for the Data Center has been set:
|
Date |
Event |
Status |
|
March 30, 2026 |
Sales of new DC licenses to new customers have ended |
Past |
|
March 30, 2028 |
End of renewals and extensions for existing customers |
Coming Soon |
|
March 28, 2029 |
Full end-of-life: read-only instances; no further support or patches |
Coming Soon |
Here’s the key point: if you don’t have a team dedicated to this project, the migration won’t happen as a “six-month task force.” It will have to be integrated into an already busy daily routine. That’s precisely why starting now, rather than in 2027 or 2028, makes all the difference.
Migrating Jira and Confluence to the cloud is probably easier than you think
The scary scenarios described in case studies—environments with tens of thousands of projects, hundreds of critical ScriptRunner scripts, and integrations with five different business systems—are environments that have grown over the course of ten years with dedicated teams.
What causes these migrations to go awry is not technical complexity, but a lack of preparation in three specific areas.
The Three Mistakes That Can Derail an Atlassian Data Center to Cloud Migration
1. Marketplace apps that were not reviewed prior to the migration
This is the area that causes the most last-minute surprises. Having an app available in the cloud does not guarantee functional parity with your data center version. And most importantly: application data, custom field values controlled by an app, and configurations stored on the plugin side do not migrate using native Atlassian tools. Each vendor has its own migration path—and some don’t have one at all.
The first thing you should do now is launch Portfolio Insights from admin.atlassian.com. It’s free, available to all Atlassian organizations, and it gives you a complete overview of your app portfolio and their Cloud status. Do this before you plan anything.
2. Inactive user accounts that were not cleaned up before the migration
The Data Center licensing model is based on the number of authorized users. The Cloud, on the other hand, bills per active user. Migrating without first cleaning up inactive accounts—such as former employees and contractors whose assignments have ended—leaves you at risk of paying for users who no longer have any role in your instance.
The simple rule: Export your user list along with last login dates, cross-reference it with HR data, and deactivate accounts that have been inactive for more than 90 days before migrating. This cleanup reduces your cloud costs and improves your governance at the same time (source: miniorange.com).
3. A poorly planned switchover window
Jira is often at the heart of day-to-day operations. A poorly planned switchover during a busy period—such as the end of a sprint, a release, or a closing period—can cause disruptions that your support team struggles to handle when it’s already stretched thin.
Identify your “offseason”: a period of low activity—ideally a long weekend or a vacation period—when the migration window minimizes the impact on teams. Plan several dry runs before the actual switchover. This isn’t optional—it’s what makes the difference between a smooth migration and one that generates support tickets for three weeks.
Need advice on choosing the right Atlassian tools?
Every organization has specific needs. Our certified Atlassian experts analyze your current business processes, identify opportunities for automation, and recommend the optimal Atlassian architecture for your needs. Contact us!
Benefits of Atlassian Cloud: What Migration Actually Offers You
Beyond the time constraints, the migration to Atlassian Cloud delivers real operational benefits.
Less infrastructure administration. No more server maintenance, no more infrastructure updates to schedule. For an admin who manages Atlassian on top of everything else, that means time saved on low-value tasks.
Security managed at the platform level. Atlassian Cloud is ISO 27001, SOC 2, and GDPR compliant. Atlassian Guard provides threat detection, data loss prevention, and centralized audit logging—cloud-only features that previously required manual configuration in Data Center.
Immediate access to new features. Rovo, Atlassian’s AI assistant, advanced automation, new interfaces—it’s all coming to the Cloud. Staying on Data Center means accepting a feature gap that widens every quarter.
Atlassian Cloud Migration: Should You Hire a Partner or Handle It In-House?
For a simple setup—with few apps, few integrations, and a dedicated team—an in-house migration using Atlassian’s native tools is entirely feasible.
But there are signs that external support really does change the equation:
- Your Atlassian admin cannot devote more than 20% of their time to the project
- You have five or more Marketplace apps with critical business dependencies
- Do you have integrations with third-party systems (HRIS, CRM, CI/CD tools)?
- You’ve never done an Atlassian migration before
- You need assurance that your data and workflows will be preserved
In these cases, the cost of an error, data loss, a broken workflow, or failed adoption far exceeds the investment in structured support.
SQORUS, Atlassian Silver Solution Partner: Our Approach to Cloud Migration
SQORUS is an Atlassian Silver Solution Partner. Our certified consultants support Data Center-to-Cloud migrations using an approach that always begins with an audit of the existing environment before making any changes.
What this means for you:
- An honest assessment of your system: mapping your apps, identifying real risks, and estimating the workload. We won’t make any promises about a timeline until we’ve taken a look under the hood.
- A plan tailored to your constraints: we structure the project so that the internal workload remains manageable, with clear milestones and a well-chosen transition window.
- Full migration of your workflows, permissions, and automations: You move to the cloud with your instance already up and running, not with an environment that needs to be reconfigured.
- Training your teams: Your users will know what’s changing and why before the switchover, not after.
- Post-migration support: The first few weeks in the cloud are when questions tend to come up. We’re here to answer them.
Our consultants work on both technical configuration and business practices (ITSM, Agile, project management, ESM), which eliminates the need for back-and-forth communication when a migration decision affects both administration and team processes.
Conclusion: Migrating from a Data Center to the Cloud—Choose Your Timeline Before It’s Imposed on You
Migrating to Atlassian Cloud isn’t a project you can just jump into overnight. But it’s also not a project reserved only for teams that have six months to spare and a dedicated task force.
Successful migrations all have one thing in common: they begin by cleaning up the Data Center instance before touching anything else. Inactive projects, obsolete workflows, duplicate permission schemes, ghost user accounts, and unused Marketplace apps.
An instance that has been cleaned up before migration arrives in the cloud in a stable, well-managed state, ready to scale. An instance migrated “as-is” carries its problems into a new environment, and those problems are often more visible and more costly to fix once in the cloud.
What makes the difference next is preparation. Launch Portfolio Insights to map out your apps. Clean up your inactive users before migrating. Choose your migration window rather than being forced into one. Three concrete actions you can take right now that will radically change what happens next.
You still have a comfortable window of time ahead of you. Not indefinite, but comfortable. Organizations that begin planning in 2026 can afford to take things in order: assessment, plan, dry runs, and a controlled transition. Those that wait until 2028 will have to migrate under pressure, with fewer partners available and less leeway to handle unforeseen issues.
The question isn’t “Should I migrate?” You already know the answer to that. The question is “Do I want to choose how to do it, or wait for it to be imposed on me?”
Start with an assessment. In just one session, we’ll tell you exactly what your migration entails!
All about IT project governance
Discover the roles and responsibilities of key profiles, as well as best practices in governance and technological development, to ensure the success of your digital transformation projects.
A project? A request? Any questions?
FAQ – Migrating Atlassian Data Center to the Cloud
What is the deadline for migrating from Atlassian Data Center?
The official end-of-life date for Atlassian Data Center is March 28, 2029. On that date, all Data Center instances will switch to read-only mode: no actions will be possible (creating tickets, updating pages, running workflows).
There are two interim deadlines to keep in mind:
- March 30, 2028, the deadline to renew or extend your existing Data Center licenses,
- and March 30, 2026—which has already passed—when sales of new licenses to new customers ended.
How long does it take to migrate from Atlassian Data Center to Cloud?
The duration depends on the size and complexity of your instance. For environments with 200 to 500 users, a few Marketplace apps, and limited integrations, a well-planned migration takes 7 to 12 weeks to complete.
For more complex environments, with numerous integrations or custom scripts, the timeline may extend to several months. In any case, the preparation phase (audit, cleanup, dry runs) determines the duration and quality of the migration.
What happens to my Marketplace apps during the migration to the cloud?
Marketplace apps do not migrate automatically. Each app has its own migration path, defined by its publisher. Some apps have a Cloud version with full feature parity, others have limitations, and some do not have a Cloud version at all. App data (custom field values, plugin-side configurations) is not handled by Atlassian’s native tools: it is up to each publisher to provide a migration path for their data. The Portfolio Insights tool (admin.atlassian.com) lets you map out your entire app portfolio and assess their Cloud compatibility before you begin.
Will my workflows and automations be preserved after the migration?
Native Jira workflows and standard automation rules are migrated using the Jira Cloud Migration Assistant (JCMA). However, ScriptRunner scripts (post-functions, listeners, and behaviors written in Groovy) are not directly compatible with the Cloud architecture and must be evaluated and, in some cases, rewritten.
Cloud-native automation has evolved significantly and now covers a large portion of the use cases that previously required scripting in the data center. An audit of your automation workflows before migration helps identify what can be carried over as-is, what needs to be reworked, and what can be replaced by a native rule.
How much downtime should be expected during the switchover?
The duration of downtime depends on the volume of data and the migration method chosen. For a standard “lift-and-shift” migration, a window ranging from a few hours to a weekend is generally sufficient for instances of a reasonable size. Since 2026, Atlassian has offered a cloud-hosted migration assistant in early access, which enables incremental transfers and significantly reduces downtime during the final switchover. Scheduling the switchover during a period of low activity (weekends, holidays) remains the best way to minimize the impact on teams.
Should we migrate Jira and Confluence at the same time?
No, and it’s actually recommended to migrate them separately. The rule to follow: migrate Jira before Confluence. If you do the opposite, users imported from Jira during the subsequent import will overwrite the user data already in Confluence Cloud. Migrating both products simultaneously increases complexity and the risk of incidents. A sequential approach, with full validation of Jira before starting Confluence, is safer and easier to manage.
What is the difference between Atlassian Cloud Standard, Premium, and Enterprise?
The three Cloud plans differ primarily in their advanced features and administrative capabilities. Standard covers common use cases with limits on automations and storage. Premium adds advanced features (advanced roadmaps, archiving, analytics, priority support) and higher automation quotas. Enterprise is designed for organizations with complex governance needs: multiple instances, centralized administration, enhanced SLAs, and Atlassian Guard included. The choice of plan depends on your number of users, your automation needs, and your compliance requirements. An audit of your current usage will help you choose the right plan without overpaying.
