Cloud to Cloud Migration

If you are a Timepiece - Time in Status for Jira by OBSS user and planning to perform a Jira Cloud to Cloud migration (as explained here), you should know the following:

Migrating Data

Timepiece prepares its reports based on Jira issue histories. Jira issues and their histories will be migrated as part of your base Jira migration. You won't need to take additional steps about issue migration regarding Timepiece. (But you must pay attention to the warning at the end of this document)

Timepiece itself does NOT store your Jira data, but it has a few app-specific settings. Settings like param sets, permissions, calendar definitions, gadget definitions, etc. 

Currently, there is no automated way to make cloud-to-cloud migrations for Timepiece settings. Customers either need to create the same settings on the target Jira manually or use the REST API to build their own automations to migrate Timepiece settings from the source Jira to the target Jira.

Manual Migration Checklist

• Timepiece has its own Calendar, Format, Access Permission settings.

  • Admin pages for these settings can be found in Timepiece Admin pages (under the Jira administration section).

  • Either the Jira admin can manually copy these configurations to the target Jira Cloud instance through the Jira Admin UI

  • Or, the REST API provides endpoints to read and write Custom Calendars and Format Settings, which can be utilized to build automations to migrate these settings from source Jira to target Jira.

• Timepiece users might have saved some Parameter Sets.

  • From Timepiece UI, each user can see his/her own param sets and the ones that are saved as public.

  • Jira admin can get a list of all saved param sets (of all users) and their details using the Get a List of Parameter Sets REST API endpoint.

  • Either users on the target system can re-create them manually

  • Or, the REST API provides endpoints to read and write Parameter Sets, which can be utilized to build automations to migrate these settings from source Jira to target Jira. (Pay attention to the warning about IDs at the end of this document)

• Timepiece users might have used Gadgets on their dashboards.

  • The gadgets and their configuration are saved by Jira. Timepiece doesn't store this information.

  • The gadgets will also need to be manually recreated on the cloud instance.

• There might be integrations built via Timepiece REST API to get Timepiece data from the source Jira (for custom reporting, BI integration, etc).

  • The same REST API will be available for the target Jira instance as long as Timepiece is installed. You will need to update the Authorization configuration. You might also need to make adjustments to your integration config, according to the new IDs on the target system.

Warning about IDs

Jira entity IDs (project, status, field, resolution, etc. IDs ) are almost certain to change during a cloud-to-cloud migration. Timepiece Parameter Sets created by users reference these IDs.

Atlassian doesn’t give (to customers or apps) the mapping of old and new IDs. This has two implications:

• If said IDs in Jira issue histories are not updated properly during cloud-to-cloud migration, issue histories for migrated issues will be corrupt. Timepiece reports (or any other Jira function that depends on these histories) will fail or will be inaccurate.

• If customers choose to build their own scripts/automation to migrate Timepiece Parameter Sets using the aforementioned Timepiece REST API endpoints, they must make sure that the IDs are properly updated for the target Jira.

Support

For any more questions or support requests, please reach us through our support channels.