Atlassian Data Center end of life is near: 10 cloud migration FAQs answered

A few months ago, Atlassian announced that all its Data Center products (barring Bitbucket and Jira Align) will reach end of life on March 28, 2029. After this date, you will no longer be able to use these Data Center products or related Marketplace applications.

This is a massive change that will affect thousands of organizations, even more than when Atlassian ended support for Server products in 2024. The move, however, is not unexpected. Like most major technology companies, Atlassian is doubling down on the cloud as AI capabilities become central to its platform and future roadmap.

You may have noticed the word near in the title. That choice isn’t clickbait but deliberate. Atlassian will not wait until 2029 to flip a switch and end support. The transition is already underway and will unfold in phases over the coming years.

If you’re a Data Center customer, this is a massive opportunity. Migrating to the cloud can dramatically accelerate your time-to-market while reducing infrastructure costs. It’s also a great way to fine-tune your internal workflows and align them to work with AI.

10 FAQs: How to migrate from Atlassian Data Center to Cloud

As a four-time Atlassian Partner of the Year, Modus Create has helped organizations such as Roblox and Dropbox successfully migrate to the cloud. In this blog, our experts answer the ten most common migration questions we have been asked since Atlassian announced its EOL of Data Center products.

1. When is the best time to perform a Data Center to Cloud migration?

Short answer: It’s sooner than you think.

While 2029 may seem far away, Data Center migrations, especially for larger environments, take time to plan and execute properly. App analysis, governance reviews, test migrations, and change management can span months. Rather than rushing into migration and then figuring out your workflows, it’s better to do the groundwork first.

Ideally, you should plan a migration at a time that will be least disruptive to business continuity. Just as a sports league wouldn’t roll out technical changes during a championship series, you don’t want to migrate during your busiest season.

So, when is your offseason? A lot of businesses shut down over the Christmas/New Year break and find that to be the best time to perform the cloud migration. For others, it’s the busiest time. To identify the best migration window:

• Review Jira Work Items (Jira tickets) to spot lower-activity periods
• Analyze Confluence page views to identify low-usage windows
• Align migration timing with fiscal planning cycles and contract renewals
• Account for internal change freezes or blackout periods

Finally, run multiple test migrations in a sandbox environment to establish a realistic duration estimate. These dry runs help determine how long data migration actually takes and whether a weekend window is sufficient, or if a longer phased rollout is the safer approach.

2. Should we migrate Jira before Confluence?

If you are migrating both Jira and Confluence to Cloud, we usually recommend migrating Jira first.

In many environments, Jira functions as the primary user directory and permission backbone. Migrating it first helps establish a consistent identity and access framework, reducing the risk of provisioning gaps or permission mismatches when Confluence is migrated later.

That said, every environment is different. The right migration sequence should be based on your identity architecture, integration dependencies, and overall application landscape.

3. How is Data Center to Cloud migration different from Server to Cloud migration?

Data Center to cloud migrations are typically more complex than Server to cloud migrations because Data Center environments are larger, more customized, and deeply integrated with enterprise systems. They usually include clustered nodes, load balancers, advanced SSO integrations, higher user volumes, and heavier Marketplace app usage, all of which increase migration complexity.

The migration approach also differs. Most Data Center migrations require phased execution, detailed app compatibility reviews, and multiple test migrations to validate performance. Server migrations, while still requiring planning, are often closer to straightforward lift-and-shift efforts due to simpler architectures and fewer dependencies.

So if you’re planning Data Center migrations, you need a longer preparation cycle, stronger alignment on governance, and closer coordination across IT, security, and business teams.

4. What should we do if information is missing after migration?

If you discover missing data or inconsistencies that can not be fixed as a post-migration activity during testing, it’s time to take a deep breath and go for a full reset.

Manually cleaning up information can be a huge pain and can introduce new variables, making it harder to reproduce the migration state later. If you encounter this, the best thing to do is to reset Confluence or Jira entirely. Here’s how to reset and delete all data from your Cloud site.

Three things you should do before a reset:

• Ensure you have created a Cloud site backup.
• Perform all testing in a sandbox environment.
• Document any errors encountered during the test run.

With these steps completed, you can safely perform the reset and continue testing without introducing additional migration risks.

5. Should we use the Jira Cloud Migration Assistant (JCMA)?

In most cases, yes. JCMA is Atlassian’s recommended tool for moving from Jira Data Center to Cloud. It is highly flexible, supporting project-by-project migrations and providing critical "App Assessment" insights to help you migrate data for supported Marketplace apps.

When should you look for alternatives?

While JCMA is the gold standard, it’s not a "one-size-fits-all" solution. You might consider alternative methods (like Site Import or CSV exports) or custom API scripts if:

• Unsupported entities: You need to migrate specific global configurations or data types that JCMA doesn't currently support (e.g., System dashboards or complex deep-level configurations).
• App limitations: Your "mission-critical" Marketplace apps do not yet have a migration path supported by JCMA.

Keep in mind that Jira Cloud Migration Assistant doesn’t migrate every piece of information. You can learn about what gets migrated and what doesn’t here.

6. Should we use the Confluence Cloud Migration Assistant (CCMA)?

Yes. CCMA should be your default migration method for Confluence Server or Data Center unless you have a specific requirement that calls for a custom approach. It allows you to assess Marketplace app readiness before migrating, run test migrations to validate results, and move spaces in controlled phases rather than all at once.

CCMA also includes built-in checks for common migration issues, user mapping support, and guided migration steps in one place. For most organizations, it serves as the foundation of the Confluence migration approach, supplemented by app-specific migration tools and phased rollout planning where needed.

7. How do we avoid security issues during Atlassian Data Center to Cloud migration?

Moving to the cloud is a good opportunity to review your entire governance model and make it simpler and more secure. Data Center instances often rely on network-level protections in addition to application-level permissions. When moving to the cloud, it’s important to review and tighten permissions before migration.

Here are a few ways to prevent past security issues from coming back to haunt you:

• Audit permission schemes to ensure no access is granted to “Anyone.”
• Review global permissions, including “Browse Users.”
• Identifying public dashboards, filters, and boards.
• Clean up inactive users and stale groups.
• Review group-to-project role mappings.

8. How does identity and access management change in the cloud?

Many Data Center customers use LDAP or Active Directory integrations with custom SSO solutions. In the cloud, you’ll handle identity management through Atlassian Access, which supports SAML SSO, SCIM provisioning, centralized user lifecycle management, and enforced authentication policies

Because identity becomes centralized at the organization level rather than managed per application, it is important to prepare before migration:

• Review and simplify group structures to avoid permission sprawl
• Remove inactive and duplicate accounts
• Define clear ownership for user provisioning and deprovisioning workflows
• Align Atlassian Access authentication policies with internal security standards
• Validate IdP mappings to ensure users are correctly matched during migration

9. How do we manage Atlassian marketplace apps during Data Center to Cloud migration?

Well, now you’ve come to the most challenging and complex part of the Data Center to cloud migrations. In many migrations, this bit takes longer than the actual migration itself!

Not every Data Center app has a direct Cloud equivalent. Some apps require reconfiguration, some need to be replaced with alternative Cloud-native solutions, and others may not be migrated at all. Before migration, create a complete app inventory, identify business-critical apps, and verify Cloud availability, feature parity, and migration paths for each one.

Where feature gaps exist, organizations typically address them by adopting replacement apps, redesigning workflows using native Cloud capabilities, or, in limited cases, building custom integrations to support critical processes.

10. How can we redirect old links after migration?

You can avoid huge post-migration headaches and improve the experience for users by using a proxy to redirect old links to new URLs. We’re sharing a sample configuration below. The purpose of this configuration is to demonstrate the ease of set-up.

Please note that the specifics in this section will depend on your deployment details.

Apache with mod_rewrite:

RewriteEngine On

# Jira legacy subdomain

RewriteCond %{HTTP_HOST} ^jira\.<company>\.com$ [NC]

RewriteRule ^(.*)$ https://<company>.atlassian.net/$1 [R=301,L]

# Confluence legacy subdomain

RewriteCond %{HTTP_HOST} ^confluence\.<company>\.com$ [NC]

RewriteRule ^(.*)$ https://<company>.atlassian.net/wiki/$1 [R=301,L]

This assumes that local Jira and Confluence were hosted on jira.<company>.com

Apache with RedirectMatch:

<VirtualHost *:80>

ServerName jira.<company>.com

RedirectMatch 301 ^/(.*)$ https://<company>.atlassian.net/$1

</VirtualHost>

<VirtualHost *:80>

ServerName confluence.<company>.com

RedirectMatch 301 ^/(.*)$ https://<company>.atlassian.net/wiki/$1

</VirtualHost>

Note that this will fix most URLs, but not all. Some links use unique IDs that can change with the migration.

Cloud migration is the start of something more profound

Cloud migration projects are often framed as technical exercises. In reality, they are inflection points.

A move to the cloud forces decisions that many organizations postpone for years: who owns identity, how access is governed, which workflows truly create value, and where automation can replace friction. Teams that approach migration only as a hosting change complete the move and carry their old complexity with them. Teams that treat it as a moment to rethink how work flows across engineering, security, and business operations come out fundamentally stronger.

The shift away from Data Center arrives at a time when AI is reshaping how products are built, decisions are made, and teams collaborate. This is the ideal opportunity for organizations to align governance, clean up legacy processes, and position themselves to adopt these capabilities faster and with far less resistance.