Atlassian Jira is used as a task management tool in more than 100,000 companies worldwide.
For this reason, it is not uncommon for one company to manage two or more Jira installations. As a result of cost savings, there may be a requirement to combine these installations into one. In the following lines, we will describe how we proceeded in consolidating Jira instances for one of our clients.
About client
Our client in this project was a company that is a world market leader in technology for measuring dynamic pressure, force, torque and acceleration. The unique sensor technology from this owner-managed Swiss corporation helps shape future innovations not only in automotive and industrial automation development but also in many emerging sectors. The corporation itself has branches in 60 locations around the world.
The challenge – to combine two Jira environments into one
The corporation acquired a smaller German company. In both companies, they used Jira as a development management tool. Management decided to merge the two Jira installations into one. The target was an installation managed by the corporation. The request included the transfer of all Jira projects with settings (workflows, fields, screens…). The projects had to be transferred together with the tasks, attachments and reported time on the tasks. It was a matter of course to maintain the rights of users on individual projects. Among other things, the source Jira was also used to submit incidents from customers to Jira Service Management (JSM). The target Jira did not contain Jira Service Management, so it was necessary to add and set up JSM in the same way as in the source Jira.
Analysis
A thorough analysis had to be done before the migration itself.
In the first step, the user report was analyzed to ensure the same login information for users. In our case, Active Directory (AD) users were read in the source Jira, so it was necessary to transfer the AD connection settings to the target environment as well.
Another important part of the analysis was the analysis of applications. We needed to find out which extensions are actively used in the source installation and then find the possibilities of replacing them in the target one. If the application could not be replaced, it had to be installed on the target Jira.
We decided to use the
Configuration manager for Jira extension to transfer the data itself (projects, tasks, attachments). This extension can capture all elements of the Jira project configuration and then export them to a snapshot. In the export settings, it is possible to specify:
- exported projects
- also, export project tasks
- also, export with attachments
The extension must be installed on both instances. The advantage of the extension is the possibility to buy it only for 30 days (instead of the traditional 1 year) and thus save the client’s money.
Later, we selected 3 specific Jira projects that were migrated to the test environment as part of the testing and whose functionality was subsequently tested. The projects were of various types (team project with internal tasks, development project with scrum board and JSM project with forms on the portal) to cover as much of the functionality as possible. The selection of projects took place in cooperation with the contracting authorities.
The acquired company was from Germany, so it used pre-set fields (such as Epic name, Epic Status, etc.) in German and the acquirer, as a global corporation, uses these fields in English. Since the Configuration Manager would rewrite the names according to the source Jira, these fields had to be renamed.
Another important thing was to check that the same scheme names were not used (authorization scheme, notification scheme…). If the schemes have the same name and are differently configured in the target Jira, the scheme with that name would be rewritten according to the configuration in the source Jira. In our case, we renamed one notification and one authorization scheme in the source Jira.
The migration itself
Before the migration itself, we imported the mentioned 3 projects into a test environment, which was identical to the production target environment. We fine-tuned the migration process during the imports into the production environment. As is often the case with migrations, the migration tool does not transfer everything 100%, and after the import, several manual interventions had to be made in the configuration of the transferred projects. In our case, these were post functions (publishing functions) from an extension that Configuration Manager did not support.
The migration itself took place in the following steps:
- export of the data from the source environment
- data transfer from the source Jira server to the destination Jira server
- preparation of the target environment (extension installation, AD connection setup, Jira Service Management installation)
- import of the data into the target environment
- making settings on projects that the Configuration Manager cannot transfer
- functionality test
It was a matter of course to create a backup in the target environment before the migration began. Overall, we were able to consolidate the Jira environment in one weekend.
Benefits
The main advantage of consolidation is that all employees work in one installation of Jira. The next step will be to unify the processes of the corporation and the acquired company – in one installation, such a process is simpler. Only the system URL has changed for users from the acquired company. Save on overhead and licensing costs for two Jira environments – save time optimizing Jira. Improved employee collaboration – the employee does not have to switch between 2 environments but can find everything in one Jira.
We managed this connection in two different instances in 2 months.
If you need help from experts with the implementation or setup of Jira, or advice on how to use it most effectively in your company, do not hesitate to contact us.
Our Atlassian solutions
