Ran into a bit of a hairy situation regarding migrations and keeping issue-keys the same.
Context: We are planning to migrate a next-gen, team-managed project to a classic, company-managed project to enable more features for the customer.
1. Issue-key should remain the same.
2. Issue-key numbers should remain the same
3. Contents of issues should not be touched, including custom fields, workflow, and Developer data from Github.
Proposed solution: Bulk-update issues to move from original next-gen project (ABC) to new classic project (EFG). Then delete original project, and rename EFG issue key to ABC.
1. If ABC-123 becomes EFG-456 and ABC-789 becomes EFG-123, then EFG is renamed to ABC, what happens to ABC-123? does it redirect to EFG-456? With the link alias be broken?
2. Confirmed with testing that bulk-moving issues does NOT retain the the issue-key numbers. Is there a way to retain the original numbers of these issue-keys? And if it's through exporting issues and importing them via CSV, what fields are required to migrate to make this work? (issue-key, issue-id, parent-id, Github?)
3. Will this break existing Github/JIRA connections that are tied by JIRA issue-keys?
I don't have an answer, but I too want to migrate from next gen to classic however, I am creating all my custom fields in classic in order to map things properly. My biggest questions are:
according to the article
there is a lot to consider and some details will surely not carry over.
Even for the issue keys there are some words of caution:
Project and issue keys: Project keys are unique and can never be reused in Jira. If you migrate your issues to another project, they will get new keys and the new project must have a different key of its own. If you migrate your issues using the process above, Jira will automatically redirect any links to your old issue keys.
For issue history I see more chances that it will work - I seem to understand it is a bulk move involved which should do no harm to the history.
After all, I think testing with a demo project (you could probably do this on a Free instance if you do not want to use your production environment) could be the best option to test all cases and to see if it is suitable at all to migrate. At least it comes with a lot of tasks to do upfront (even if the most of the intended data should carry over).
Hi Jira Community! I’m Mark, a product manager working on Jira Software. Today, I’m happy to announce that we’re launching custom filters for team-managed projects. If you’ve used the quick filters...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events