Jira Data Center 8.x to 11.x Upgrade Path Recommendation

Platform Notice: Data Center Only - This article only applies to Atlassian apps on the Data Center platform.

Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.

*Except Fisheye and Crucible

Summary

Upgrading from Jira Data Center 8.x to Jira Data Center 11.x is best treated as a staged upgrade rather than a single-version jump. The path crosses several major platform boundaries, each introducing important runtime, indexing, and compatibility changes.

The recommended path is 8.x → 9.12 LTS → 10.3 LTS → 11.3 LTS. This approach reduces risk by allowing administrators to validate the environment at each major step before moving forward.

While there is a mention in Jira Software 11.3.x release notes | Atlassian Support | Atlassian Documentation that you can go straight from 9.12 or 10.3 to 11.3 this statement does not change the general recommendation for customers starting on Jira 8.x. For 8.x environments, intermediate upgrades remain the safer and more supportable approach.

This is a recommendation, not a blanket statement that every shorter path is technically impossible. However, there are important technical requirements within the journey that must be addressed before upgrading to later major versions.

Solution

Recommendation

For customers upgrading from Jira Data Center 8.x to Jira Data Center 11.x, Atlassian recommends the following path:

  1. Upgrade from Jira 8.x to Jira 9.12 LTS.

  2. Validate the upgraded environment, including apps, integrations, authentication flows, and operational readiness.

  3. Upgrade Java to a version supported for the next stage before moving onward.

  4. Upgrade from Jira 9.12 LTS to Jira 10.3 LTS.

  5. Validate the environment again, especially custom apps, REST, and Java API usage, and third-party integrations.

  6. Complete required platform prerequisites for Jira 11.x, including supported Java and database versions.

  7. Upgrade from Jira 10.3 LTS to Jira 11.3 LTS.

Recommended upgrade path: 8.x → 9.12 LTS → 10.3 LTS → 11.3 LTS

The reasons for this recommendation are:

  • Jira 8.x to 9.x requires a full reindex; index format changes make this a significant upgrade boundary.

  • Java progression must be planned carefully. Java 17 is supported in Jira 9.12 but not in Jira 8.20.x, and later Jira 11.3 requires Java 21.

  • Jira 10 introduces important platform and API changes. Using Jira 10.3 LTS as an intermediate stop provides a stable checkpoint before moving to Jira 11.x.

  • Jira 11.x has additional platform requirements. For example, Jira 11.3 does not support MySQL 8.0 and requires Java 21.

  • Each major version increases app and integration risk. A staged path gives teams time to test Marketplace apps, customizations, webhooks, SSO, and automation between major upgrades.

Important technical considerations: A full reindex is required when moving from 8.x to 9.x, and another full reindex is required when moving from 10.x to 11.x. Zero-downtime upgrade is not available across major-version jumps such as 8.x → 9.x, 9.x → 10.x, or 10.x → 11.x. You'll need to use one of the regular methods

Customers should also review application compatibility, custom integrations, authentication behaviour, Java requirements, database support, and maintenance window planning before each stage. In practice, the intermediate LTS stops provide the clearest checkpoints for validation and reduce the likelihood of compounded upgrade issues.

Known Issues

1. Jira 9 requires a full reindex after upgrading from Jira 8:

Because of indexing changes introduced between Jira 8.x and Jira 9.x, indexes from Jira 8 are incompatible after the upgrade. Plan downtime accordingly and avoid releasing the system to end users until the full reindex completes.

2. Async webhooks are now the default in Jira Data Center 10:

Starting from Jira Data Center 10.0.0, asynchronous webhooks are the default and only option. This improves user-facing responsiveness, but it may expose queue sizing, payload timing, or stale data issues in webhook-heavy environments.

Known webhook-related bugs include:

  • JRASERVER-78697: Webhook queue size and number of consumers can no longer be customized. Fixed in 10.3.5.

  • JRASERVER-74312: Inconsistent data for custom fields. Fixed in 10.3.6.

  • JRASERVER-74097: Comments not included in webhook payload. Fixed in 10.3.9.

  • JRASERVER-78739: Webhook can fire with stale modification data. Fixed in 10.3.12.

Recommendation: If webhook-heavy integrations are in scope, use a later 10.3 maintenance release during testing and validate webhook behavior before moving onward to Jira 11.3.

3. Jira 11 requires a full reindex because of index structure changes:

When moving from Jira 10.x to Jira 11.x, you’ll need to perform a full reindex. For larger environments, consider reviewing Atlassian’s guidance for upgrading Jira Data Center 10 to 11 with minimal downtime using an auxiliary instance and index snapshot workflow.

Upgrading Jira Data Center to version 11.x on an existing index results in startup failure due to DocValues type mismatch: https://jira.atlassian.com/browse/JRASERVER-79510. More details here: Jira Data Center 11.x Reindex Cannot Change DocValues Type from SORTED_NUMERIC to SORTED_SET | Jira and Jira Service Management | Atlassian Support

4. App compatibility and custom integration risk increase at each major boundary:

This upgrade path crosses multiple platform releases, so app compatibility needs to be checked at least three times: before 9.12, before 10.3, and before 11.3. Pay special attention to custom apps, SSO plugins, webhook consumers, frontend customizations, and any direct use of REST or Java APIs.

Things to Check

  • As you are upgrading from Jira DC version 8.x to Jira DC version 11.3.x, please review the breaking changes introduced in Jira 9.x, 10.x, and 11.x.

  • Please confirm the current Java version and plan for Java 17 during the 9.12 and 10.3 phases, and Java 21 before the move to 11.3.

  • Please confirm the database platform and version, and verify whether an intermediate database upgrade is required before Jira 11.3. In particular, MySQL 8.0 must be upgraded to MySQL 8.4 before Jira 11.3.

  • Please plan for a full reindex after the Jira 8.x → 9.12.x upgrade.

  • Please plan for a full reindex after Jira 10.3.x → 11.3.x upgrade.

  • Please run compatibility checks for installed Marketplace and custom apps before each hop, and verify whether any app updates, replacements, or removals are required.

  • Review whether you need to re-enable app installation using the Upload app button on the Manage apps page, which is disabled by default in Jira Data Center 9.12.4 and later or Universal Plugin Manager 6.1.9 and later. See How to re-enable plugin upload in Jira Data Center | Jira and Jira Service Management | Atlassian Support .

  • If new apps need to be installed in Jira 11.x, review app signing requirements for Marketplace apps and custom apps before the maintenance window.

  • If you have SSO, LDAP, automation rules, webhooks, or custom REST integrations, test these specifically in a lower environment before each production cutover.

  • Please validate the rollback strategy, backups, shared home integrity, the database restore procedure, and the maintenance window duration for each major version step.

Additional References

Links to Jira release and upgrade information

Updated on September 8, 2026

Still need help?

The Atlassian Community is here for you.