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.
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:
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.
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.
@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:
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.
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.