Addteq recently had the opportunity to assist an insurance agency deployment of upgraded Jira and Confluence instances on new servers in preparation for a migration to the Atlassian cloud. The versions of Jira and Confluence in use were far past end-of-life and co-existed on a single server. The customer was looking to create a new, dedicated environment for each application, reap the benefits of the latest versions of the applications, and take some time to assess their Atlassian configuration while preparing for the migration.
The Situation
With the Atlassian Cloud set as the end game, upgrading the applications was of the highest priority. Nearly all of the cloud migration methods for Jira and Confluence require a currently supported version of the application and an active license. The customer’s Jira and Confluence application versions were far past end-of-life. The applications also co-existed on a single server, which itself was past its prime. This would require re-installation and configuration of Jira and Confluence from the ground up, ideally on new dedicated servers. Given the wide gaps between the current versions and the latest long term support releases for Jira and Confluence, each product had to be upgraded in stages – it was not possible to upgrade the current versions in production directly to the latest long-term support versions, and even if that were possible, Addteq would have still used milestone updates to ensure the customer’s data was also upgraded without loss – especially since the latest applications also required new databases to support them. In the months leading up to this project, the customer had dealt with several problems in Jira, resulting in significant functionality loss. In addition to upgrading Jira, Addteq needed to find a way to restore this functionality in the latest version of Jira.
Challenges and Roadblocks
Our original plan was simple: create functional copies of the production instances on staging servers and upgrade the products. To ensure the upgrades were successful and performed safely, Addteq selected several Milestone versions for each product. Each product was to be upgraded to the next milestone, tested, and prepared for the next upgrade until the final long-term support version has been reached. However, reality sometimes does not adhere to the plan.
Our initial attempts to upgrade Jira were unsuccessful due to the re-emergence of the Jira issues previously faced by the customer. The main issues ranged from a failure of the automation module to function on startup, functionality loss in Jira Service Desk, the inability to upgrade Jira Service Desk or even get it running in an upgraded environment, and the inability to upgrade the Universal Plugin Manager – an issue that persisted through several attempted upgrades. Any attempts to upgrade the UPM resulted in its immediate shutdown, along with several other modules. These conditions posed significant challenges that prevented the upgrade process from taking place. Without resolving these problems, there was no way to safely upgrade Jira in a way that ensured it would work properly. Also, the customer’s problems in the past forced them to make changes to their Service Desk, which included removing automation that was crafted and implemented by Addteq in 2015. This automation was a critical component of their customer service and product development processes and needed to be restored.
Likewise, our initial attempts to upgrade Confluence were unsuccessful due to multiple database errors observed after the upgrade. Although Atlassian’s documented upgrade paths stated that it was possible to upgrade Confluence from the current version in production, 5.6, to version 7.0, this was not actually the case. The recommended upgrade method for an Atlassian product involves upgrading the application and then launching it with a connection to the existing database’s restored backup. Upon launch, the upgraded application will upgrade the data in the database to the latest version. In this case, between versions 5.6 and 7.0, an intermediate version, 5.10, had introduced new indexes. When Confluence 7.0 attempted to upgrade data from version 5.6, the attempt failed, effectively destroying the data within. The only way to upgrade to version 7 using the recommended upgrade method would be to upgrade to version 5.10, followed by another upgrade to version 7.0. However, this approach was not possible for one significant reason; Confluence 5.6.3 used Microsoft SQL Server 2008 to host its database, which is unsupported by 5.10. Confluence 7.0 and above were set to use Microsoft SQL Server 2016, which is also unsupported by version 5.10. The only version of SQL Server that Confluence 5.10 supported was MSSQL Server 2012, which was unavailable. Upgrading via this method would require creating a new SQL Server 2012 server and the purchase of a new license solely to host a temporary SQL Server 2012 database.
The Solution
Confluence
After carefully researching the options, we decided to install Confluence 7.0 fresh and connected it to a blank database. Using an XML backup from production without attachments, Addteq successfully restored all of the data from Confluence 5.6. Once complete, Addteq restored the original home directory and reinstalled all plugins. Once upgraded, a health check in Confluence failed, stating that a local admin account was missing, when in fact, a local admin account was present and active. The health check for a local admin failed due to a local Confluence group and an Active Directory group with the same name: confluence-administrators. The customer set the order of user directories to Active Directory first, and then the local user directory. Given the order of directories, and two groups with the same name, when identifying admins, Confluence used the AD group and ignored the local group of the same name. To rectify this, Addteq created a local group for local admins, and this group was granted Confluence Administrator and System Administrator rights within Global Permissions. Although there were no health check failures in Jira after the upgrade, the same steps were taken for Jira, just in case.
Jira
To rectify the problems with Jira and provide a solution, Addteq researched each of the problems and potential solutions in consultation and collaboration with a member of the Atlassian Support team. Addteq cleaned up the instance, removing unnecessary third-party tools and resolving tool-related issues in the database on the back end. Once the instance had been properly prepared, Addteq incrementally updated Jira from one milestone version to the next, all while collaborating with Atlassian Support to ensure all issues at each upgrade point were addressed. Once complete, Addteq verified the functionality in Dev Jira was equivalent to that of Production Jira. We then restored all of the Service Desk automation that the customer previously removed due to the pre-existing conditions, repairing automation no longer working in Jira after the upgrade due to changes in functional requirements between versions.
The Win
Although the final implementation deviated considerably from the original plan, the involvement and collaboration with the customer at every step ensured their involvement and understanding of the scope as refinements were made through the course of the project. As a result, the customer’s team was thrilled, not only with the outcome but the level of collaboration and transparency into the work we performed. Some highlights of the outcome include:
• The customer now has the latest LTS releases of Jira and Confluence running independently on new servers.
• The new versions of Jira and Confluence meet and exceed the functionality of what was previously in place, with lost functionality restored.
• The customer is delighted with the outcome and is currently working with Addteq to plan their migration to the Atlassian Cloud.
