Integrate with Deep Clone to preserve Xray data when cloning Projects

Problem statement

Users need a reliable way to transfer Xray data from one Jira Cloud project to another within the same instance, while preserving Xray-specific entities and relationships (e.g., Tests, traceability links/coverage, and, where applicable, Test Sets/Plans/Executions).

Today, typical “copy/clone/move project content” approaches in Jira Cloud don’t provide a built-in, Xray-aware project copy mechanism, and Atlassian explicitly notes Jira Cloud does not directly support copying projects. As a result, teams trying to replicate or move testing assets across projects frequently end up with missing or broken Xray coverage/traceability, and must fall back to manual export/import or API scripting.

User friction

Users expect cross-project duplication/migration to keep Xray coverage & traceability intact.

In practice, Xray-specific associations are not preserved by common project/issue copy flows, so the destination project loses key test management context.

There is no simple “transfer Xray data to another project” flow, teams must orchestrate multiple steps (exports/imports and/or APIs). Xray’s own guidance for migration emphasizes manual exports/imports rather than a single automatic process.

This becomes time-consuming and error-prone at scale (large test repositories, complex requirement→test link structures, audits).

Steps to reproduce (workflow)

1. In Jira Cloud, select a source project containing Xray-managed testing assets and traceability (Requirements/Stories linked to Tests, etc.).

1. Attempt to move/replicate that content to a different project (e.g., via cloning apps, bulk copy approaches, or other “project copy” workflows). Jira Cloud doesn’t directly support copying projects, so customers often rely on Marketplace apps for this use case.

1. Review the destination project’s Xray relationships and coverage.

1. Observe that Xray-specific data transfer is incomplete (missing links/coverage and related test management context), requiring manual rework.

Impact

What would improve if solved

• Users can confidently transfer Xray assets + relationships project-to-project without rebuilding coverage.
• Reduced errors and rework; faster cross-project rollouts and reorganizations.
• Better consistency in reporting, audits, and stakeholder exports across projects.

Impact on stakeholders

• Test Managers, QA Engineers, Project Leads, Compliance/Audit stakeholders
• Any team that needs to replicate or migrate testing scope across projects (reorgs, new product lines, customer onboarding, portfolio splits, shared test libraries).

Current workaround

• Manual export/import using Xray features like Document Generator + Test Case Importer.
• Custom automation via REST/GraphQL to recreate entities/links (requires engineering effort and maintenance).
• Post-migration cleanup to reconcile coverage gaps and broken traceability.

CONTEXT & EXAMPLES:

Concrete example: A QA lead needs to move a mature set of Tests + requirement coverage from Project A to Project B (same Jira instance) due to a program split. They expect requirement↔test relationships to remain accurate. Instead, the destination project ends up missing or inconsistent traceability, forcing a manual export/import and link reconciliation.

Also, from the support ticket that recommended this: A team wants to build reusable Jira project templates and/or duplicate work across projects without losing Xray metadata. 

Workaround risk: Manual reconstruction can introduce discrepancies (missed links, duplicated tests, incomplete mapping), which is especially risky for regulated reporting where traceability must be exact.