It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Is it possible to migrate current tickets from a service desk project to another one? Edited

Dear All,


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?


Thank you!

1 answer

0 votes
Jack Community Leader Jan 19, 2018

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

  1. Decide whether you use an existing project to import the other two into or create a new one. If one of the current projects has exactly, or very close to, what you want in the way of workflows, screen, etc. then use it as the end project. I likely would stick w/ the same key and project name though. If you want to start clean w/ new name/key then just do that as you don't have to make any compromises. Let's assume you want a new project for the sake of continuing here.
  2. Create the new project taking care and experience to configure workflows, screens, etc. the way you want. This is a key point especially where workflows are concerned. Obviously Moves are easiest when the workflows are the same otherwise you have to perform a lot of mapping. Moves are even more messy if you have multiple workflows based upon issue types.
  3. Start with a test. Create a test issue in each of the three projects and move them to the new project. See if things are as you desire.
  4. Once happy with things then run a filter for the entire project and perform a bulk move. if you have different workflows for different issue types then move by issue type as you can't perform bulk moves across multiple workflows at once.

hope this helps.


Dear Jack,

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?

Thank you!

Jack Community Leader Jan 22, 2018

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. 

good luck!

Thanks a lot! I need to check on the components.


Suggest an answer

Log in or Sign up to answer
Community showcase
Posted in Jira Service Desk

Tell us how you've implemented Change Management

Hello Community 👋, I'm a product manager at Atlassian, looking at improving change management capabilities across our products. In particular, we're looking at bridging the gap between Dev & ...

283 views 0 5
Join discussion

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you