Migrating issues between two projects in the same Jira cloud instance

[János Hinkel]

Hello Community!

I did find questions and answers to this topic but haven't found a fresh topic on this, so this is why I'm asking.

Our client asked us to move issues from an existing project to a new one while keeping the issue ID's.

My questions would be:

- Issue ID's and Issue Keys are not the same in the background, right?

- If the issue key changes from AAA-123 to BBB-456, will the ID remain the same in the new project?

- Can it be confirmed that all the connected development data (commits etc) will be linked and will work from the new project as well?

- Can an addon or app assist us in this task?

Thank you very much for your answers!

Cheers

János

[Vish Reddy _Revyz_]

Hi @János Hinkel 

We have built a feature in our app Revyz Data Manager for Jira to be able to clone configuration from one cloud site to another in a granular manner, we are adding in the capability to clone issues across cloud sites next. I would love to get your feedback on what we have built if you are open to it.

Please let me know if you are open for a meeting.

Thank you

Vish

[János Hinkel]

Hi Vish!

Thanks for your offer i will get back to you after the holidays.

Best

János

[Nic Brough -Adaptavist-]

Welcome to the Atlassian Community!

The main part of the answer is a simple "use the 'move' option to move issues between projects"

Issue ids (which humans barely see when using Jira, they're the unique ids in the database) will not change.  The keys will.

The new key for any moved issue will be the new project key and the next number in the sequence. 

Connected development data will remain as it is, but you should check that the target project is configured the same way as the source in order to continue to use it

You don't need apps to do a move, it's built in.  However, with team-managed projects, you may want to look for one to make the field data carry over (team-managed project fields currently do not migrate, as the project fields are local to each project.

[János Hinkel]

Thanks Nic!

However, moving might not be the best option as we discuss over 2000 issues. What if we bulk clone them will the connected data remain and function in the other project? We are looking to use Deep clone addon for this purpose.

Thanks a lot again!

[Nic Brough -Adaptavist-]

Cloning them is probably more effort that moving them.  You can bulk-move up to 1,000 issues at a time, and it's very easy.

The problem with cloning is that, yes, you can keep the link back to the original, but what happens if people carry on using the old project?  Your projects will drift off, existing issues won't be updated at the other end of the link unless you set up automations or syncs.

If you move the issues though, you don't need to worry about any of that.  And, you can still search for the old issue keys - Jira keeps a record of moves, and will redirect people landing on the old issue key.

[János Hinkel]

Hi again,

i appreciate your answers, but it seems we would need a solution that combines backing up before moving and inserting a step where it is possible to map issue statuses before copying over to the other project. Maybe it's me but I haven't found such a solution or addon. The target project is already set up with the new improved workflow and statuses and transitions all we would need is to squeeze the issues from the source project into it. :)

Anyway, I won't give up yet!

Thanks again for your effort.

[Nic Brough -Adaptavist-]

Yes, moving an issue might involve mapping.  It's wider than status too.

If the target project and issue type does not have the same configuration as what you are moving into it, you will need to map things.  You may also lose data.

Imagine three issues:

Key	Issue type	Status	Custom field X
1	Bug	Open	red
2	Bug	In review	green
3	Feature	Closed	blue

Now imagine your target project

• Does not have "Features": you will need to map the issue type
• Does not have a status of "in review" for bugs, you'll need to map that
• Does not have a red option for Custom field X - you'll need to map that or lose it
• Does not have context for Custom field X - you'll lose all the data in the field

Cloning into the project won't help.  You can't create issues of types that are not in the target project, you can't clone to a status that isn't there, and you can't clone values or fields that are not there either!

What I would do is:

Housekeep the current project as much as possible - tidy up stuff you don't want to move over to the new one (probably the least important part of this suggestion, and you can be lazy about it - don't delete stuff, just accept it's going away)

Identify what you want to keep, work out what you don't want to have to faff about mapping and then

• Change what you have now so you don't have to map
• Prepare the target to accept it as is
• Issue bulk moves and go for it, mapping whatever was easier to map than do one of the last two!

Note - I have a personal preference for changing the source data to match the target.  This is usually because I've spent time making the target work for the way we want to be working (not the way we work now!  Might as well try to improve as we go!), so changing the current data makes it easier to migrate.

Also, if you do it in source, people will question more before you move, and your flood of "why is it different" questions from people arriving in the target will be lower!

[János Hinkel]

Thanks Nic for your answer in this level of detail.

Im having the feeling that the client stepped on the wrong path by creating a new blank project with the statuses and workflow ahead.

Maybe as you write and if its possible we should look into changing and adding new statuses in the current project and somehow assign them to the issues. Because the core problem is that the old statuses and workflows and board lanes which were created years ago don't fit the project and daily routine anymore.

[Nic Brough -Adaptavist-]

Reconfiguring your old project is actually another good solution in this case.  I didn't know you had that option, I assumed you were splitting a project up!

You have not lost the work you've done configuring the new project, on the status.  If you swap your existing project over to use the new workflow scheme, Jira will walk you through migrating the old issues to use the new workflows and status.

You can flip it over to your new field configurations, permissions, notifications, screens and the rest without migration (and easily flip back if it breaks anything)

But I would check that all your field contexts are set correctly before you do any of this.

[János Hinkel]

Hi Nic!

Thanks again i appreciate your support! Are you aware of any step-by-step guide or documentation about migrating old issues to use new workflow and statuses?