Server/DC to Cloud Migration with JCMA

Summary

Timepiece is fully compatible with Atlassian’s Jira Cloud Migration Assistant (JCMA). This means your Timepiece configuration and data can be migrated from Jira Data Center to Jira Cloud automatically using JCMA.

Timepiece enables advanced historical reporting by analyzing Jira issue histories in detail. To ensure accurate and consistent results, issue data and history must be migrated reliably. 

Prerequisites

JCMA migration is supported only if your Jira Data Center instance runs Timepiece version 6.3.1 or later.

We strongly recommend upgrading Timepiece to the latest version before starting the migration.

Feature Compatibility

Please see the Server/DC and Cloud Feature Comparison document for a detailed feature comparison between Timepiece Server/DC and Cloud.

Migration of Jira Issues and Issue Histories

Jira issues and their histories are migrated by JCMA itself. Timepiece has no control over this part of the migration.

Timepiece reports are generated based on Jira issues and their histories. In most cases, Jira entities (projects, issue types, custom fields, users, etc.) will have new IDs in the cloud environment. During migration, JCMA updates all references to old IDs in Jira configuration with the new IDs.

If issues and issue histories are migrated correctly by JCMA, Timepiece reports in Jira Cloud will work correctly with migrated data.

However, sometimes JCMA may not migrate issue histories correctly.

There was a known bug in older versions of JCMA (explained in the info box below) that caused corrupted histories, but this can happen even if you are using the latest version of JCMA. In most cases, this is data-dependent. For example, while creating new projects, issue types, custom fields, etc, on your DC environment, if you used the names of similar entities deleted in the past, you might encounter such corruption. (This is just an example, definitely not the only cause.)

Unfortunately, Timepiece has no control over the migration of this data, so it has no chance to correct these corruptions.

If issue histories are not correctly migrated to the cloud, any reports that depend on this data will potentially produce inaccurate results. This may include some built-in Jira reports like burndown charts, cumulative flow diagrams, some built-in Jira gadgets, etc.

The Timepiece reports you get in the cloud that are using corrupt histories of issues migrated from the DC will also be inaccurate. For some types of corruption, Timepiece can detect them and display warning messages in the UI for corrupted issues. For others, Timepiece can’t detect them. It will try to process the histories as if they are correct, and this will result in inaccurate report calculations.

Please refer to the “Post-migration checks and validation” section below on how to check for this type of corruption.

Even when migrated issue histories are corrupted, Timepiece reports based on issues created in the cloud environment (issues that are created AFTER the migration) will be fine.

What is migrated?

The following components are included in the automated Timepiece migration via JCMA:

• Access Settings

• Format Settings

• Calendars

• Saved Parameter Sets

Access Settings

Group-based access settings of Timepiece defined in the Data Center environment are migrated to the Cloud.

If a group from the original access settings does not exist in the Cloud environment, the data will still be migrated, but a warning will be logged in the Timepiece migration log indicating the missing group.

Format Settings

Date format and date-time format configured in Timepiece are included in the migration.

Calendars

All custom calendars configured in Timepiece are fully migrated to the Cloud environment. During migration, all calendar definitions (working days, hours, breaks, holidays) and their associated time zone settings are preserved to ensure continuity in report results.

Saved Parameter Sets

Saved report configurations (report type, filters, groupings, columns, calendar settings, etc.) are migrated in bulk.

If a saved parameter set includes references to projects, users, groups, etc. that are not migrated to the Cloud, those parameter sets will be migrated, but reports using those sets may not load successfully.
If the user who owns a parameter set does not exist in the Cloud environment, the owner field will be empty in Cloud.
These issues are logged in detail in the Timepiece migration log file. Please review this log after migration.

You may see similar messages in your log file for unmapped status, project, user, or group values. These indicate that some field values from the Data Center environment could not be resolved in the Cloud instance, but the parameter set will still be migrated with the original values.

What is not migrated?

Dashboard Gadgets

Currently, JCMA does not support the migration of app-specific dashboard gadgets. As a result, Timepiece dashboard gadgets and their configurations will not be migrated. The gadgets in the DC environment will need to be manually re-created in the cloud environment.

Repeated Migrations & Overriding Behavior

If you perform multiple migrations from the same Data Center instance to the same Jira Cloud site using JCMA, the following Timepiece configuration components will be overwritten during each migration:

What gets overridden?

⚠️ Important Note: Timepiece treats items with matching names as equivalent — regardless of whether they were originally migrated from DC or manually created in the Cloud.
As a result, manually created Cloud items may be unintentionally overridden if they share a name with an item from the Data Center source.

This mechanism ensures consistency, but we recommend reviewing Cloud configurations before repeating a migration to avoid overwriting manually created content.

Post-migration checks and validation

To validate a successful migration of Timepiece data, check the items below:

• Use the Jira admin pages to manually (visually) compare the Timepiece settings between DC and Cloud environments. If you find discrepancies in any of these, you’ll need to manually correct the configuration on your Jira Cloud instance.

  • Access Settings

  • Format Settings

  • Calendars

• Manually prepare Timepiece reports using your saved parameter sets to make sure they work as expected.

  • This process may be time-consuming, but it is the most reliable way to validate the results.

  • After the migration, when you try to load a parameter set that contains references to Jira entities not present in the cloud, the parameter set will still load, but will display a warning banner that says some of the parameters were not loaded successfully. In that case, the browser console will have detailed messages about which parameters were not loaded. In such a case, you can manually correct the corrupt parameters in the Timepiece UI and save the parameter set with the same name (overwrite it) to correct it.

• Compare the DC and Cloud results of a group of pre-selected Timepiece reports to confirm that issue histories are migrated correctly.

  • The choice of reports to validate depends on your data and configuration, but we recommend checking at least one report from each report type. Comparing both List and Aggregate (Average, Sum, etc) reports is recommended.

  • Try to compare reports covering different projects with different configuration histories.

  • See the “Migration of Jira Issues and Issue Histories“ section above to understand why you need to make this check and why issue histories might be corrupt.

Migration Support

If anything goes wrong, you can reach us through our Support channels.

Please include the following information in your support request:

• Your Jira Cloud instance URL (xxx.atlassian.net) and the date/time of migration (so we can check our service logs for any error messages on our side).

• JCMA logs related to Timepiece (if available).