Leave No Assets Behind: How to Clone Work Items and Relink Jira Assets Across Jira Cloud Instances

[#1]

A step-by-step guide to Jira Cloud instance migration: clone work items and restore Jira Assets without manual relinking.

In enterprise Jira Cloud environments, it’s common to operate multiple instances that eventually need to be aligned or consolidated. This is often driven by standardization, organizational change, or the need to reduce duplication and complexity. Standard cloning between Jira Cloud instances typically breaks Jira Assets references. In practice, successful instance-to-instance replication requires more than work items. Teams also need to migrate space structures, service desks, and the related Jira Assets data reliably, without data loss or manual workarounds.

This article shows instance-to-instance cloning in Jira Cloud, with a specific focus on relinking Jira Assets fields in cloned work items.

The following scenario uses a fictional company “CloudMerge Inc.” for illustration.

To make it tangible, we’ll walk through a fictional example: CloudMerge Inc. is consolidating two Jira Cloud instances as part of a company-wide effort to optimize operations following a recent acquisition. The team needs a repeatable approach that covers both layers of the migration: cloning work items across instances, and restoring the associated Jira Assets data so that asset fields in the cloned work items remain usable.

To achieve this, the team combines two Atlassian Marketplace apps: Deep Clone for Jira (for cloning work items and entire spaces, across instances) and Insight Assets Backup & Migration (for backing up, migrating, and restoring Jira Assets data). Together, these two apps cover both parts of the workflow: cloning work items and restoring/relinking Assets data.

What we’ll achieve

• Clone work items across Jira Cloud instances

• Restore or migrate the required Jira Assets schema(s) and objects

• Relink Jira Assets fields in cloned work items — with no manual relinking

Prerequisites

Before you start, make sure the following prerequisites are in place:

• Deep Clone for Jira is installed on the source and target Jira Cloud instances 

• Insight Assets Backup & Migration is also installed on the relevant instances

• You have admin permissions to create a custom field and add it to the appropriate screens

• You have a clear migration scope, including:

  • which spaces and work items to replicate

  • which Jira Assets schema(s) are involved

  • which Jira Assets fields need to be restored

Step-by-step guide

Step 1: Create a custom field to store the source work item key

On the target instance, CloudMerge Inc. creates a custom text field to hold the original work item key from the source instance. This field will later be used to match and re-link Asset data.

• Suggested field name: Source Work Item Key or Original Work Item Key

• Field type: Text (single line) aka Short text (plain text only)

• Screens: Add the field to all relevant screens used during cloning

Outcome: Every cloned work item will carry a stable identifier that references its original source work item.

Step 2: Clone work items with Deep Clone for Jira

Next, the team uses Deep Clone for Jira to perform the instance-to-instance clone. During this process, they ensure that each cloned work item stores the source key in the custom field. Deep Clone can handle large volumes, run in the background, and provides detailed logs to help teams resolve problems early.

• Map the original work item key into the custom field created earlier using the Jira expression “issue.key” (Copy the value of a field to another field)

Outcome: All cloned work items now exist on the target instance and contain a reference to their source work item key

ℹ️ In Jira Expressions and APIs the object is still called “issue”, even if the UI uses “work item”.

Step 3: Back up Jira Assets on the target instance

Before restoring Jira Assets references, the team creates a backup of the required Assets schemas directly in the target instance, using Insight Assets Backup & Migration.

• The backup includes the schema(s), object types, objects, and structure relevant to the Asset fields used in the cloned work items

• This backup will serve as the restore source in the next step

Outcome: A complete and restorable snapshot of the necessary Jira Assets is available within the same instance where the cloned work items are now located.

Step 4: Start the Jira Assets restore process in the target environment

With the backup complete, the team starts the restore process in Insight Assets Backup & Migration:

• Open the backup created in Step 3

• Select it and begin the restore process

• Proceed to the section where work item matching is configured

Outcome: The restore process is now ready to match cloned work items and relink Asset fields.

Step 5: Configure the Work Item Identifier 

CloudMerge Inc. configures the restore process to match cloned work items using the custom field created in Step 1:

• Choose “Custom Field” as Work Item Identifier

• Select Custom field that contains the source work item key

• Match the original work items with the cloned work items and the Asset references with the correct target work items

• Select the relevant Asset fields that should be restored in each work item

Outcome: The app now knows how to link cloned work items back to their original Jira Assets using the preserved key.

Step 6: Validate Fields and Restore Jira Assets

With everything configured, the team can validate the outcome by checking a small, representative sample of work items.

• Validate Asset fields to restore

• Optional: Limit the Issue Scope to test the restore on a sample set of work items

• Start the restore process

Outcome: The team has a proven, repeatable process, ready for full-scale execution:

• Work items are successfully cloned

• Asset fields in cloned work items are correctly restored

• Objects remain consistent with the source environment

• No manual relinking

Security & Compliance

For CloudMerge Inc., functionality alone isn’t enough. The migration approach also needs to meet strict internal security and compliance standards. With sensitive data involved, the tools have to be trustworthy and enterprise-ready.

Both apps used in this workflow meet high standards for cloud app reliability, support, and security:

✅ Deep Clone for Jira 

• codefortynine Trust Center

• SOC 2 certified and Cloud Fortified for enhanced security across all environments.

• Offers flexible data residency options, allowing teams to keep data in the EU or US

• Supports Atlassian Government Cloud deployments

• Participates in Atlassian’s bug bounty program with regular vulnerability testing

• No external data sharing and full adherence to GDPR

✅ Insight Assets Backup & Migration

Committed to keeping your Jira Assets safe. The app protects critical Assets with enterprise-grade standards and full compliance with:

• Twinit Trust Center

• ISO/IEC 27001:2022

• Cloud Fortified

• Participates in Atlassian’s bug bounty program with regular vulnerability testing

• CSA STAR

• Performs regular penetration tests and ensures encryption of all data in transit and at rest

• No external data sharing and full adherence to GDPR

Wrap-up: Jira Cloud Migration with Jira Assets Relinking

This two-step pattern, cloning work items with a preserved key, then restoring and relinking Jira Assets, gives CloudMerge Inc. a repeatable, enterprise-ready way to migrate Jira Cloud data across instances with confidence and no manual relinking.

Want to test this workflow in your environment?

Start with the Deep Clone for Jira Get Started guide and the Insight Assets Backup & Migration Get Started guide , then run a small pilot migration to validate the workflow.