How We Managed a Downgrade from Jira Data Center 8.22.6 to 8.20.30 with Zero Downtime

Recently, our team was hired to address an uncommon challenge involving a Jira Data Center hosted in AWS. Due to a misconfiguration, the system was upgraded to version 8.22.6 instead of the intended 8.20.30. This required us to perform a precise downgrade—a task that is seldom straightforward, especially when aiming for zero downtime. Here's how we successfully managed this complex situation.

Step 1: Verify Potential Database Incompatibilities

The first and perhaps most crucial step was to ensure that the database schema introduced in version 8.22.6 had no incompatibilities that would prevent us from rolling back to 8.20.30. By comparing the entitymodel.xml files from both versions located in WEB-INF/classes/entitydefs/, we could assess any changes in the database tables, columns, data types, and relationships.

Step 2: Downgrade the Database Version

Next, we updated the database version recorded in Jira's system properties to reflect our target downgrade version. We executed the following SQL command:

UPDATE propertystring SET propertyvalue = '820030'
    WHERE id = (SELECT id FROM propertyentry 
        WHERE property_key = 'jira.version.patched');

This effectively set Jira's internal version tracking to match the downgrade target.

Step 3: Revert Schema Changes

Based on our initial comparison, we identified a need to revert a schema change by adding a column that was removed in the higher version. The following SQL statement was executed:

ALTER TABLE component ADD deleted VARCHAR(10);

Step 4: Disable AutoScaling Health Checks

To prevent AWS AutoScaling from terminating the new nodes—which might take longer to start due to the downgrade—we temporarily disabled the health checks.

Step 5: Clean Shared Home Plugin Versions

We then cleaned up the shared home directory by removing plugin versions specific to 8.22.6, ensuring no artifacts from the newer version remained that could interfere with the rollback:

find /media/atl/jira/shared -type f -name "*4.22.6*" -delete && find /media/atl/jira/shared -type f -name "*8.22.6*"- delete

Step 6: Modify Shared Home Jira Version

We explicitly set the Jira version in the shared home directory:

echo "8.20.30" > /media/atl/jira/shared/jira-software.version

Step 7: Initiate a Rolling Update

With preparations complete, we began a rolling update. This method ensures that the system remains operational by updating nodes one at a time.

Step 8: Update AWS Cloud Formation Template

We updated our AWS Cloud Formation template to specify the target version of 8.20.30, ensuring that all new nodes launched would be correctly configured.

Step 9-12: Node Management

We proceeded by detaching one node, starting a new node with the correct version, and then systematically stopping and restarting the remaining nodes. This phased approach allowed us to maintain uptime and service continuity:

1. Detach one node and start a new node with version 8.20.30.
2. Sequentially stop the remaining nodes.
3. Complete the rolling update across all nodes.
4. Restart all remaining nodes to ensure they were running the correct version.

Through meticulous planning and careful execution, we successfully downgraded our Jira Data Center from version 8.22.6 back to 8.20.30 with zero downtime. This experience underscores the importance of rigorous version control and operational checks in managing enterprise software deployments in the cloud.