Best practices for transferring configuration between JIRAs

Hi folks,

just now I came across a situation where I'm not sure of what is the best approach. So I wanted to ask you guys how you are handling this. Here we go:

We have three (!) JIRA systems running, on productive system, one test system and one development system. Usually for any major configuration changes we do the following:

  1. "develop" settings and configuration that words on, done on development system
  2. document this
  3. ask our admins to use the documentation in order to apply the modifications to configure the test environment as the documentation says (two purposes: check the validity of the documentation and educate our admins)
  4. check the test environment if all was configured correctly, (let other users test this)
  5. modify the documentation and/or settings, if needed
  6. ask our admins to use the documentation in order to apply the modifications to configure the productive environment as the documentation says
  7. test on production environment if anything is missing
  8. being done.

In order for this to work out the three systems are basically identical, settings are "synced" (manually, beloved admins) every now and then. There may be minor inconsistency but that should rather be an exemption.

Now I have configured a super complex workflow and everyone is happy and pushing hard for it to go live in the production system. So I thought I'd be clever, configuring screens, issue types and fields, installing needed plugins (it's all done already) and then only export the workflows as XML and reimport it on the productive system.


While doing this I just learned that all status' and screens and steps and stuff is called by its ID in the XML. While I can imagine possible backgrounds of this it basically means I have no chance (ok, 0,001% chance maybe) of using this export/import interface for transferring the workflow as the is a 99,999% chance of either a status, screen or step is having a different ID in one of the systems.

Is there any way you guys cope with such scenarios?

Oh, in case someone is suggesting the workflow sharing plugin, to me this thing is a complete mess. Inserts new statuses (bad mapping), cannot handle special characters (ä, ö, ü, ß - I’m in Germany...) and so on. Tried this already. I'm on JIRA 5.0.6 (both systems)

Thanks a lot, let’s have a fruitful discussion :)


5 answers

1 accepted


for the Workflows/screens changes i usually apply it on the production server and test it on a seperate jira project

if every thing was ok i apply it back to the rest of the projects

i only use the test system when planning upgrade or instllation new plugins

unfortunately in your case you need to create the screens, statuses and workflow again on the production server

or create the statuses/screens in the same order when you create them on the test server, the IDs are incremental, check them from the test site, then do the workflow import (it's gonna take the same time though "creating them from scratch" :P)


actually not the answer I wanted to hear, but thanks anyway. I went the tough way this morning and reconfiguring all this on the production system.

JIRA Command Line Interface has an exportData action that can help with some of the project data, but not the workflow related stuff :(.

Try this:

Interesting enough, prior to that we had internally a tool we called Sunda-to-Sahul (read here why: or ) Anyway, it never reached production code quality so we could release it. It worked on creating deltas between two Jira exports ... That plugin above ended the development on our side.

Well, as stated above the workflow sharing plugin does not work for us due to several restrictions. And the result is not desireable IMHO.

Thanks for pointing out though.

Ah, I missed that ! (sorry for that)

Edit: Anyway, if you have problems, you should raise bugs on it. Otherwise it wont get any better ...

Dieter Community Champion Oct 10, 2012
This was a solution once for Jira 3: It's punlic and of course everyone can start it's own development based on the code. The code is tremendously complex but this just reflects he complexity of Jira scheme and custom field concept ...

I had the same question as you and didn't find a suitable solution available, so we made our own.

We put together a perl script to promote configuration data (workflows, screens, fields, groovy scripts, etc.) from our Dev to Prod JIRA instance. Our method was to copy all the configuration database tables from the Dev to Prod JIRA DB.

Due to some issues with MS SQL Server, we transferred the workflows via XML export/import.

It has been working fine for 5 or 6 months...

You can see some details here:

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

3,063 views 13 18
Join discussion

Atlassian User Groups

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!

Find my local user group

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

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot