Table of Contents

Restoring or Migrating Objects in issue fields - Server/DC-to-Cloud, Cloud-to-Cloud (including current instance)

After the schemas are restored, you can restore the corresponding objects in Jira issue fields. The process of the migration is identical for all the three cases:

• Restore of the schema on the current instance

• Migration of the schema from Data Center / Server to Cloud

• Migration of the schema from Cloud to another Cloud

Prerequisites

Before starting the process, the following prerequisites should be fulfilled:

• Make sure that the projects and issues are already migrated Cloud.

  • Server/Data Center to Cloud

    • Use Atlassian-recommended methods, which preserve Jira issue keys of the Server/DC issues in the target Cloud. See more details on the following page: What is Jira Cloud Migration Assistant? | Atlassian Support.

  • Cloud to Cloud

    • Use Atlassian-recommended methods, which preserve Jira issue keys of the original issues in the target Cloud. See more details on the following page: Merge multiple Jira Cloud sites | Jira | Atlassian Documentation.

      • From the available methods, Use a CSV file to import issues will not be suitable for further restoring the objects in Jira issue fields, as in this case original issue keys are not preserved!

• The user (email) indicated in the current connection must be added to the project(s) and have valid permission to view and edit.

• After backup is completed, objects in issue fields are backed up in the background. The backup status of the objects in issue fields can be checked under “Objects in issues status“ column of the “Available backups“ grid. Only after the status is COMPLETED, it is possible to start restoring objects in Issue fields. While the status is IN PROGRESS, “Restore objects in issues” will be disabled (see Restore Process). By clicking the (i) info button, you will see the number of the issues in which the objects from this schema are selected.

• 

Restore Process

After you have successfully migrated the schema either from Server/DC to Cloud, or from Cloud to another Cloud, you will see the button “Restore objects in issues“ along the corresponding schema Restores grid:

After clicking the button, you will see the popup with the prerequisites reminder, Start Process button, and link to the current instructions:

1. Validate fields to restore

After clicking Start process button, you will see the list of the Jira fields of the original Server/DC or Cloud instance, where the Asset objects from the original backup are presented:

From here you can select the fields, that you want to restore and click the Continue button. The selected fields will be checked and the validation results will be shown in the next screen.

2. Field validation results

For the selected fields you will see the validation results on the next screen:

There can be various results of the validation:

• The Asset field does not exist in the target Coud instance and will be created with the next step, if you select the field from the list.

• The Asset field already exists in Cloud, therefore there is no need to create it. No action is needed in this case

• There are more than one Asset fields with the same name name in the target Cloud instance. In such case you will not be able to proceed with the restore, until only one Asset field with the proper name remains in the Cloud instance.

  

  To deal with such an issue, you can:

  • Rename one of the corresponding Asset fields in Jira (leaving a proper name to the field, which you will use for the restore) or

  • Go to the original instance (where the backup was taken from), change the corresponding Asset field name to the unique one, backup and restore the schema again, and Start the process of Issues restore from the beginning.

If there are blocking issues with the fields, the Continue button will be disabled. After sorting the issues out and Restarting the check, if there are no issues that might prevent the restore, click the enabled Continue button to proceed to the Configuration helper screen.

3. Configuration helper

On the Configuration helper screen, you will be given the necessary information regarding the issue fields where the objects should be restored in:

If there are inconsistencies in the fields, you will not be able to proceed until those consistencies are solved. By clicking the error icon you can see the details of the error (screen above) and by clicking the downward arrow you can see the details of the field:

By clicking “Open configuration“ button you will be directed to the field configuration to accordingly configure the field before restoring.

After configuring the fields come back to the Configuration helper and click the Refresh all button. If the fields are configured properly, you will see the corresponding result:

3.1. Scoping issues for update

At this stage, you can limit the issues you want to update. This can be handy if you are updating a large number of issues and don’t have a wide timeframe. For example, you can update the only active issues or the issues for the last year. To do so, turn on the JQL toggle and enter the desired JQL to query the issues:

After typing the desired JQL, click the Validate query button to see the result:

After query validation, you will be able to see the number of the issues and open the list of the issues, if needed:

Click the Start restore button for resting the objects in the Jira issue fields.

3.2. Associated screens and request types

To simplify the configuration of the fields on the Cloud instance, you can review the Screens and Request Types, where the fields in the backup are associated with. To do so, click the “View Screens and Tabs” button above JQL scoping:

After clicking the button, you will see the delist of the fields on the two tabs:

• Screens and Tabs

• Request types

For the screens, you can view:

• Field name

• Screen name

• Tab

For the request types you can view:

• Field name

• Project

• Request type

To export the list, click the “Export“ button. The downloaded file (in .xlsx format) will contain the data organized in the same columns as on the interface.

4. Restore

After configuring all the fields, click the “Start Restore“ button. When the restore starts, you will see the following screen:

When the restore is finished you will see the corresponding message:

You can close the popup and see the restore result in the Restores, under Objects in the issues box:

Here you can see:

• When the issues' update was started

• When the issues' update was ended (the value will N/A until the process is finished)

• Status of the issues' update

  • Pending (until the process starts)

  • In Progress - you will see the number of the issues updated at the moment

  • Warning

  • Error

  • Success

• Full error log (see https://twinit.atlassian.net/wiki/spaces/IB/pages/685899777/Restore+Objects+in+Jira+Issue+Fields#Full-Error-log-of-the-updated-issues below)

• Real-time error log (see https://twinit.atlassian.net/wiki/spaces/IB/pages/685899777/Restore+Objects+in+Jira+Issue+Fields#Real-time-error-log below)

• Filter scope - JQL which was used for the issues' scoping

  

• List of the fields updated

  

• Associated screens and request types - see https://twinit.atlassian.net/wiki/spaces/IB/pages/685899777/Restore+Objects+in+Jira+Issue+Fields#3.2.-Associated-screens-and-request-types

When the process is started, if needed, you can stop the process by clicking the “STOP” button and confirming by “Yes, Stop“ button on the subsequent confirmation popup.

The corresponding actions will also be added to the audit log:

Restoring or Migrating Objects in issue fields Cloud-to-Server/DC and Server/DC-to-Server/DC

• Migration of the schema from Cloud to another Data Center / Server

• Migration of the schema from Data Center / Server to another Data Center / Server (the schemas should be initially backed-up via cloud app)

Prerequisites

Before starting the process, the following prerequisites should be fulfilled:

• Make sure that the projects and issues are already migrated to Data Center / Server.

  • Use Atlassian-recommended methods, which preserve Jira issue keys of the original issues in the target DC/Server

  • Make sure the corresponding Assets custom fields exist on the Data Center and are configured.

    • Restored schema should be filled in the field configurations.

    • Make sure the field is on the appropriate edit screen.

    • The user indicated in the added to the “Data Center / Server“ connection must be added to the project(s) and have valid permission to view and edit.

Restore Process

After you have successfully migrated the schema either from Cloud to DC/Server, you will see the button “Restore objects in issues“ along the corresponding schema Restores grid:

After clicking the button, you will see the popup with the prerequisites reminder, Start Process button, and link to the current instructions:

1. Choose the fields to migrate

After clicking Start process button, you will see the list of the Jira fields of the original Server/DC or Cloud instance, where the Asset objects from the original backup are presented:

From here you can select the fields, that you want to restore and click the Start Restore button. the restore will be started and the selected fields will be updated.

2. Scoping issues for update

At this stage, you can also limit the issues you want to update. This can be handy if you are updating a large number of issues and don’t have a wide timeframe. For example, you can update the only active issues or the issues for the last year. To do so, turn on the JQL toggle and enter the desired JQL to query the issues:

Click the Start restore button for resting the objects in the Jira issue fields. The progress and the results is identical to the details of the migration to the Cloud, see above for the details.

Repeat restore

When the objects in issues is already restored at least once from the backup, you can repeat the restore again with the last configuration, without configuring the fields from scratch. To do so, click “Objects in issues“ button again, in the “Objects in issues“ box:

On the popup, you will see “Repeat Restore“ button (this button is not visible when the objects in issues restore is not yet run from the backup):

Clicking the “Repeat restore“ button will display the configuration of the last fields restore, including used JQL and the updated fields:

Clicking the “Restore” button will start the fields update and you can check the progress in the Restores, under the “Objects in issues“ box.

Real-time error log

When the restore of objects in issue fields is started, you can monitor errors in real-time by clicking the “Real-time error log“ button:

In the displayed window you will the the errors when they appear in the process:

Since the process of the fields' update may take time, this way you can identify the errors in the process (for example, if the fields are not on the corresponding screens), stop the restore, correct the issue, and run the process again, without need of waiting the restore to be completed.

Full Error log of the updated issues

You can see the errors (if any) after updating the issues, by downloading the error log file (JSON) from the restore details:

The log will show ONLY the errors while updating certain fields. The downloaded file contains the following information in JSON format:

• IssueKey: Corresponding issue kye

• Result: will be always false for errors

• Message: The details of the error

{
    "IssueKey": "ISSUE-001",
    "Result": false,
    "Message": "The process was stopped"
}