Best Approach to Split and Copy Jira Cloud Issues into Three Projects While Preserving Data

Akshad Katke

Hi Community,

We have a Jira Cloud project containing approximately 3,000 issues, including system fields, custom fields, assignees, reporters, attachments, comments, issue links, and parent-child relationships.

Our requirement is to copy these issues into three separate Jira Cloud projects, with approximately 1,000 issues in each destination project, while keeping the original project and its issues completely unchanged.

We would like to perform this activity in a sandbox environment first and then execute it in production after successful validation.

We are considering Jira's native CSV export and External System Import approach, but we are concerned about preserving all issue data and relationships.

Could you please advise on the following?

1. Is CSV export/import a reliable approach for copying approximately 3,000 issues into three separate Jira Cloud projects?
2. How can we preserve parent-child relationships, sub-tasks, issue links, comments, attachments, assignees, reporters, and custom field values?
3. Are there any limitations with CSV import that could result in data loss or incomplete migration?
4. Would you recommend a Marketplace app for this requirement? If so, which apps can preserve the required data and relationships?
5. What is the recommended approach for testing and validating the migration in a sandbox before executing it in production?

Our primary objective is to create copies of the issues in the three destination projects without making any changes to the source project.

Any recommendations, practical experiences, or step-by-step guidance would be greatly appreciated.

Thank you!

Sami Shaik

@Akshad Katke ,

Short version: CSV is the only native way to copy (rather than move) work items on Jira Cloud, it is reliable for 3,000 rows if you prepare the file properly, and it has three hard limits you should accept before you start. Details, in the order you asked.

Is CSV reliable for this? Yes, with one design choice that simplifies your case: the importer can split one file into three spaces in a single run. Under Import data from a CSV file, the space mapping step offers Defined in CSV: add a space name and space key column to every row, and each row lands in the space it names. So you do one export, add a column that assigns each row to project A, B or C, and run one import, not three.

What survives, and the column format that makes it survive:

• Parent and child, subtasks: three columns, Work item ID (a unique sequential number per row), Work type, and Parent (the Work item ID of the parent row). Parents must appear in the file before their children. Keep a parent and all its children in the same destination space; a child whose parent is in a different space will not resolve.
• Comments: one column per comment, formatted 01/01/2026 10:10;<Atlassian account ID>;comment text. Without the account ID the comment is attributed to the importer; without the date it gets the import time.
• Attachments: an Attachments column holding a URL the importer can fetch (HTTP or HTTPS). This is the step that fails most often: a Cloud attachment URL behind your site’s login will not be fetched by the importer. Export the attachments and stage them on a web location the import can reach, then put those URLs in the file. For 3,000 items, do this for the subset that actually has attachments; count first.
• Assignee and reporter: use Atlassian account IDs, not display names or emails, so they map without a prompt. Inactive users still map by ID.
• Created and updated dates: the Date Created and Date Modified columns import, in the date format you set in the wizard’s second step. The new work items will not look “new” if you carry these.
• Custom fields: map them in the wizard; multi-value fields take one column per value with the same header. Check that every destination space’s screens and field contexts include the field before the import, or the mapping step hides it.
• Worklogs: importable, as comment;date;author;seconds.

What does not survive (plan for it, do not fight it):

1. Change history. Nothing imports it. The copies start with an empty history. If audit matters, keep the source project (you are) and link back.
2. Rank. The page says it outright: board rank is not retained. Re-rank in the destination boards.
3. Work item keys. The copies get new keys. Any key cited in a description or comment points at the source item, which still exists, so that is tolerable; but filters, dashboards and automation rules keyed to the source will not follow.

Issue links: I could not find links documented on the Cloud CSV import page today, so I will not promise a format. Test it in the sandbox mapping step first; if the mapping screen does not offer link fields for your link types, the fallback is a script against the Create issue link REST endpoint after the import, keyed on a “source key” custom field you carry across (see the next point).

Two things that make the sandbox run worth doing:

• Add a text custom field, call it Source key, to the three destination spaces and fill it with the original key on every row. It gives you a one-to-one reconciliation query after the import (project = A AND "Source key" is EMPTY should return nothing), and it is what a post-import link script keys on.
• Validate by counts, not by eyeballing: number of rows per space, number of comments per item for ten sampled items, attachment counts, parent-child counts. Write those numbers down from the source before you start.

Marketplace apps: there are clone and sync apps that copy items with links and history-like metadata, and if link preservation turns out to be a blocker in the sandbox, that is the moment to evaluate one; the gap you measured in the sandbox tells you what to test. I would run the native route in the sandbox first, because for a one-time split of 3,000 items it is usually enough, and the test costs you a day rather than a licence.

Source project untouched throughout; the import only creates. Come back with the sandbox counts if something does not reconcile and we can work out why.