How to: Migration of Billable Hours in Tempo (Cloud)

How to save important Tempo data when moving to the Atlassian Cloud
04.10.2021
Tags

Not every Atlassian application migration works smoothly. It is not uncommon for things to become more complex and thus more time-consuming if the Jira, Jira Service Management and Confluence instances have been highly customized. And not all data from every Atlassian Marketplace app can be easily brought into the Atlassian Cloud either. This blog is about the migration of App Tempo timesheets and billable hours. Exactly the kind of data you don’t want to lose under any circumstances in a migration. As an Atlassian Platinum Solution Partner and partner of Tempo, we are your experts for the implementation, development and migration to the Cloud of Tempo Timesheets, Tempo Planner and Tempo Budget. Contact us.

Starting Point: Tempo Migration to the Cloud

Tempo Timesheets / Budgets are Atlassian Marketplace extensions that are installed in the instance. Worklogs and timesheets may not go missing in the Jira migration of the server or data center instances (on premise) to the Atlassian Cloud. A standard approach does not guarantee that this won’t happen - so there are some essential points to be considered.

With the installation on the Tempo data center or server version, additional database tables are added so that the application can store additional worklog attributes such as billable hours and comments. These features are complementary to the worklog section of the standard Jira. In principle, this illustrates it quite well:

Tempo Billable Hours

The blue table represents the default worklog entries. Tempo Timesheets can be used to store additional attributes/values for each worklog entry. This is achieved with an additional table, in orange above. In the example above, this would mean that four hours can be entered for the worklog entry for Issue ABC-1, but only two of them will be billed. For the worklog entry for Issue ABC-2, three hours were entered, of which all three can be billed. This functionality or distinction is particularly important in projects in which it is important to familiarize oneself with a subject, or when not all the hours used can be remunerated in accordance with a contractual agreement.

Saving the billable hours

With the migration from Jira Data Center or Server to the cloud, this data is not automatically transferred. In other words, they are simply no longer available after the migration. This is a real disaster if costs are actually to be charged here, but also if there are internal budgets for individual projects. The tracking of booked times and the controlling of projects and budgets becomes completely impossible. Essentially, this is because Atlassian needs to know the structure of the source and target instance (server and cloud), so that a transfer with the Jira Cloud Migration Assistant (JCMA) or the site import is possible. The structure of all app data (orange tables) is unknown to Atlassian and therefore no automatic transfer can take place. For this reason, all information from Tempo is also lost with the normal cloud migration. However, there is a way to transfer this data to the cloud after the fact. This is how it works.

How does a Tempo-migration to the cloud work?

  1. The first step is to move the Jira data from the Server or Data Center-Deployment to the cloud as usual. There are various approaches to this, which are relatively well documented on the corresponding support pages of Atlassian for the migrations. First, the standard Jira data is migrated. Then, both instances (Server and Cloud) contain the same worklog entries. The instances must be online and accessible from the same computer.
  2. When installing Tempo in the cloud, there are two ways to handle the missing information. First, Tempo Cloud does not know the (orange) values from the server. After all, these have not been transferred. For this reason, Tempo in the Cloud can either set the billable hours to 0, or you take the value from the blue table. This is exactly what Tempo does. You set Logged Hours = Billable Hours. To remedy this, we wrote a job as part of a customer project that checks every entry on the server and transfers the information to the cloud.



A validation script ensures success

Example: If, for example, 27 hours were logged for Issue ABC-1, but only 20 hours are specified as billable, then our job checks which hour was entered and how, and which hours were classified as non-billable. The job finds exactly the same entries in the cloud and adjusts them afterwards. Once the job has run, it then checks whether all entries on the server and in the cloud match.

What to consider: Our job works generically, independent of projects, of settings and permissions. At the beginning, the permissions are always set correctly for all projects and removed again after the run.

Cleaning up this Tempo data is a time-consuming process that can take several hours or even days. But the time spent is worth it, because after the cleanup, the data is available 1:1 in the cloud, just as it was on the server. Manual adjustments are no longer necessary. Our job can also be started in stages, so that historical data can be transferred overnight or over the weekend, for example. In our view, this is the only and correct way to bring additional data from the server to the cloud: completely without data loss.

We are your Atlassian professionals for migration to the cloud.

As an Atlassian Platinum Solution Partner, we have many years of expertise from working on a multitude of projects. This naturally includes many challenges when migrating to the Atlassian cloud. Depending on the app you use and the general complexity of the instances you use, you should be able to rely on support from our Atlassian experts. We usually start migration projects to the cloud with a so-called Cloud Readiness Assessment, which assesses the task in detail and provides you with valuable advice.

Get in touch with us!

(PS: Of course, this also applies to Atlassian licenses, training, the introduction and further development of Jira, Confluence and Jira Service Management, etc.)