Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


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
Community Members
Community Events
Community Groups

Migrating Issues and Maintaining Issue Keys

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?


  • 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?"

2 answers

1 accepted

0 votes
Answer accepted
Daniel Ebers
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Sep 08, 2021

Hi @Henry Chad Apale + @Sue Hannan

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


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

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?

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events