5 Atlassian Cloud migration realities most teams discover too late

From app portfolio strategy to stakeholder alignment, here's what consistently separates smooth migrations from difficult ones. 

TL;DR

• Atlassian Cloud is where Atlassian is investing: in AI, automation, and the features your teams will rely on next. The move is worth making, and how you plan it determines how smoothly it goes.
• Atlassian Data Center reaches end of life on March 28, 2029. Most enterprise migrations take 12 to 24 months, which means the window to move on your own terms is narrowing.
• The five realities most teams discover too late: apps need assessment far earlier than most teams start, the right migration team is bigger than IT, lift-and-shift migrations arrive in Cloud with the same problems they left with, timelines are almost always longer than expected, and communication is a project dependency rather than an afterthought.
• Each one is manageable if you plan for it early enough.

Atlassian has officially set March 28, 2029 as the end-of-life date for all Data Center products. After that date, instances go read-only, security patches stop, and new capabilities stop coming. New license sales for new customers already ended in March 2026. For organizations still running Jira, Confluence, or Jira Service Management on Data Center, migration isn't a question of whether. It's a question of when, and how to do it without disrupting the teams and workflows that depend on these tools every day.

That "how" is where migrations get complicated.

Maybe app testing surfaced incompatibilities nobody expected. Maybe the pilot migration revealed how many critical workflows were quietly depending on third-party Marketplace apps. Maybe the migration hasn't officially started yet, even though March 2029 keeps getting closer every quarter.

That's not a failure of effort. It's what happens when organizations underestimate what a migration actually involves. And it's more common than most teams expect.

Most enterprise migrations take 12 to 24 months to complete. That math leaves less runway than it looks like.

The good news: these aren't surprises for teams that plan for them. From working with enterprise Atlassian customers migrating complex app portfolios, we consistently see the same gaps come up. Here are the five realities most teams discover too late, and what to do about each one.

Reality 1: App assessment almost always starts too late

This is one of the most common and costly realities enterprise teams face. It's also the hardest to recover from once execution has started.

Many enterprise organizations running Atlassian Data Center products have dozens of third-party Marketplace apps supporting Jira, Confluence, and Jira Service Management. These aren't add-ons. They're the layer of your environment that supports how teams track work, manage SLAs, report on capacity, and connect your Atlassian tools to the rest of your business. When you migrate to Atlassian Cloud, every one of those apps needs to be individually assessed.

One of the biggest surprises for enterprise teams is how much migration complexity sits inside Marketplace apps rather than the core instance. Not every Data Center app has a Cloud equivalent. Some Cloud versions exist but behave differently. Some have feature gaps that affect workflows your teams depend on every day — including:

• ScriptRunner automations and custom scripts
• Confluence macros embedded across thousands of pages
• Assets and Insight dependencies
• JSM request types and portal customizations
• Integrations with Salesforce, SAP, and identity providers

And since December 2025, Atlassian stopped accepting new Data Center app submissions, which means the Cloud Marketplace is where all new development and innovation is happening now.

The real problem isn't that teams skip app assessment. It's that they do it too late, often not until the test migration phase, when they're already deep in execution. In some migrations, app validation alone has taken longer than migrating the core instance. By that point, there's very little room to adjust course.

By the time most teams assess their apps, they're already too deep in execution to course-correct.

What experienced teams do differently

Start your app assessment during the assessment and inventory phase, before your migration plan is locked. Map your apps to your key workflows. Identify Cloud equivalents early, flag feature gaps, and build app-specific testing into your timeline.

This is also the right moment to bring your app vendors in directly. They know their products' Cloud behavior better than anyone. They can flag known issues, advise on feature parity, and support your testing process in ways that Atlassian's native tooling simply can't.

It's also worth approaching this as an opportunity, not just a checklist. Migration is the moment to evaluate whether your current app portfolio is still the right one, and whether there are Cloud-native apps that could help your teams work better than what you had in Data Center. Many organizations arrive in Atlassian Cloud with a stronger, leaner app stack than they left with.

That approach pays off. When Verisk migrated more than 5,000 users to Atlassian Cloud, the central challenge wasn't the core data migration. It was maintaining continuity across a broad set of Marketplace apps and integrations that teams across the business depended on every day. By treating app strategy as a first-class part of migration planning, rather than something to address later, Verisk completed the move ahead of schedule and under budget.

Atlassian's Cloud Migration Assistant generates a compatibility report for your current app portfolio. That's a useful starting point. But it won't tell you how a Cloud app performs in your specific environment. That requires hands-on testing.

If you're not sure where to begin, Appfire's app assessment resources can help you inventory your Marketplace apps, map them to key workflows, and identify Cloud readiness gaps before migration planning is locked.

Reality 2: Your migration team is probably missing critical voices

Cloud migration is an organizational initiative, not an IT project. The organizations that treat it like one are the ones that struggle most.

The migrations that go smoothest are the ones where the full ecosystem comes together early. That means three groups:

• Internal stakeholders from IT, security, finance, knowledge management (Confluence), service management (JSM), compliance, governance, enterprise architecture, and identity and access management teams
• Atlassian as a partner in the migration process, particularly for guidance on Cloud readiness and platform-specific considerations
• An Atlassian Solution Partner to support technical planning, execution, and risk mitigation
• App vendors who can speak to Cloud readiness, testing requirements, and feature parity for each tool in your portfolio

The internal stakeholders organizations most commonly bring in too late, and that most frequently create bottlenecks, are:

Identity and access management teams. Atlassian Access setup, SSO migration, domain verification, SCIM provisioning, and user consolidation are not minor technical tasks. In organizations dealing with multiple identity providers or recent mergers and acquisitions, these steps are often on the critical path. One delayed SSO migration has stalled an otherwise ready cutover for weeks. Getting your identity team involved at the planning phase, not the execution phase, is what prevents that.

Service management leaders. JSM environments often have the most complex app dependencies, portal customizations, and workflow configurations in the Atlassian stack. Without JSM ownership represented in migration planning, these gaps surface late.

Governance and compliance teams. Permission model redesign, data residency requirements, and audit trail continuity are decisions that need owners before migration begins. These are not questions to resolve during testing.

The vast majority of enterprise organizations enlist a Solution Partner to support their migration. The complexity goes well beyond what most internal IT teams are set up to own alone, especially when you factor in custom workflows, dozens of apps, and cross-functional dependencies.

One important note: Atlassian's Fast Shift program is a valuable accelerant for getting core data migrated. But it's designed to handle the infrastructure layer, not the full complexity of your app portfolio or the specific way your business operates.

The earlier you bring partners in, the more flexibility you have in sequencing, in decision-making, and in choosing the right people for your environment. Solution Partners with deep migration experience are in demand, and that demand will grow as 2029 approaches.

What to prioritize early

Start your Solution Partner conversations now, while you have options. Get app vendors engaged during the planning phase, not at test migration. Build a team that includes every stakeholder who will be affected, and clarify everyone's role before execution begins.

The organizations that migrate early move on their own terms.

Reality 3: A lift-and-shift migration lands you in Cloud with the same problems

Here's what a "lift and shift" migration actually gets you: you pay the full cost of migration and arrive in Atlassian Cloud with the same technical debt, unused apps, redundant configurations, and legacy workflows you were trying to leave behind.

Atlassian Cloud opens capabilities that weren't possible in Data Center: automation at scale, AI-powered features through Atlassian Intelligence, modern integrations with the rest of your SaaS stack. This is the moment to think about how your teams should work, not just where your data lives.

But you can only take advantage of that opportunity if you go into migration with a clear picture of what you actually need to carry forward, and what decisions you need to make about how your Cloud environment will be structured.

The cleanup problem

Before your migration snapshot, do the honest audit:

In practice, this means retiring inactive Marketplace apps, consolidating duplicate workflows built up through years of acquisitions, cleaning up thousands of unused custom fields, closing out legacy JSM projects, and deleting abandoned Confluence spaces. It's not uncommon for an assessment to surface thousands of custom fields that nobody owns and nobody uses. Each one is a small piece of complexity that migrates anyway if nobody makes the decision to remove it. These are real cleanup activities that migration teams spend months on, and every one of them is easier to address before the migration than after.

Migrating less, intentionally, means a faster migration, a lower cloud bill, and a cleaner environment on day one.

The environment strategy problem

Lift-and-shift thinking also shows up in how organizations plan their Cloud environment structure. Moving to Atlassian Cloud isn't just relocating data; it's a design decision.

Key questions to answer before migration planning is locked:

• One Cloud site or multiple? Business units that operated independently on separate Data Center instances need a deliberate decision about coexistence in Cloud.
• How will permission models be redesigned? Cloud's permission architecture differs from Data Center. Carrying over legacy permission schemes without review introduces both security risk and user friction.
• What happens to duplicate projects, spaces, and configurations accumulated across years or acquisitions?
• What's the future operating model? Who owns and governs the Cloud environment, and how will it be managed differently from Data Center?

Organizations that spend time on these questions during planning, not during execution, move faster and have fewer surprises at go-live.

How to avoid this

Treat the pre-migration phase as a required design phase, not optional prep. Audit what you're carrying forward, make deliberate decisions about your Cloud environment structure, and define what "better" looks like, not just what's familiar.

For a practical walkthrough of the pre-migration cleanup process, the Configuration Manager for Jira (CMJ) pre-migration guide covers how to approach environment assessment and app rationalization before your migration begins.

Reality 4: Enterprise migrations take longer than almost everyone expects

Most enterprise organizations take 1 to 2 years to complete a cloud migration. Most of them go in expecting it to take six months.

That gap is where projects fall apart. Based on what we see working with enterprise organizations across the Atlassian ecosystem, here's why the timeline is longer than it looks:

Assessment and inventory: (months 1–3) Audit your current environment: apps, integrations, workflows, users, data volume, security requirements. This phase takes longer than most teams expect because most teams have never fully mapped their own Jira, Confluence, or JSM instance.

Migration planning: (months 3–6) Define your approach, sequence, and risk mitigation strategy. Engage your Solution Partner and app vendors. Build your test plan. Align stakeholders on timeline and impact.

Preparation: (months 6–9) Configure your Cloud environment. Prepare app migrations. Run cleanup activities and finalize your approach before testing begins.

Testing: (months 9–12) Test app compatibility. Run trial migrations. Validate data integrity. Identify and resolve issues before they reach production.

Execution and validation: (months 12–18+) Run your production migration. Validate outputs. Resolve issues. Support teams through the transition and into post-migration optimization.

For an 18-month enterprise migration, the front-loaded phases (assessment, planning, and preparation) typically account for the majority of total project time, according to industry research on enterprise migration timelines. Organizations that invest most heavily in those early phases consistently have fewer problems when execution begins. The ones who rush to execution are the ones who end up extending it.

The March 2029 deadline sounds like a long runway. For a complex enterprise environment, if you factor in the time needed to find and engage the right partners, it isn't.

What successful migrations have in common

They front-load planning. If your realistic execution window is mid-2028, your planning phase should be starting now. Build in a buffer too. Not because you expect things to go wrong, but because things sometimes do, and having space to recover beats having to scramble.

Reality 5: Migration communication is a project dependency, not a soft skill

Every team that relies on Jira, Confluence, or Jira Service Management every day will feel this migration. Developers, service desk agents, project managers, finance teams, ops leads — they all have workflows that live inside your Atlassian environment, and they all have a stake in how the transition goes.

Teams can tolerate change. They struggle with surprises.

Service desk teams may need entirely new escalation workflows in Atlassian Cloud. Finance teams may lose access to legacy reporting structures they've relied on for years. Developers may see workflow changes tied to Cloud app limitations they didn't know existed until go-live. Knowledge workers may have a new process or app for moving a document through approvals. When those teams find out about changes after the fact, you spend weeks managing confusion and workarounds that a solid communications plan would have prevented entirely.

Migration communication isn't a soft skill. It's a project dependency.

How to avoid this

Before migration planning is finalized, identify every team that will be affected. For each group, clarify:

• What changes for them specifically
• When they need to know about it
• What actions, if any, they need to take
• Who their point of contact is during and after the transition

Build your communications plan in parallel with your technical plan, not as an afterthought once the hard work is done. The teams who are most prepared for the transition are the ones who experience the least disruption.

The window to migrate on your own terms is closing

There are still thousands of organizations that need to complete their migration before March 2029. The ones that start planning now have something the late movers won't: flexibility — to choose the right partner, set a realistic pace, and treat the migration as an opportunity to modernize, not just relocate.

Appfire helps enterprise teams assess Marketplace app readiness, identify compatibility gaps before they become production problems, and optimize app spend as part of the migration process. Whether you're evaluating app parity, consolidating your portfolio to reduce Cloud costs, planning phased migrations, or validating workflows before go-live in Atlassian Cloud, we've worked through these challenges across hundreds of enterprise Atlassian environments.

Frequently asked questions

Q: What happens after Atlassian Data Center end of life in March 2029? 

A: After March 28, 2029, Data Center product subscriptions and their associated Marketplace apps expire and become read-only. That means no new security patches, no support, and no access to the AI, automation, and collaboration capabilities Atlassian continues to build exclusively for Atlassian Cloud. Organizations that migrate before the deadline get to move on their own timeline, with the partner of their choice, at a pace that works for their teams, and with the full Atlassian Cloud feature set available from day one.

Q: How early should enterprises start planning an Atlassian cloud migration? 

A: Most enterprise organizations need 12 to 24 months to complete a migration when you account for app assessment, planning, testing, and execution. If your environment includes dozens of third-party apps, complex custom workflows, or a large user base, you should be in active planning now. Organizations that wait until 2027 or 2028 will face a much more competitive market for Solution Partners and migration support resources.

Q: Do all my Jira apps work in Atlassian Cloud? 

A: Not automatically. Some Data Center apps have direct Cloud equivalents that work seamlessly. Others have Cloud versions with different feature sets. And some apps don't have a Cloud version at all, meaning you'll need to find an alternative or adjust your workflows before you migrate. The key is assessing your app portfolio early, during the planning phase, so you have time to test, make decisions, and avoid surprises during execution. Atlassian's Cloud Migration Assistant is a good starting point for a compatibility overview — but for the most accurate picture of how an app will behave in your specific environment, go directly to the app vendor. They have the deepest knowledge of their product's Cloud behavior, known limitations, and migration path, and most are eager to support customers through the transition.

Q: What's the difference between Atlassian Cloud and Data Center? 

A: Both platforms run Jira, Confluence, and Jira Service Management, but they're built and maintained differently. Data Center is hosted on your own infrastructure, giving you full control over your environment. Atlassian Cloud is hosted and managed by Atlassian, with continuous updates, built-in security, and exclusive access to newer capabilities like Atlassian Intelligence, advanced automation, and AI-assisted features. Atlassian's product investment is now concentrated in Cloud — which is why Data Center is reaching end of life in March 2029 and why most organizations are planning their move now.