Cloud-to-Cloud Migrations: Tempo Products - Timesheets

Can I migrate from one Cloud instance to another Cloud instance, or re-install a backup I have taken from my Cloud instance?

Tempo does not offer migrations between Tempo Cloud instances. Tempo stores its data in a database separate from Jira, so Tempo data does not follow when Jira is migrated. Atlassian's migration methods don't copy Marketplace app data either (see Atlassian's Cloud-to-Cloud migration guide).

A backup and restore feature is on the roadmap, but there is no timeframe yet.

Support can assist with specific issues that come up during a migration, but doesn't support the migration process itself.

Options

• Tempo Platinum Partners: Some partners offer Cloud-to-Cloud migration services. See the Tempo Partner Directory.

• Adaptavist (ScriptRunner Connect): Adaptavist, a Tempo Partner, offers a tool that can migrate the data. Open a ticket on their Support Portal.

• Migrate manually with the APIs: Follow the steps below.

Manual migration

1. Create entities on the destination first

Create the following in this order, so worklogs can be linked to them on import:

1. Teams

2. Accounts

3. Workload schemes

4. Holiday schemes

5. Work attributes

6. Worklogs

7. Plans

2. Handle user mapping

If users have different email addresses on the destination, their Atlassian account IDs will differ. There is no automatic mapping. Replace the source account IDs with the destination account IDs in the exported data (worklog authors, team memberships, and so on) before importing.

3. Export, clean up and import worklogs

Worklogs copied by Atlassian (Jira worklogs)

• Tempo keeps the original Jira creation timestamp (created) and work start date (started). It does not replace them with the migration date.

• The author is whatever Jira returns on the worklog. For Tempo-created worklogs this is the “Tempo Timesheets” app user, not the real owner, and Tempo can’t recover the real owner from it. Only the Tempo REST API export has the real owner and description.

• This is why we recommend deleting the migrated Jira worklogs and importing the Tempo export instead.

Worklogs imported through the Tempo REST API

• The real author is set with authorAccountId, which must be the account ID on the destination site (see user mapping above).

• The original creation date can’t be set. The worklog endpoint has no created or createdDate field, and Tempo ignores any such field in the payload. Tempo sets the creation time at import. Only the work date (startDate and startTime) can be set.

Summary: Real author and description require the Tempo REST API import, and the original creation date is lost. Keeping the Jira worklogs retains the original dates but loses the real author.

1. Export Tempo worklogs from the source instance with the Tempo REST API. Tempo worklogs live in a separate database, and only limited, anonymized worklog data is synced back to Jira (Jira has no information about the worklog owner). The Tempo REST API is the only way to export worklogs with the real owner and description.

2. Delete the migrated Jira worklogs on the destination with the Jira REST API. Jira worklogs are copied with the issues regardless of migration method, so skipping this step creates duplicates.

3. Import the exported worklogs into the destination instance with the Tempo REST API.

Before you start

• Make sure Timesheets by Tempo is installed and has an active license on the destination site.

• Freezing time logging on the source during the move isn't required, but is recommended so the exported data stays consistent.

Related links

• Tempo Cloud REST API

• Jira Cloud REST API

• Tempo Partner Directory