Currently we have 3 support desk projects.
We would like create 1 support desk project to replace these 3. We definitely want to import all the current tickets into this new project.
Question 1: Is this import possible? If yes, will the ticket keep the original KEY or the tickets will get a new key ? If they get a new key, the numbering will be based on the creation time for example?
Question 2: What would be the best practice here? Creating a brand new support desk project (and import the tickets from the current 3 projects) or rename the biggest one and import the tickets from on the other 2?
Question 3: If better to rename the biggest one, I saw that we can change the key as well but I did not fully understand the impact: “Changing the project key will start a background re-index of your project, and may break some external integrations.”
Can you please explain this?
@Zsuzsanna Huszti, there may be a better way to do this (plugin, export and import, etc.) but here is likely what I would try first along w/ some questions, thoughts and considerations.
Let me preference this w/ I have not done this specific scenario so take my advice w/ that in mind.
First, I will ask knowing full well you probably have thought of this and made up your mind already. Is this really what you want to do? What is driving you in this direction? Don't need an answer here just something to consider before moving forward.
Second, how many issues do you have in each project? 10s, 100s, 1000s? That might influence the approach. If 10s of thousands then I would likely explore an export and import scenario.
A big factor in success or at least effort lies in the question - "How different are the three projects?". Are the workflows, custom fields, screens and schemes the same? If identical or close then it is likely to go smoothly. This goes back to my first point. Obviously when you move to a single project any uniqueness of any project is out the window.
That out of the way let's jump into a possible solution, one that I would likely take on. My approach would be to use the bulk move method. Especially if there are only 100s. Note you will be limited to 1000 at a time. There are ways around this but we won't go there right now. Here is how I would likely proceed. I say likely because I don't know your details.
hope this helps.
Thank you for your response!
The biggest project has 2200 issues, the others 650 and 450. The workflow and issue types are the same for the biggest and the second biggest. So it might be a good idea then to keep the biggest and move the tickets here from the other 2. The smallest has a slightly different workflow... so we may even want to keep that separate and not move the issues.
We definitely have to change to key and rename the project to reflect the topics of these 3. We can do this I believe?
We also need to create new custom fields. I guess the best would be to rename and change the key; then move the issues and then create new custom fields? Would you agree?
Yes that would be a reasonable approach. You may wish to use components to continue to distinguish the 2 (or 3) ‘sub-projects’. In that case set the component on all issues in the biggest project first before moving the 2nd project in. Finish with custom fields, screens, etc.
If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot