![]() Overall, we were able to consolidate the Jira environment in one weekend. It was a matter of course to create a backup in the target environment before the migration began. making settings on projects that the Configuration Manager cannot transfer.import of the data into the target environment.preparation of the target environment (extension installation, AD connection setup, Jira Service Management installation).data transfer from the source Jira server to the destination Jira server.export of the data from the source environment. ![]() The migration itself took place in the following steps: In our case, these were post functions (publishing functions) from an extension that was not supported by Configuration Manager. 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. During the imports, we fine-tuned the migration process itself into the production environment. The migration itselfīefore the migration itself, we imported the mentioned 3 projects into a test environment, which was identical to the production target environment. ![]() In our case, we renamed one notification and one authorization scheme in the source Jira. 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. Since the Configuration Manager would rewrite the names according to the source Jira, these fields had to be renamed.Īnother important thing was to check that the same scheme names were not used (authorization scheme, notification scheme…). 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. 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. 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 projects had to be transferred together with the tasks, attachments, reported time on the tasks. The request included the transfer of all Jira projects with settings (workflows, fields, screens…). The target was an installation managed by the corporation. Management decided to merge the two Jira installations into one. In both companies, they used Jira as a development management tool. ![]() The corporation acquired a smaller German company. The challenge – to combine two Jira environments into one The corporation itself has branches in 60 locations around the world. 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. Our client in this project was a company that is a world market leader in technology for measuring dynamic pressure, force, torque and acceleration. In the following lines, we will describe how we proceeded in consolidating Jira instances for one of our clients. 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.
0 Comments
Leave a Reply. |