Documentation for Confluence 5.8 (Server).
Documentation for Confluence Cloud and earlier versions of Confluence is available too.

Skip to end of metadata
Go to start of metadata

See Migrating Confluence Between Servers for a more comprehensive explanation.

Many Confluence administrators will have a production instance running the "live" version of Confluence, as well as a test instance for testing upgrades and so on. In this situation, it's quite common that the two instances are running different versions of Confluence. This document describes how to copy the data from a production instance to a test instance, where the production version may be different to the test version.

Before proceeding with this guide, ensure you have read and understood the normal procedure for upgrading Confluence.


(warning) The information on this page does not apply to Confluence Cloud.

Upgrading a test Confluence instance with production data

Essentially, we are copying both the production home directory and database to the test instance. We then update the database details on the test instance to point to the test database, leaving all other instance metadata (most importantly the Confluence build number) the same as production.

  1. Shut down your test instance.
  2. Restore the production database to the test database server.
  3. Create a backup of the confluence.cfg.xml file found in the home directory of the test instance.
  4. Copy the production confluence-home directory to the test application server.
  5. Open the confluence.cfg.xml which has been copied in a text editor. Change the database settings to match the test database server. Ensure you do not point to your production database. (You can compare with the backup you made in Step 3 if you need to get the database settings. Don't just copy this file – you need the build number unchanged from production to indicate the database is from an older version of Confluence.)

Before starting your test instance, you need to do the following steps to ensure no contact with production systems.

Ensuring no contact with production systems

To ensure no contact with external systems, you will need to disable both inbound and outbound mail services.

  1. Disable global outbound mail by running the following database query:

  2. Disable space-level mail archiving by running the following database query:

Change the 'SELECT *' to a 'DELETE' in the above queries once you are sure you want to remove the specified accounts.

Once this is done, you can start your test instance without any mails being sent or retrieved. Think carefully about other plugins which may access production systems (SQL macro, etc.). These should be disabled promptly after starting the test instance.

You can create a developer license for this server and update the License Details after starting up.

See also

Upgrading Confluence
Migrating Confluence Between Servers
Restoring to a Test Instance of Confluence from Production


  1. Is this the process to follow if we want to disable all existing mail notification setups but allow new ones to go in? In other words, if we copy PROD to QA we don't want QA to send emails to users that signed up for notifications in PROD but we do want our QA testers to be able to use the email notification features as part of their testing.

    Right now I've just removed the mail server by hand...

    1. Hi Peter,

      The instructions above will remove the mail accounts set for both inbound and outbound emails. That will ensure Confluence not to send out notifications to any users, regardless they are PROD users or QA testers. If you would like to maintain the mail accounts (for QA testers usage), you may want to perform this instead:

      1. Do not delete the mail account settings
      2. Remove the PROD users notifications/daily report: SELECT * FROM notifications

      Hope that helps.


      1. Perfect, that's exactly what I needed. Thanks!

  2. Anonymous

    How to shut down crowd:

    1. open command prompt
    2. type:

    net stop confluence

  3. How can I delete all application links to production systems?

  4. Hi everyone,

    Bumping up Vidal's last question as I do have the same problem. Doing a restore that way keeps all the application link live, so when changing then in TEST, the PROD app links are messed up.

    So how do we delete all those app links in the TEST DB before safely starting Confluence in TEST?

    1. Hi Fred,

      Sounds like someone might need to dig into this a bit more, so I'd suggest contacting support so that someone can work through it with you.

      1. Not really, I already spent quality time with support to figure out the right configurations of all links between JIRA, Confluence and Bamboo. The Atlassian products are so awesomely integrated that I couldn't figure out the right checkboxes to click. But now I think I'm good, at least last time I restored a Confluence test instance I was able to fix the broken PROD application links.

        No, same as Vidal is asking, this page needs to be edited to provide instruction on how to handle the application links so that my TEST instance never connects to the PROD instances.

        I tried messing around with the BANDANA table but that was not enjoyable and still not sure if it's enough.