Best Practices to Prepare for Migration
Collect Data from Your Financial Applications
One key step to take when preparing for migration is to gather data from your financial applications. Depending on the amount of Tempo Accounts and users you have, this will likely mean that you will need to make a significant number of API calls.
There are two main approaches we recommend to collect this data. In the end, you will need to decide which approach is best given the level of information you need for your financial integration. But regardless of the approach you take, you should try to retrieve as few chunks of data as possible.
Use a datalake A datalake can act as a middleman between Tempo and your financial application. The datalake collects all worklogs, all Timesheet approvals and all Tempo Account worklogs. Then you can map the worklogs against the approved timesheets and the Tempo Accounts to gather the information from the Tempo Account that the the worklog is assigned to. This approach is appropriate when you already have a datalake infrastructure in place and you want to see the collected data for other purposes (e.g. reporting).
Gather additional data on the fly Another approach is to get the additional data on the fly. To do so, you make additional calls to the Jira and/or Tempo REST endpoints for each single worklog you retrieved in your original REST API call.
To get the approval status of a worklog you call the worklog approval endpoint where you populate the from and to parameters with the returned date field from the response.
To get the Tempo Account you will need to check against the Jira issue API and retrieve the information for the Tempo Account custom field. More detailed information can be found in the REST API section. Since the Account can also be set on the worklog level, you will need to introduce the same logic that Tempo uses behind the scenes.
When Account is set on the worklog level, use this Account (no need to call the Jira REST API in this case).
Then check the Account which is set on Jira issue level.
If both approaches above do not return any account information, then there is simply no Account set against the worklog and you will get a NULL value.
Since this approach requires a lot of back and forth calls, it may take a while to complete and iterate through all worklogs.
Set the same time zone for your Jira Cloud and Jira Server / Data Center instances
A number of customers migrating from Jira Server or Data Center to Cloud have noticed that migrated Tempo worklogs shift by several hours – or up to a day – when compared to the JIRA worklogs. This is due to the fact that Jira Cloud uses UTC as its time zone by default.
If you are operating in a time zone outside of UTC, it is important that make sure your Cloud instance is set to the same time zone as your Server instance. This will ensure that you do not experience problems with Jira issue dates (created, updated, etc.) after the migration. (You can find more information under item #10 in Atlassian’s migration checklist.) Just as importantly, this will ensure that Tempo worklogs have accurate timestamps after your migration is complete.
You can follow these steps to prevent migration issues related to time zones:
Check the time zone of your Server or Data Center instance.
Set the same time zone for your Cloud instance prior to import/migration.
Execute the JIRA data migration.
Install Tempo.
Watch this short video to get an overview of the migration steps, from doing a test run to launching Tempo from its new home on the Cloud: