Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal


  • Give kudos
  • Received
  • Given


  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

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

How to clone JIRA instance to a new server with same settings


We would like to setup another JIRA server and perform a full clone of the current JIRA server over to the new one. It would all just come over as part of the clone. 

Instead of the normal migration using import/export xml backup file, do we just need to reconfigure the Jira software and database with the new server name and IP address? The Jira application would still use the same port number on the new server.


If the entire OS and application file systems are cloned to the new server, can Jira be reconfigured with the new server name without requiring a new install? Also, if they are performing this clone using something like VMWare VMotion, can it be done with the existing application and database up and running or does everything need to be shutdown?


3 answers

1 accepted

0 votes
Answer accepted

This all depends on how you set up Jira. If the database is on the same machine and the database host is set to it makes things easier.


You can clone it while running on low load, boot it with it's nic disabled, set a new ip, add /etc/hosts entries to all your Atlassian stack to localhost (otherwise you will have 2 applicationservers talking to all your application links from the same unique id).

Before starting it up, it makes sense removing your hardcoded hostnames in the database, so do a mysqldump, and do something like:

cat jira.sql | sed 's/http:\/\/jira\./http:\/\/jira-test2\./g' | sed 's/https:\/\/jira\./https:\/\/jira-test2\./g' | sed 's/http:\/\/other.hostname\./http:\/\/confluence-test2\./g' | sed 's/https:\/\/other.hostname\./https:\/\/confluence-test2\./g' | sed 's/http:\/\/jira\//http:\/\/jira-test2\//g' | sed 's/https:\/\/jira\//https:\/\/jira-test2\//g' | sed 's/http:\/\/other.hostname\//http:\/\/confluence-test2\//g' | sed 's/https:\/\/other.hostname\//https:\/\/confluence-test2\//g' | sed 's/http:\/\/confluence\//http:\/\/confluence-test2\//g' | sed 's/https:\/\/confluence\//https:\/\/confluence-test2\//g' | sed 's/http:\/\/confluence\./http:\/\/confluence-test2\./g' | sed 's/https:\/\/confluence\./https:\/\/confluence-test2\./g' > new.jira.sql

The import the new dump back to the mysqlserver.

At this point find your dbconfig.xml and verify that it does not point to your production database server

Lastly, edit your to make sure you have the disabled email row uncommented. If not you will receive 2 notifications from different servers.

Lastly, if your JIRA instance talks a lot to applications around your landscape, add all the hostnames, short and FQDN's to the hostfile pointing at Better to have it chatter to itself than a production instance.

If you terminate SSL you might need to replace your cacerts file with a new keystore.

Thanks Jonas for your quick reply. Looks like it is not as easy as using JIRA default export/import xml backup files.

Is the following way also good enough to do the migration?

1. Fully Clone the server.(JIRA & Database)
2. Export the data from old server using XML backups and Import them to the new server.

Do I still need to install all the plug-ins in cloned server?

Another question is 

If the entire OS and application file systems are cloned to the new server, can Jira be reconfigured with the new server name without requiring a new install?

I finally took the time to write a jira-cloner for work. It's written in bash but due to being developed at work they own the IP so i can't share the code but i can share a few things i learned along the way.

Stepstoning it functions with continues sanitychecks is a must. Two instances that accidentally talk to the database WILL crash production and test and leave the database in a mess very hard to recover from.

I start the process on production server. In short:

* kick of a script that verifies the status of the test server, makes sure it can SSH with a ssh-key, that the test-instance is not running, that mysql is installed, apache rewrite proxy exists and so on, then proceeds to delete most of the data/app directory (skipping logs as we have gigs of it). It also drops the database and recreates an empty one.

* Next on production i do a mysqldump that is added to /opt/atlassian/

* Next i rsync the database dump and a current copy of the filesystem to the test server.

* Next i kick off a script that updates:

server.xml (changes reverse proxy statements (disable emails as you dont want notifications from test)

dbconfig.xml (change database server to localhost, renaming username/password/database)

* stringreplaces all instances of hostnames such as jira, bamboo, bitbucket, confluence to it's correlating test-server names in the database dump file, then imports it to the local database server.

* using openssl i download all the respective certificates to files, and imports them to the keystore.

* replace our jira logo with one that clearly states jira-test

* using atlassian guide on how to remove application links via the database, i automated this into a script too.

* using a list of host i dont want this server to be able to talk to, i add them to /etc/hosts (localhost) making sure if jira wants to talk to them, it will only talk to localhost.


I can now clone jira while it is still running in less than 25 minutes, by simply firing up a single script. Most of this time is spent on rsyncing 26gb of files over the network, and a fraction to sed replace hostnames in database and the import of the database dump. I noticed that not deleting all was an option, but the footprint of cache dirs might grow on test, but in return i can clone it in ~ 5 minutes.


It's well worth taking this time to automate it, because what was a gigantic task that took 5 hours and only happened every 3 months, can now happen on a weekly base.

The only manual labor left is reestablishing the application links, but once i have done this for all atlassian apps, i will approach this issue too, most likely via the database.

Next up: Confluence! :)

Thanks for sharing this with us! Very helpful!

Like kahn chang likes this

Hello @Jonas Andersson ,


Thank you for sharing this! It helps a lot to understand.

Would it be possible to share the script?

Suggest an answer

Log in or Sign up to answer

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