Atlassian Data Center End of Life: How to Assess Your Instance Before Migrating to the Cloud

Share

If your organization has ever considered moving to the Cloud, now is the time to act. Atlassian has officially announced the end of life (EOL) for its Data Center (DC) products, which means that all DC instances will eventually become read-only.

Key Dates for Atlassian Data Center End of Life

  • March 30, 2026 – End of sales for new Data Center licenses and Marketplace apps for new customers.
    March 30, 2028 – Final date for existing customers to purchase new licenses.
  • March 28, 2029 – All Data Center licenses will expire and transition to read-only mode.

With this timeline approaching, organizations running Jira Data Center or Confluence Data Center should start preparing their Cloud migration strategy as soon as possible. This article outlines the most important steps and considerations for a smooth, successful transition — serving as both a practical guide and a solid starting point for your migration journey.

1. Data Center Instance Assessment

Before migrating your data, the first and most critical step is to perform a comprehensive assessment of your Jira and Confluence Data Center instance.

A thorough assessment helps you:

  • Understand the current state of your Data Center environment, including users, projects, spaces, apps, and custom configurations.
    Identify what data needs to be migrated and what can be archived or cleaned up.
  • Detect differences between Data Center and Cloud, such as feature gaps, app availability, or configuration variations.
  • Highlight areas that require extra effort, such as custom fields, automation, or Marketplace apps.

A proper assessment offers a clear view of your migration’s scope and complexity, allowing you to estimate effort accurately and prepare your teams for a seamless move to the Cloud.

2. Apps

When assessing your apps, the first step is to analyze actual app usage to determine which ones are essential for your Cloud environment. Removing unused or low-value apps early reduces migration complexity, risk, and cost.

Once you’ve identified the apps to retain, the next step is to understand how each Marketplace app behaves on Cloud compared to Data Center.

Two aspects are particularly important:

  • Feature differences: Many apps operate differently in the Cloud due to architectural and platform differences. Some features available on Data Center are not supported on Cloud.
  • Migration path: Tools such as the Jira Cloud Migration Assistant (JCMA) and Confluence Cloud Migration Assistant (CCMA) support a range of apps, but not all. For example, third-party dashboard gadgets are not automatically migrated and require manual adjustments.

Below are examples of popular apps that typically require additional planning and effort during migration.

ScriptRunner

Migrating ScriptRunner from Data Center to Cloud is not a direct transfer. ScriptRunner Cloud interacts with Jira via REST APIs, whereas the Data Center version relies on Java APIs.

Migration process for ScriptRunner:

  1. Review existing scripts: Identify which Data Center scripts are still necessary.

  2. Rewrite or replace: Determine whether each script can be rewritten for Cloud or replaced by:
    • Jira automation rules
    • Native Jira workflow functionalities
    • Another Marketplace app

  3. Adapt to Cloud limitations: ScriptRunner Cloud has a 240-second script timeout. Long-running scripts must be refactored or redesigned to comply.

Xray

Migrating Xray from Data Center to Cloud requires several pre-migration adjustments to ensure a successful data transfer.

Key steps before migrating Xray:

  • Align issue link types and issue types: Ensure names are identical in both instances.
  • Run pre-flight checks: Identify potential blockers and resolve them before migration.
  • Review issue security schemes: Confirm access permissions allow migration tools to read and transfer Xray data.
  • Add Xray custom fields to Test Execution screens: Ensure all relevant fields are included during migration.

Additionally, Xray recently introduced attachment upload support, allowing app-specific attachments to migrate alongside Jira attachments, significantly reducing total migration time.

Jira Misc Workflow Extensions (JMWE)

The Jira Misc Workflow Extensions (JMWE) app offers only a partial automatic migration path.

Automatic migration includes:

  • Basic workflow conditions, validators, and post functions supported by Atlassian’s tools.

Manual adjustments are required for:

  • Any functionality built using Groovy scripting, as these cannot migrate directly. Such scripts must be rewritten using Jira Expressions or Nunjucks templates in Cloud.

Skipping this step may result in broken workflows post-migration, potentially disrupting key business processes.

3. Projects and Spaces

Migration is the ideal opportunity to review which Jira projects and Confluence spaces should make the move. While migrating everything is technically possible, archiving or removing unused and low-value items beforehand is strongly recommended.

Migrating unnecessary data increases complexity and cleanup effort. By cleaning up in advance, you reduce risk and ensure a cleaner, faster migration.

Atlassian provides detailed documentation on which data types are automatically migrated using the Migration Assistant for Jira (including JSM) and Confluence. Reviewing these resources helps you plan effectively and avoid surprises.

4. Automation Rules

Migrating Jira automation rules involves export, import, and post-migration adjustments.

Steps to follow:

  1. Pre-migration review: Check if each rule is still needed. Determine if it’s active, redundant, or can be merged with another.
  2. Export from Data Center: Automation rules can be exported as JSON files.
  3. Import into Cloud: Upload JSON files to the Cloud instance.
  4. Post-migration fixes: After import, validate each rule carefully. Custom fields, statuses, and project references may need manual updates.

A thorough audit ensures you migrate only valuable rules, reducing clutter and avoiding redundant automation.

5. Boards, Filters, and Dashboards

With Atlassian’s Cloud Migration Assistant, boards, filters, and dashboards migrate automatically — but there are exceptions worth checking:

  • Third-party dashboard gadgets: These are not migrated automatically. Identify dashboards using such gadgets and plan replacements or rebuilds.

  • Data inconsistencies: Atlassian offers documentation and database queries to help identify and resolve common issues, such as:

    • Boards linked to non-existent filters
    • Filters using email addresses (the ‘@’ character is reserved in Cloud JQL)
    • Boards or filters owned by deleted or inactive users

Running these checks prevents broken dashboards, missing filters, and other migration errors.

6. User Macros

User macros are not migrated automatically because Confluence Cloud does not support the user macro feature.

Before migration, review each existing macro and decide:

  • Is it still needed in Cloud?
  • Can it be replaced by a built-in Confluence Cloud macro?
  • Can it be replicated using a Marketplace app or custom-built via Atlassian Forge?

For macros without a direct replacement, custom development may be required.

7. Users

Before migrating users to the Cloud, it’s essential to resolve duplicate and invalid email addresses in your Data Center instance.

The Cloud Migration Assistant can detect these issues, list affected users, and export them to a CSV file for review.

To resolve duplicates:

  • Merge duplicates (automatic): The assistant merges accounts with the same email. Some users may no longer exist post-merge.
  • Update email addresses: Assign unique emails to preserve separate accounts.
  • Delete duplicates: Remove unnecessary accounts.

To resolve invalid users:

  • Migrate as “Former users” (automatic): They will be deactivated in Cloud.
  • Assign valid email addresses: Required for users that remain active.
  • Delete invalid users: Recommended for obsolete accounts.

Cleaning up users ensures accurate license sizing in Cloud and avoids unnecessary costs.

Conclusion

A Data Center assessment is the foundation of every successful Cloud migration. Skipping or rushing this phase can lead to unexpected complications later, making the process slower and more expensive.

By investing the effort upfront, you gain a clear overview of your instance, minimize risks, and accurately plan your migration journey from Atlassian Data Center to Cloud.

Reach Out

If you have questions or need expert guidance with assessing your Atlassian Data Center instance and planning your migration to the Cloud, reach out to our team.

At Idalko, we’ve helped countless organizations successfully make the transition, ensuring minimal disruption, reduced risk, and a smooth path to the Cloud.

Let’s Talk. It’s on The House.

CONTACT US