Migrating Issues and Maintaining Issue Keys

[Henry Chad Apale]

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.

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

Problems:
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?

Assumptions: 

• Doing some thorough research and combing through documentation and threads, I can determine that renaming the classic project EFG to ABC may break the historical connections to the original issue, as Atlassian's logic prioritizes the active issue in the classic project, rather than the previously deleted next-gen project.
• Documentation: Migration of Jira's Historical Keys for Issues and Projects 
  
• Another thread from a Community leader confirming that "“should be aware that if you plan to re-use the old project key AAA for a different project (either renaming an existing project or creating a new one with that project key) you will effectively break this redirect for all issues that used to have an AAA issue key.  So that is one way that this commit data could be lost or even misdirected.”
  
• Thread: "If I move issues from on project to another, what will happen to my Github info?"

[Daniel Ebers · Accepted solution]

Hi @Henry Chad Apale + @Sue Hannan

according to the article

• Migrate between team-managed and company-managed projects
  https://support.atlassian.com/jira-software-cloud/docs/migrate-between-team-managed-and-company-managed-projects/

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).

Regards,
Daniel

[Sue Hannan]

Thank you, we are working on this step by step. I appreciate your feedback.

[Sue Hannan]

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:

• Can I migrate history
• Can I migrate attachments
• Can I migrate logged time
• Will linked issues still be in place
• Will sub tasks still be linked
• Will epic links carry over
• Will all my like for like fields copy over (from next gen to classic) in a csv upload?