October 7, 2018 at 19:22How I combined the data of the Tempo plugin for Jira Server and Jira Cloud and migrated it back to Jira Cloud
Hello!
Tempo plugins for Atlassian Jira are installed on a large number of Jira instances in both cloud and servers. I had to combine the data from the cloud and server Jira and set the combined data back to Cloud. In addition to the standard Jira data, I also needed to combine the data from the Tempo plugin. In this article I will tell you how I did the union and migration of Tempo data.
I picked up two Jira with the following configuration: Jira Software 7.11.2 and Jira Service Desk 3.14.2. Then I removed the backup from Jira Cloud and installed it on the first instance, then I removed the backup from Jira Server and installed it on the second instance. After that, I transferred the data from the second instance to the first using the Configuration Manager plugin (although it would be possible to use the Project Configurator plugin ).
As a result, I found that at the first instance, where the combined data was already located, ready to be transferred to Cloud, the following data of the Tempo plugin was missing:
It was necessary to fill out this data during the migration.
I was lucky with the accounts. The Tempo plugin has built-in functionality for exporting and importing accounts.
All I had to do was export the accounts from Jira Cloud and Jira Server to files before installing the combined data in Jira Cloud, and then, after loading the combined data into Jira Cloud, import these files into Cloud.
There was only one problem that some of the account keys in Jira Cloud and Jira Server were the same, so I needed to change these keys in one of their files. Otherwise, when importing account data with the same keys, the accounts will either be updated or archived, but none of these options suited me.
With teams it was more difficult. There is no built-in functionality for transferring commands. Therefore, I had to use Tempo Rest Api to get data on commands, and then create these commands in Jira Cloud.
I used the following Rest calls:
I also wanted to use Tempo Rest Api to set the permissions of the command, but found a bug in this Api.
Since there was no information on the meaning of the Account and Team fields on the combined Jira instance, I had to save this information before migrating.
For Jira Cloud, I used Jira Rest Api to search for all items that have Account or Team fields filled in. Then I saved all these ishs with field values to a file.
For Jira Server, I used the Jira Java API to get the values of the Account and Team fields.
As a result, I got two files with information about accounts and commands for ish from Jira Cloud and Jira Server.
The problem was that after I migrated the combined data to Jira Cloud and created the accounts and teams, the teams and account IDs did not match the old IDs, so when I set the correct values for the commands and accounts for Ishu, I had to remap the old ones id in new ones.
To update the Account and Team fields, I used the standard Jira Core Rest Api to update Ishu .
There were no problems with the work records that came from ish with Jira Server. Everything was postponed without any corrections, but there were problems with the records about working from ish with Jira Cloud.
This is due to the fact that when a record of work in Jira Cloud is added using the Tempo plugin, this record is added from the user of the Tempo plugin, and not from the user who makes this record. Therefore, in order to get the right user, you need to get this user from the Tempo plugin database.
For this reason, I had to get the right users of Jira Cloud work records before doing the migration.
This was done as follows:
Then, after I installed the backup with the combined data, I deleted all the work records that were added from the standard user of the Tempo plugin and added the records from the file that I received in step 3.
It is also better to set the Remaining Estimate field when adding job records in optional. In this case, it will not be necessary to get the current value of the Remaining Estimate field for each time you add a job entry.
1. When you install the Tempo Timesheets plugin in Jira Cloud, a connection is created between the Jira Cloud and the Tempo database, which is needed so that when you receive data from the Tempo plugin, it would get the data for your Jira instance.
The problem is that if you restore Jira Cloud from backup, then this connection is no longer visible from Jira Cloud and therefore you have to reinstall the Tempo plugin, and thus a new connection is formed between Jira Cloud and Tempo. However, the old link actually exists in the Tempo database.
As a result, when you start working with ish, the data is pulled through the old and new connections, and the old connection is primary (i.e. if in the old Tempo database there is a command with the same id as in the new one, then the name of this command will be pulled from the old DB Tempo). But if you enter the Administration of teams and accounts through the user interface of the administrator, then we will see the correct data from the last connection. And if we create a custom Tempo Report, then we will also see the correct data. Therefore, the old connection must be deleted, and you can remove it only by contacting Tempo support. True support Tempo worked very quickly for which I am grateful to her.
2. After I migrated work records with Jira Server, some work records had a deduction date one day earlier than needed. This was due to the time zone of the user and the date of debiting. I had to write a program to find all such work records and change the date.
In general, this is all you need to do and know to successfully transfer data from the Tempo plugin. Hope this information is helpful.
Tempo plugins for Atlassian Jira are installed on a large number of Jira instances in both cloud and servers. I had to combine the data from the cloud and server Jira and set the combined data back to Cloud. In addition to the standard Jira data, I also needed to combine the data from the Tempo plugin. In this article I will tell you how I did the union and migration of Tempo data.
Tempo data that I migrated:
- Tempo Accounts (accounts)
- Tempo Teams (teams)
- The values of the Account and Team fields for all ishui in Jira
- Worklogs
The process of integration and migration:
I picked up two Jira with the following configuration: Jira Software 7.11.2 and Jira Service Desk 3.14.2. Then I removed the backup from Jira Cloud and installed it on the first instance, then I removed the backup from Jira Server and installed it on the second instance. After that, I transferred the data from the second instance to the first using the Configuration Manager plugin (although it would be possible to use the Project Configurator plugin ).
As a result, I found that at the first instance, where the combined data was already located, ready to be transferred to Cloud, the following data of the Tempo plugin was missing:
- Tempo Account Information
- data about Tempo teams
- values in the ish for the Account and Team fields
- authors of ish work records that were downloaded from Jira Cloud
It was necessary to fill out this data during the migration.
How I Migrated Tempo Plugin Data
Accounts
I was lucky with the accounts. The Tempo plugin has built-in functionality for exporting and importing accounts.
All I had to do was export the accounts from Jira Cloud and Jira Server to files before installing the combined data in Jira Cloud, and then, after loading the combined data into Jira Cloud, import these files into Cloud.
There was only one problem that some of the account keys in Jira Cloud and Jira Server were the same, so I needed to change these keys in one of their files. Otherwise, when importing account data with the same keys, the accounts will either be updated or archived, but none of these options suited me.
Teams
With teams it was more difficult. There is no built-in functionality for transferring commands. Therefore, I had to use Tempo Rest Api to get data on commands, and then create these commands in Jira Cloud.
I used the following Rest calls:
- teams - to receive data on teams and create teams
- team-membership - to add team members
- team_links - to add a link to a team on a project or board
I also wanted to use Tempo Rest Api to set the permissions of the command, but found a bug in this Api.
Setting the correct values in the Account and Team fields for all
Since there was no information on the meaning of the Account and Team fields on the combined Jira instance, I had to save this information before migrating.
For Jira Cloud, I used Jira Rest Api to search for all items that have Account or Team fields filled in. Then I saved all these ishs with field values to a file.
For Jira Server, I used the Jira Java API to get the values of the Account and Team fields.
As a result, I got two files with information about accounts and commands for ish from Jira Cloud and Jira Server.
The problem was that after I migrated the combined data to Jira Cloud and created the accounts and teams, the teams and account IDs did not match the old IDs, so when I set the correct values for the commands and accounts for Ishu, I had to remap the old ones id in new ones.
To update the Account and Team fields, I used the standard Jira Core Rest Api to update Ishu .
Job Records
There were no problems with the work records that came from ish with Jira Server. Everything was postponed without any corrections, but there were problems with the records about working from ish with Jira Cloud.
This is due to the fact that when a record of work in Jira Cloud is added using the Tempo plugin, this record is added from the user of the Tempo plugin, and not from the user who makes this record. Therefore, in order to get the right user, you need to get this user from the Tempo plugin database.
For this reason, I had to get the right users of Jira Cloud work records before doing the migration.
This was done as follows:
- I found everything in Jira Cloud, where the user of the work record was a user of the Tempo plugin. I did this using the standard Jira Core Rest call .
- Then I got all Jira id work records from those received by Ish in step 1 with the help of this Rest call .
- Then I received data from the Tempo plugin for all work records obtained in step 2 and saved to a file. I received data using Tempo Rest Api .
Then, after I installed the backup with the combined data, I deleted all the work records that were added from the standard user of the Tempo plugin and added the records from the file that I received in step 3.
It is also better to set the Remaining Estimate field when adding job records in optional. In this case, it will not be necessary to get the current value of the Remaining Estimate field for each time you add a job entry.
Unexpected problems
1. When you install the Tempo Timesheets plugin in Jira Cloud, a connection is created between the Jira Cloud and the Tempo database, which is needed so that when you receive data from the Tempo plugin, it would get the data for your Jira instance.
The problem is that if you restore Jira Cloud from backup, then this connection is no longer visible from Jira Cloud and therefore you have to reinstall the Tempo plugin, and thus a new connection is formed between Jira Cloud and Tempo. However, the old link actually exists in the Tempo database.
As a result, when you start working with ish, the data is pulled through the old and new connections, and the old connection is primary (i.e. if in the old Tempo database there is a command with the same id as in the new one, then the name of this command will be pulled from the old DB Tempo). But if you enter the Administration of teams and accounts through the user interface of the administrator, then we will see the correct data from the last connection. And if we create a custom Tempo Report, then we will also see the correct data. Therefore, the old connection must be deleted, and you can remove it only by contacting Tempo support. True support Tempo worked very quickly for which I am grateful to her.
2. After I migrated work records with Jira Server, some work records had a deduction date one day earlier than needed. This was due to the time zone of the user and the date of debiting. I had to write a program to find all such work records and change the date.
In general, this is all you need to do and know to successfully transfer data from the Tempo plugin. Hope this information is helpful.