Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

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

Test Environment

How difficult is it to setup a test environment; and how to transfer to production

2 answers

1 accepted

5 votes
Answer accepted
Mike Rathwell Community Leader Jun 08, 2016


I'm not sure if you're doing this in JIRA Cloud or on a server. If Cloud... can't help you there. If it's on your own server I do this all the time myself and it is, with JIRA, surprisingly easy. The steps I take are:

  1. Build a brand new, totally empty JIRA server of the version you want (same as production or whatever you want to try to update to).
  2. Once you get it up and happy and can log into and see the empty JIRA instance, shut JIRA down.
  3. On your source production system, run the XML backup
  4. Copy the <jira-data> directory from the source production in its entirety to your target test system replacing the <jira-data> directory created by the base JIRA instance install
  5. Move the export created from <jira-data>/export to <jira-data>/import
  6. Change the ownership of the directory and contents to whatever user you run JIRA as. If you don't you'll get an epic failure to start.
  7. Start the target test system JIRA instance. You still don't have your clone back quite yet
  8. Import the file you just exported to the system
  9. When the system settles down you have a clone of the system


  1. The above assumes that you are running the database on the same server as your JIRA instance, the host you are pointing to is "localhost" or "". If you have a FQDN for your datasource even if it is local to your JIRA instance OR you point at an external DB server CHANGE THE DB CONFIG IN <jira-data> BEFORE YOU START JIRA. Other wise you'll bork your production data.
  2. If JIRA has a failure at one of these points, it's possible it's just unhappy with how things came over and can't sort itself out. This isn't a consistent failure; i have it so it doesn't fail at all or fails at different points of the steps above (from intial start to import, to final restart). To fix it at any of these points it fails and then just be able to carry on:
    1. Stop JIRA
    2. Delete the contents of:
      1. <jira-home>/caches directory

      2. <jira-home>/plugins/.osgi-plugins directory

      3. <jira-home>/plugins/.bundled-plugins directory

      4. <jira-install>/work directory

    3. Restart JIRA

When it's time to transfer to production... perhaps it's an awful hack but when I am happy with the migration and it's flawless after testing... I do the following:

  1. Take that last point in time backup of current production
  2. STOP the JIRA instance to keep people from making changes even if I've communicated to the community the server is being updated so leave it alone from X time to Y time.
  3. Shut down the server after you have the <jira-data> directory copied over
  4. Re-assign the IP address that was being used on the old production to the new production server.
  5. Do the migration steps above.
  6. When it's done, the new server is automagically... in production. If Something Bad happens on the migration, roll back is as simple as restarting the old server.

You CAN do this with a DNS Alias change but I found that the IP address swap had the new JIRA server come up without having to re-establish application links to anything and Crowd just happily authenticated users to it without having to reconnect the Crowd server as its user authority. With the DNS alias change you have to reconnect applications and tell Crowd about the new server.

This approach is also great if you want to slide a new OS and/or Database server under your JIRA application. For.... reasons... I've used this approach to go from CentOS and MySQL to Windows and PostgreSQL and to where it is now, Debian with PostgreSQL

Let me know if this helps




Thanks Mike, we need it for cloud but this is a great reference to have.  Much appreciated.

For Cloud, there's no concept of "test" - a Cloud system is a Cloud system.  You can use it for whatever you want! 

So, if you set up two Cloud accounts, one production and one test, you can work in them separately, but your options to transfer between them are very limited - you'll be doing config and setup mostly by hand (or merging in local dev systems before re-uploading)

Got it, thanks so much Nic you are right on point smile

Short and very good description to setup a test environment. Two additional steps from my point of view:

  1. Remove incoming mail handler (I changed server to localhost in XML-File)
  2. Disable users to log in to test environment (for example remove them from group "jira-software-users")

I'm about to set up a test environment, this is a great help. Thankyou. 
How is licencing handled? Do I need to just keep applying for trial keys?

No, that will be shut down.  If you need a Cloud "test" system, you will have to pay for it.  If you want a Server test system, use a "developer" licence, which is associated with your main server licence.

Ah perfect thanks!

Mike Rathwell thx for such simple and step by step explenation.

Hi @Mike Rathwell

many thanks for these awesome instructions for Jira. Is the approach for Confluence and Bitbucket rather similar, if you have got any experiences regarding that matter?
(I know the post is like 4 years old, but is suits so well :)). 

My best


Mike Rathwell Community Leader Feb 20, 2020

Hi @Merve Nur Bas ,

I can't speak, to Bitbucket as I have never run one of those BUT it is largely the same for Confluence. The only delta is that it is a different cache blast for Confluence. In the Confluence case:


Like Merve Nur Bas likes this

Thanks a lot! Really nice of you replying to an ancient post :) 

Have a nice weekend!

My best


Suggest an answer

Log in or Sign up to answer
Community showcase
Published in Jira Service Management

JSM June Challenge #2: Share how your business teams became ITSM rockstars

For JSM June Challenge #2, share how your non-technical teams like HR, legal, marketing, finance, and beyond started using Jira Service Management! Tell us: Did they ask to start using it or...

196 views 6 7
Read article

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