Having trouble exporting a project from a JIRA instance

[Marcia Peterson]

Need to export a JIRA project from a JIRA instance that has other JIRA projects for other customers.  How to ensure not to cross contaminate project exports?

[Trudy Claspill · Accepted solution]

Hello @Marcia Peterson 

Welcome to the Atlassian community.

What problem are you trying to solve with this export? What do you need to do with the exported data?

What data are you trying to export? The issues in the project? The History information for each issue? The comments associated with the issues? The project configuration?

In what manner do you think there could be cross contamination of data? Are the issues in this project linked to issues in other projects?

[Marcia Peterson]

Hi Trudy,

Appreciate the quick response and great questions.

The data lives in a partners Jira instance.  We need to receive it in a manageable format to upload it to another Jira instance of similar environment.  

We need the issues, the history for each, the comments associated with each as well as any attachments.  We do not need the project configuaration.

The partner we are working with is stating they can't separate our information from other customers even though when viewing the project no other customers information is appearing.

[Trudy Claspill]

Hello @Marcia Peterson 

Thank you for that additional information.

Do you know the project type?

• Service, Business, or Software
• Team-managed or Company-managed

Have you been accessing the data through a Customer Portal or through the Jira UI itself? Are you licensed users of the partner's Jira instance, or are you customers of their Jira Service Management portal? This can affect the options available for you to get the data.

In addition to what @Himanshu Tiwary , another consideration is that your data might be contained within a project that they use to track items for multiple clients. Depending on the project type and the security measures they have in place, they could do that and prevent one client from seeing the data (in the same project) that belongs to another client. That can also make it more difficult to extract just your data.

If your data is in its own project, and if that Jira instance is a Jira/JSM Cloud instance, and if your destination instance is a Jira/JSM Cloud instance, another option would be to work with the partner on a Cloud-to-Cloud migration of the one project. That is only viable if your data truly is in a separate project.

I recommend that your company review your contract with the partner to see what it says about your entitlement to get a copy of the data, and what is included in that.

[Marcia Peterson]

Hi Trudy,

It is a software space - team managed, accessed via the Jira UI.

Our data is in its own project, accessed via the cloud.

Will suggest the cloud-to-cloud migration which will require we contract for our own Jira instance or use our new partners.  

Our contracts covers our entitlement to our data, legal teams working on that.

Thank you,

Marcia

[Trudy Claspill]

Moving to another Jira instance that is managed by another entity adds difficulty to a cloud-to-cloud migration.

Such migrations can be executed only by individuals that have Organization Admin and Jira App Admin access in both Organizations/Jira sites. You may have difficulty getting two partners to agree to this arrangement.

Documentation on the process can be found here:

https://support.atlassian.com/organization-administration/docs/copy-product-data/

You may need to set up your own intermediate subscription to Jira, giving designated individuals from your current partner Org Admin access so they could migrate the project to it. Then remove their Org Admin access and give your new partner Org admin access to it, so that they can then transfer the project into their Organization.

Did this request for your data come from a conversation with your new partner? They may have been through this before, and may be able to help you have this conversation with your current partner.

[Marcia Peterson]

Thank you Trudy for all of your replies and guidance.  Very helpful.  The request is internal.

[Paul Glantschnig _Appfire_ · Accepted solution]

Hi @Marcia Peterson ,

Lots of good advice in this thread already. Just wanted to add a practical note on the data completeness side of things.

Whichever route you go — CSV export, REST API, or cloud-to-cloud migration — one thing that often gets overlooked is verifying what you're actually moving. Jira projects accumulate a lot of field data over time (custom fields, linked issues, attachments, comments), and it's easy to miss gaps until someone asks "where did that data go?" weeks later.

A few tips:

1. Before you export, get a complete inventory of the project. Run a JQL query like project = "YOUR-PROJECT" ORDER BY created ASC and review the issue count and field coverage. Make sure you know which custom fields have data — some may have been added after the project started and only apply to newer issues.
2. After import, do the same count and spot-check a sample of issues across the timeline. Compare field values, comment counts, and attachment counts against the source. Issues that were created early in the project's life are the ones most likely to have missing data.
3. For history and comments specifically, the CSV export won't capture these. If the cloud-to-cloud migration path doesn't work out (cross-org access can be tricky as Trudy mentioned), the REST API is your best fallback — GET /rest/api/3/issue/{issueKey}?expand=changelog,renderedFields gives you the full history per issue, and /rest/api/3/issue/{issueKey}/comment gets all comments.

On the topic of getting that complete picture of your project data — if you have access to install apps on the source instance, even temporarily, you might find JXL for Jira useful for this kind of audit. It gives you a spreadsheet-style view of all your project's issues with every field visible in one table — custom fields, linked issues, parent relationships, comments, attachments, etc. That makes it straightforward to verify what data exists before export and confirm nothing was lost after import, without having to click into issues one by one.

Disclosure: I work for the team that builds JXL.

Cheers, Paul

[Marcia Peterson]

Hello Paul,

Appreciate the weigh in and the additional information/options.  I have plenty to work with here - such a great community!!

Marcia

[Arkadiusz Wroblewski · Accepted solution]

Hello @Marcia Peterson 

You do have a few options here, depending on what exactly you need to preserve.

If you only need the issue data, a project-scoped CSV export/import is the simplest option.

If you need a more complete Cloud-to-Cloud move, I would check Atlassian’s copy/migration tooling first, especially if this is a team-managed Jira Software project.

If you also need attachments or a more complete handoff, then a simple CSV export is usually not enough by itself.

With that answers you provided to @Trudy Claspill , only one viable option I see are Cloud to Cloud migration.

[Marcia Peterson]

Understood and much appreciated!!

Marcia

[Himanshu Tiwary · Accepted solution]

Hi @Marcia Peterson ,

Welcome to the community!!

What your partner says is true if they are talking about a full Jira site backup/export — that type of export is not really meant to hand over just one customer’s project cleanly, and it can include data beyond a single project. Atlassian’s backup/import docs are site-level, not “safe single-project handoff” tools.

But if your data is already isolated in its own Jira project, then they should be able to give you a project-only extract of the issues by filtering on that project and exporting the issue data. Jira’s CSV export can include issue fields and comments.

The important limitation is this: CSV export/import is not a full-fidelity project migration. It is fine for issues and comments, and attachments can be imported with extra work, but it does not behave like a true project transfer with complete history/changelog preservation. Atlassian documents separate processes for comments and attachments during CSV import, which is usually a sign that this is a staged migration approach rather than a “lift and shift” project export.

So I’d reply to the partner along these lines:

If you mean a full Jira backup/export, then yes, I understand why you can’t safely separate only our data from other customers.
But if our work is contained in its own project, you should still be able to export just that project’s issues using a project-specific filter/export.

The bigger concern is not “cross contamination” at that point — it is that CSV export/import won’t fully preserve everything, especially full issue history/changelog. Comments are exportable, and attachments are possible with additional steps, but this is not the same as a complete project migration.

So the real question is whether we want:

a project-scoped issue export for business data only, or

a true migration approach if preserving history and attachments exactly matters.

In other words: they are probably correct about full backup exports, but not necessarily correct that your project data cannot be separated at all.

[Marcia Peterson]

Fantastic response, I will let you know how it turns out.

Many thanks,

Marcia

[Aron Gombas _Midori_]

@Marcia Peterson If you take this route, then you can use the Better Excel Exporter to export work items, with their change histories, comments, worklogs, etc. You can then convert the Excel file to CSV.

[Marcia Peterson]

Aron - good to know!!  

Marcia