The Project
Our client’s engineering support team manages the tooling used across developers in Germany and other countries. Among these tools are two Jira servers: one is used by the developers of German online shopping platform, the other one by software development teams from other marketplaces including Holland, Australia, and Denmark. kreuzwerker was asked to merge all active projects from the German instance to the main, global server.
The Problem
Developers at our client’s side have been working in two Jira worlds for a long time already. In fact, the engineering support team itself had similar projects in both instances. Apart from doubling the cost of maintaining two servers, having separate Jira applications also prevented close collaboration between teams worldwide and created two support entry points for end users. In this state, the same group of 2,000 users had access to both servers. The German server was accessed mostly at normal working hours, while the global server saw 24/7 world wide access. Our client believes that teams are at their best when they can freely organise their own work. For Jira however, this means that there are a lot of differently configured projects and only a small amount of shared configuration items.
The global server was selected as a target server based on the number of existing projects and issues. Hence, about sixty active projects from the local server were selected for merging. Besides the technical complexity, the challenge was running the project with minimal impact on development teams. However, a big bang scenario where all projects could be merged over a weekend was not possible because the time needed to merge sixty projects was simply not enough. Furthermore, the support on the days after such weekend couldn’t be guaranteed due to the small size of the engineering support team. We decided to make groups of around ten business-related projects, merging one group per week.
The Solution
To actually perform the merge we constructed a merge-toolchain of two production and two staging servers. We synchronised the Jira software and add-ons on all servers. In order to be able to transfer the agile data (which was not possible over Jira for a long time) we upgraded to the latest Jira version and used the standard Jira project importer of this version to import the issues. The project configuration was transferred using the Configuration Manager add-on of Botron Software. The necessary conversion of configuration items and issue data was done with SQL scripts. Particular attention was given to the communication with the teams. We wrote a manual for the development teams which described what to do before and after the merge and used e-mails, Slack (instant messaging tool) and calendars to communicate about the merge schedule.
Our Contribution
Our most important contribution in this project was to perform an extended analysis of the configuration and projects of both Jira instances, as well as preparing and testing the merge in detail. In the end, this resulted in a minimal number of support issues during the merge itself and a freeze for only one night for the individuals in the German development teams.
The Benefit
Our client’s developers across all countries work now in one common Jira instance and don’t have to make context switches anymore. The engineering support team in Berlin has one central support project in Jira in order to help locally based developers and globally based development teams. Work on this project enabled kreuzwerkers to further extended and enriched their Jira merge project expertise. As a result of the operation we successfully moved 60 projects, 100 agile boards, 75,000 issues and some 250,000 comments.