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 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 need to create the same settings on the target Jira manually.

We have plans to improve REST API capabilities to read Timepiece settings from the source system and develop new REST API capabilities to write these settings to the target system. We'll update this document as parts of this become available.

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 Jira administration section).
  • Jira admin needs to manually copy these configurations to the target Jira Cloud instance through Jira Admin UI.
• 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.
  • There is currently no way to automatically or manually move these to the target cloud environment.
  • Users on the target system will need to re-create them.
• 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 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 field 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.

• Even when Timepiece has an automated cloud-to-cloud migration function, most likely, customers will be required to manually prepare mapping data to translate IDs between source and target systems.

Support

For any more questions or support requests, please reach us through https://appsupport.obss.tech/ or send an e-mail to appsupport@obss.tech.