Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

Project Data migration from one jira instance to other including attachments

Gyana Madhuri Kyppa
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
October 25, 2022

Hi Everyone,

 

We are trying to migrate one project data from one jira instance to other jira ehich has already 3 projects including attachments.

 

Firstly we thought to create project from scratch and import tickets using CSV but unfortunately we got to know that it will not import attachments .

 

We would consider project snapshot but the version of one jira is 7.6 ours is 8.20.11

 

Can any one please help me on this.

 

Thanks,

Gyana Madhuri

3 answers

1 accepted

1 vote
Answer accepted
Radek Dostál
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
October 25, 2022

The recommended approach would be to restore the backup from 7.6 on a separate 7.6 instance - upgrade it all the way up to your destination version, and then create a new backup from that intermediate 8.20.11 instance - then you get a compatible zip.

 

With CSV, you can import attachments - https://confluence.atlassian.com/adminjiraserver/importing-data-from-csv-938847533.html

It supports http/s and file protocols.

So this is quite a job to figure out a good way to do it, but it's possible. Granted though you probably would need somebody confident with scripting to generate the .csv entries for it. Note that the url it downloads the file from in this case must be either authenticated as part of the url, or anonymously accessible. So with 7.6 this could be an issue since you cannot use any tokens in the url. In 7.6 you can still use "os_username" and "os_password" to get around the auth, although of course needless to say this is plain texted so you really only want to do this in a secure network and ideally with a discardable, temporary account. Other than that you might have to move those attachments elsewhere, could be a public apache directory, or a different server entirely. And that would also need to be done so you can clearly identify which attachments belong to which issues, so you can them use appropriate paths for each issue row.

 

So yes, it's possible, but not for the faint of heart. Unless resources are a constraint then spinning up an intermediate instance might be easier and would give you more complete data - such as history, comments, the things that CSV import doesn't support. The intermediate instance can be any spare machine/VM really - since you just need it to work, it doesn't have to lift any user traffic or be fast, so long as it won't run out of memory or disk space.

0 votes
Diana_Architect_ZigiWave
Atlassian Partner
November 11, 2022

@Gyana Madhuri Kyppa hello! I see some quite helpful options have been offered. If you'd like to try an alternative way that includes a 3rd party solution, consider ZigiOps. It can help you connect your Jira instances, sync them and transfer the data you want from one Jira to the other - project data (tasks, bugs, changes, incidents, comments, attachments, etc.). Have a look at it and if you'd like to see it in action, you can book a technical meeting

 

Regards, Diana (ZigiWave team)

0 votes
Brad Peterson
Contributor
November 10, 2022

Hi @Gyana Madhuri Kyppa

Many free and paid tools on the Atlassian marketplace can help with migrating Jira tickets from one Jira instance to another. As you are migrating only one project as a one-time activity, it would make more sense to go with a free tool that can migrate Jira tickets with complete information to another Jira instance. One such free utility provided is Jira CSV export and import, but as mentioned in one of the above replies, it must be done very carefully to ensure complete migration while maintaining data integrity. Additionally, here are a few factors that should be considered, as they often cause trouble during the migration process: 

  • Disruption to user operations: Some migration tools can create disruptions and impact productivity. Some may require the project or the Jira instance to be in read-only mode for an extended period. The cost and impact of disruption should be factored into the plan. 
  • Field Template In-consistency: Analyze if there is any field scheme configuration difference between your source and target Jira instance. If there is, make sure the tool you choose can bridge those differences. 
  • Loss of entity context and activities: Understand whether the tool migrates the tickets with history to prevent loss of data 
  • Impact on Jira: Migration activities might result in additional load (because of bulk data read or write) on Jira servers. Proper planning should be done to ensure appropriate scaling of the Jira server and isolation of migration load so that the regular activities are not impacted.

OpsHub, an Atlassian Partner, offers a free Community Edition that can help you transfer (by bulk update and sync strategy) Jira tickets along with comments, attachments, and history (as comments). Community Edition offers zero-downtime data transfer and allows you to handle any field template inconsistency across the source and target Jira instance. Additionally, feel free to reach out for an initial free consultation on migration planning with OpsHub’s Migration Experts.

Thanks

Brad

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events