How I merged Tempo data from Jira Server and Jira Cloud and migrated them to Jira Cloud

[#1]

Hello!

Many Jira instances have Tempo add-ons installed either on Server or on Cloud. Not so long ago I had to merge data from a Jira Server instance and a Jira Cloud instance and then migrate this merged data back to the Jira Cloud instance. And one part of this migration was Tempo data.

What was exactly this Tempo data?

1. Tempo Accounts.

2. Tempo Teams.

3. Links to the Tempo Accounts and Teams for each issue.

4. Worklogs.

What was the process of merging and migration?

I created two Jira instances with the following configuration: Jira Software 7.11.2 and Jira Service Desk 3.14.2. I took a cloud server backup and installed it on the first Jira instance. Then I took a server backup and installed it on the second Jira instance. Then I merged all data from the second Jira instance to the first one, using Configuration Manager (but actually it does not matter what to use: Configuration Manager or Project Configurator).

As a result I discovered that on the first Jira instance, where I had all my data merged and ready to be restored to Cloud, I did not have any data about Tempo Accounts, Tempo Teams, I did not have links to Tempo Accounts and Tempo teams for all issues and I did not have the real worklog authors for issues from Jira Cloud.

And I had to solve all these problems somehow.

How did I migrate Tempo data?

Accounts

That is where I got lucky. Tempo has an in-built functionality to export and import all information about accounts. That is why all I did, I exported all accounts from Cloud and Server to files and then, after I restored merged backup to Cloud, I imported these files with account info back to Cloud.

There were accounts with the same Account Key in Cloud and Server, that is why I had to change account keys for such accounts in the file with the server accounts. Otherwise upon importing the server account file, you would have two options: to update duplicate accounts or archive duplicate accounts and create new ones. None of these options was a good fit for me.

Ok. It was very easy with accounts.

Teams

I was not so lucky with Tempo Teams. I had to develop my own application based on Tempo Rest Api. I used the following Rest API:

teams - to create a Tempo team.

team-membership - to add a member to a Tempo team.

team-link - to add a link to a project or a board for a Tempo team.

I also wanted to use the Tempo Rest Api to add the required permissions for a Tempo Team, but this rest method did not work correctly and I published a bug with the Tempo support.

Linking issues to Tempo Teams and Tempo Accounts

Since I did not have any information about issue links to teams and accounts in the merged instance, I had to save this info in a file before migration.

For Jira Cloud I used the search Rest Api Call to get all issues, for which the Account or the Team field was set. And I had to create a multithreaded application, because it took me too long to take this info in one thread.

For Jira Server I used the Jira Java Api to get info about accounts and teams.

As a result I had two files with info about teams and accounts for each issue. But there were ids of old accounts and teams. After I restored a merged backup to Jira Cloud, imported Accounts and created Teams, all teams and accounts had a new id and I needed to replace the old id with the new one. 

That is why while updating the Account and the Team fields for every issue, I mapped the old account or team id to the new id. I updated issues with the edit issue Rest Api.

That was it with links.

Worklogs

Worklogs from the Server instance were moved just fine without any hacks from my side. But unfortunately it could not be done for the worklogs from Cloud. In Cloud when you log time with the Tempo Plugin, Jira Cloud does not store the real author of the worklog. The Tempo plugin logs all worklogs under the Tempo Timesheets user. You can find who logged work only by getting this info from the Tempo database. That is the reason why when you restore a backup from Cloud to Server, you loose all info about the real author of worklogs.

That is why I needed to save all info about worklog authors in a file, before doing migration. I did it the following way:

1. searched all issues where the worklog author was the Tempo Timesheets user.

2. got all jira worklog ids for each issue.

3. got all worklog authors from Tempo for each jira worklog id and saved the result to a file.

Then after I restored the merged backup to Cloud, I deleted all worklogs with the Tempo Timesheets user and added saved worklogs to issues programmatically.

You should also set the Remaining Estimate as optional in the Tempo settings, otherwise you would need to provide the remaining estimate for each issue, to which you add a worklog. 

And that was all with worklogs.

Unexpected problems

1. When you install the Tempo add-on to Jira Cloud, a link is created between your Jira instance and the Tempo database.  When you execute queries against Tempo data in your Jira Cloud instance, this link allows Tempo to map your Jira Cloud instance to the Tempo database. When you restore a backup from Jira Server to Jira Cloud this link is not available anymore in your Jira Cloud instance, that is why you need to install the Tempo Timesheets add-on again and create a new link.

And the problem is that the old link is not deleted from the Tempo database. Your Jira Cloud instance begins to query data for issues from both links. But if you work in the Tempo administration UI or create a Tempo Custom report, your data are queried only from the last link as expected. As a result you get completely wrong data in your issues. 

Fortunately this problem was solved fast by deleting the old link by the Tempo Team and all data became correct for issues. And I am very grateful to the Tempo Team for very fast cooperation and willingness to help.

2. Some worklogs from the Server instance was one day behind in the Cloud instance. It happens because of the timezone of users and the created date of a worklog. 

I had to write a program to identify all such worklogs and change their date.

I guess, that is all what is needed to know to make a successful migration of Tempo data.

Hopefully. this information will be useful to you.

[Ethan Vaughan VF]

Would be possible to see examples of the code?
That would help out if anybody ever needed to do a migration like that.

[Alexey Matveev]

Just to say, that it is possible to do it. You can make your own app and share it.