Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,369,744
Community Members
 
Community Events
168
Community Groups

How to Migrate a Single Project from a Jira instance to another one

Dear Team, 

Need to migrate Jira tickets (a single project ) from one instance to another. Following are the requirements

a) Ticket count > 1000

b) Linkage between tickets should be retained.

c) Attachment inside tickets should be retained.

d) Comments and History inside each ticket should be retained.

 

 

5 answers

1 accepted

1 vote
Answer accepted

Hi @Pankaj Kalambe,

I am Marlene from codefortynine.

Another option would be Deep Clone for Jira.

With our app you can bulk clone thousands of issues between two or more Jira cloud instances. This is how it works:

  • Open the Deep Clone - Bulk Clone dialog from Apps > Deep Clone > Bulk Clone
  • Select the project you want to clone
  • Select "Clone to another instance" as "target project"
  • Select the instance and project you want to clone into 
  • Configure your clone

Please note that you would have to create the project with all fields, before you clone the issues to the new instance. If a certain field is not available, it's not possible to clone it.

It is also possible to remain issue links, attachments and comments. 

Since Deep Clone creates new issues in the target instance, it is not possible to keep the issue history. But it is possible to create a link between the original issue and the clone so you could get the issue history of the original issue easily.

An advantage of Deep Clone is, that we provide a detailed progress dialog of the bulk clone. So if some fields couldn't be cloned, you would get feedback about it. 

Thanks for the response. what is the cost involved in using this app ?

You're welcome, @Pankaj Kalambe

The pricing of our app depends on the size of your Jira instance. You can read more about pricing and how to calculate the costs of Deep Clone for Jira in our documentation.

Hi @Pankaj Kalambe

This is Majid @ Exalate. 

Have you considered a third party app in order to perform this migration in a customized manner. If not, I would urge you to look at Exalate that, although is a bi-directional sync solution, can be used very well in a migration use case. 

Please feel free to book a customized demo if you would like to see the product in action. 

Thanks

Majid

@Pankaj Kalambe hi there! You can take a look at ZigiOps. It's a no-code tool that can help you with your migration project - without limitation on the number of tickets you want to transfer. It's easy to use and you'll keep all the information your use case requires - linkage between the tickets, ticket attachments, comments, and history. Feel free to book a demo to see how ZigiOps can help you.

Regards, Diana (ZigiWave)

Hi @Pankaj Kalambe,

Many free and paid tools on the Atlassian marketplace can help with migrating tickets from one Jira instance to another. In your case, given the data size is not too big (1000 - 2000 tickets), it would make more sense to go with a no-cost tool that can migrate tickets with complete information to another Jira instance. One such free utility provided is Jira CSV 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 Inconsistency: 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
  • Impact on Jira: Migration activities might result in additional load (as a result 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 no-cost Community Edition that can help you transfer (by bulk update and sync strategy) 1000+ 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

hi Pankaj,

1.use export issue in excel with all field (it will only allow 1000 at a time ) so the trick is u use JQL to filter the once you already exported and then export again do same as many time as need 

2. when you import links between issue of same project retains if you properly field while importing on other instance

3.You can attach files to issues created from your CSV file. To do this, specify the URL of your attachment in an Attachments column within your CSV file.

4.can be done 

You can import multiple comments on an issue if you're using the external CSV import.  You just need to create a separate column for each comment, with the same header name.  In turn Jira will import these as separate comments.  This is explained during the import process:

 

The hard part here is making sure that your CSV file is formatted correctly.   The number of comment columns your CSV file is expected to have is dependent on the issue with the largest number of comments.   So if you have an issue that has 50 comments and that is the one with the most comments, your CSV file would be expected to have 50 comment columns in order to maintain the formatting.   Obviously the other issues won't have values for all 50 comment fields, but at least one issue would.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS

Atlassian Community Events