Migration Notes
Before Migrating
Before migrating to Cloud, there are a few things you should check.
There are some differences between the features available on Data Center/Server and Cloud. We strongly encourage you to review our Feature Comparison and Formula Comparison charts.
Large structures - There is a 30,000 issue limit for any structure on Cloud. If you currently have structures with more than 30,000 issues, you should optimize those before updating: adjust the generators to include fewer issues, split them into multiple smaller structures, etc. If it's not possible to split generators, our support team can assist you with raising the issue limit for Cloud. You can contact them at Tempo Support.
Manual adjustments - Manual adjustments are not supported in Cloud. The structures will still migrate, but any hierarchies you've created using manual adjustments will be removed and appear as a flat list of issues (or the way they originally looked before manual adjustments were applied).
Permission to create new structures - Structure on Cloud does not yet support restricting the ability to create new structures for certain users or user groups. Any logged-in user with access to the Structure app can create new structures of their own.
Views - Only views that are associated with migrated structures are migrated, and sharing permissions are not migrated.
We highly recommend performing an audit of your structures before starting the migration process. This can help ensure a clearer transition to a Cloud instance, without unnecessary or obsolete data. Using the Manage Structures page, you can see which structures were recently used and if there are manual adjustments, effectors, or synchronizers enabled. Unused structures or structures with inactive owners can also be spotted, archived, or deleted in bulk using groovy scripts.
After Migrating
After migrating, please be aware of the following:
Structure permissions (view, edit, automate, and control) and view permissions are handled differently in Cloud, so you may need to reconfigure these after the migration. Structure Cloud will attempt to use the existing DC/Server permissions if all of the following conditions are true:
All permission rules are Set rules (not copied from another structure).
All users, groups, or project roles mentioned in every permission rule can be mapped to a new user, group, or project role in Cloud.
Levels of the permission groups form a non-decreasing monotonic sequence (each permission group is greater than or equal to the previous permission group).
To configure or update a structure's permissions, locate the structure on the All Structures page, click Configure, and update the permission settings.
It's normal for your Structure Selector menu to be empty immediately after migrating. This is usually because there are no recently used structures and/or permissions have not been configured for the migrated structures. Jira admins can view the migrated structures and assign permissions on the All Structures page.
You can migrate Notes columns from your DC Structure to Cloud, but those columns will appear in Cloud as empty Flex Field columns. To repopulate the Flex Field column with your migrated data:
Click the column name and select Edit column.
Open the Text Field dropdown.
Under Context Fields, select the migrated data to populate the Flex Field column. Data from the DC Structure contains a (migrated) prefix.
In order to determine which Jira users have access to Structure, you should configure Global Permissions in Structure Cloud.
If you reset and delete Jira data from your cloud site, your structures will not be deleted. This is because our data is stored differently from Atlassian’s, so even though the data that Structure relies on (projects, users, permissions etc.) is deleted, the structures themselves will remain undeleted. NOTE: this could result in duplicate structure if you’ve performed multiple test migrations.
Additionally, we highly recommend you review each migrated structure following Step 7 in our Migrating to Cloud guide.