Best way to copy 400+ issues from one project to another?

[Ken Uehling]

Right now I am working on creating a new software project kanban board to combine two other software project kanban boards. What would be the best way to copy the tickets / issues from the two boards into this new one? From reading suggestions online, it seems the best way would be to use a plugin? Any recommendations? Thank you!

[Alexey Matveev · Accepted solution]

Hello,

Tickets do not belong to boards. Tickets are selected by boards according to the filter, defined for the board. Just make a filter, which combines the two filters, defined for the first two boards, with the OR clause and you will have, what you want.

[Ken Uehling]

Hello Alexey, 

Thank you for your prompt response. 

I am not understanding your answer. Right now I have two projects that issues can be created in. How would I use a filter to have the issues in both those two projects show up on this new project kanban board that I created? We want to merge these two projects for better record keeping and to have everything in one board. 

Thank you. 

Ken

[Walter Buggenhout]

@Alexey Matveev is suggesting that you keep both projects and configure your existing kanban board to display issues from both projects. In order to do so, you would go into your board configuration, locate the current board filter and then edit this to something like:

Project in (ProjectA, ProjectB)

All your issues will remain where they are, your board will just display them all.

[Alexey Matveev]

If you want to merge two projects into one of the two projects, you can use the bulk edit feature to move all issues from one project to the other:

https://confluence.atlassian.com/jiracoreserver073/editing-multiple-issues-at-the-same-time-861257342.html

Go to the Move Multiple Issues part.

[Alexey Matveev]

And thank you @Walter Buggenhout, that is exactly what I meant.

[Cristian Rosas [Tecnofor]]

Give more votes to this people!

[Ken Uehling]

Thank you for your help. What would be the advantage / disadvantage of actually bulk editing and moving all the issues when compared to using the board filter? 

[Walter Buggenhout]

Hi @Ken Uehling,

For whatever reason, someone initially decided to manage the issues in separate projects in Jira. That means this 'someone' must have thought they did not belong together. If you want to bring them together on a single board, this is usually because one and the same team is working on both projects and - quite understandably - wants a single view on all their work.

If you want to bring the issues into the same project has the following consequences:

• the issues you are moving will get a new issue key, identified by the project you are moving them to.
• if the initial need to differentiate between the issues from the two projects still remains, you will not be able to search them by project anymore. So you will need to set up a different way to identify them separately (probably by component)
• In separate projects, you have the possibility to manage releases (fix versions) for that project independently. Fix versions are specific to Jira projects. If you bring the issues from 2 projects together, they will share the same releases.
• When you bring your issues together in a single project, your issues will have to go through the same workflow for each issue type.
• And should you have custom fields with a list of options (a select list), you will no longer be able to specify different options based on type of issue with the same custom fields.

Some of the items I mentioned are quite specific and probably not relevant immediately, but those are the main things to consider.

In short, I would only move the issues into the same project if the reason to separate them initially appears to be a clear mistake.

[Ken Uehling]

Hi @Walter Buggenhout

Thank you for your very prompt and detailed response. 

The reason these two projects were separate in the beginning was because there were two teams within the same department working on their issues. However, upper management has decided to consolidate these two teams into one so we no longer need two separate project kanban boards in JIRA. 

The only reason why my boss asked me to merge those two projects into one is just due to better record keeping. In case someone wants to look up the previous cases, they can do so within this new project board that I created. 

So with that in mind and considering everything you said, I believe the best course of action would be to do a bulk edit and move it to the new board that I created. I'm sure that I will be able to do a bulk edit -> copy to the new board? Thank you. 

Ken

[Walter Buggenhout]

Hi @Ken Uehling,

Yes. Just be aware that you will be moving the issues, not copying them.

[Ken Uehling]

Hi @Walter Buggenhout

In that case, what would you recommend I do to copy these issues since we do not intend to have the new & merged kanban board ready to go until Q1? In the meantime, both teams should be working in their respective boards until everything is finalized. 

Thank you 

Ken

[Walter Buggenhout]

Hey @Ken Uehling,

In that case, don't do anything now. Just do the move when the organisation is ready for it.

[Ken Uehling]

Hi @Walter Buggenhout

The organization expects everything to be ready to go so I was hoping to be able to first copy the issues from the two boards into the new one that I created to ensure that everything works fine and no issues will arise. There must be some plug-in that I could do to bulk copy -> edit that you would recommend? 

Thank you again for your help so far with my questions. 

Ken 

[Walter Buggenhout]

Hey @Ken Uehling,

If you are going to move the issues, you will just be moving them into the existing project and as such into the already existing board. There will be no need for a new board.

If there is one thing that you shouldn't do in any way, it is copying issues. It will create a duplicate of the same task, so you will end up with the same task in you system twice. If work will go on on either one of them, how will you be able to tell which one is the right one? 

And if you want to validate how things will go during the final move, copying is not the way to go. It is a completely different operation than moving an issue.

If you want to validate how this will work, just create a single test issue from each issue type you manage in the project you plan to shut down and move those test issues, just the way you will do it for real later on. Then see how they appear in the other project and verify whether it's ok.

[Ken Uehling]

Hi @Walter Buggenhout

Thank you for your response. 

Just to make sure we are currently on the same page - at my work, we have two project boards where each team is responsible for the issues that are created there. Each of these projects have slightly different workflows and even one of the projects utilizes swim lanes to categorize the issue type. However, there is not much else associated with those issues in either boards - they are pretty straight forward and does not utilize anything too complicated. 

My goal in the beginning of this project and what was confirmed from my boss was to create a completely new project board where this new combined team can use to work on issues. This idea was proposed so the two separate boards can continue to operate without any issues while the new project board is created. 

I'm not sure I follow you regarding your stance on copying issues. My boss does not mind that we copy issues from the old board into the new one. When we use the search function on this new board, we will only see issues (New and copied ones) that are associated with this new board. 

I'm fully confident that you're proposed idea is the way to go but sometimes when it comes to upper management, it can be difficult to propose this idea of just bulk moving into the new project board since potential issues can arise. Anything that can cause a few hours of downtime will not be good for me. Your idea of creating test issues may seem the best option here but with all the tinkering I have done within JIRA in the last month or two, I am worried that something may happen that may be out of my knowledge that will cause a few hours of downtime. 

Ken

[Walter Buggenhout]

Okay @Ken Uehling,

Trust me on this one: moving issues does not cause any downtime at all. Moving 400 issues will take no more than a couple of minutes while your Jira instance keeps running just fine.

But we are back at the beginning of this thread, where it is clear that you currently don't see the difference between a board and a Jira project. Issues are stored in projects, boards are nothing more than a functional instrument to visualise and manage the issues from the associated project(s).

So before you do anything else, create a couple of test issues and just move them from one project into the other one. Pay specific attention to both the process and the results:

• document the steps of the move itself
• see how the issue key changes as the issue is moved
• check on which boards the issue is displayed before/after the move
• make sure all information is carried over correctly

When you have a clear view of the impact, start planning for the real move.

[Ken Uehling]

Hi @Walter Buggenhout

I'm clear now - boards are nothing more than an instrument to visualize and manage the issues that are within those associated projects. After I created the filter to show issues from both those older boards onto my new ones, I understand now. Thank you for your explanation. 

Ken

[Gabriel Tessarini]

Hello Ken, there a Groovy script called "scriptJiraCopyIssueToOtherProject" for Script Listener of Script Runner in this GIT repo bellow that automatically copy as issue with same name and type from one project to other when it reach some specific status like... "Version of Production" from project called "DEV" to project "Production", for example.

In your case, i think that just setting the code on Script Console and passing a get for all issues on project you can copy then to the other project.

https://github.com/GTessarini/JiraAutomations

I hope help you!

Regards

Gabriel Tessarini.