Migrating Confluence Between Servers

How to Create a Test or Development Instance

Adminstrators may need to move a Confluence instance from one server to another for upgrades or downtime. This page tells you how to copy a Confluence instance from one server to another. For example, you may want to transfer your current production snapshot to a test server as permitted in the licence agreement.

Transferring Confluence To Another Server Using The Same Operating System

If the operating systems on both servers are the same, then the home and install folders can be copied straight into an identical external database and user management setup.

1. On the original server, create zips of the Confluence install and home directories. Copy the zips to the new server.
   
   
2. On the new server, unzip the install and home directories. Windows users should avoid unzipping with the Windows built-in extractor, instead use Winzip or the free 7Zip.
   

   If you are changing the location of the home directory, open the Confluence install\confluence\WEB-INF\classes directory and edit confluence-init.properties by changing the line starting with 'confluence.home='.

   
   
3. Modify the location of your war file if need be. If using Tomcat, this is likely in /Conf/Catalina/localhost. You'll want to make sure the docbase attribute is pointing to the right location.
4. This next step is dependent on your database:
   
   
   1. For users of the internal database, the content is stored inside the home directory. You should switch to an external database after the transfer is successful.
      1. For databases stored on another server: change the user account or datasource permissions so that the new server has the same network access permissions as the original. Then confirm from the new server that the hostname can be resolved and is listening for database connections on the expected port.
      2. For external databases stored locally: on the original server, create a manual database backup using a native db dump backup tool. Copy the database backup to the new server.
   2. On the new server, install or upgrade the database version to match the original server.
   3. Import the database backup.
   4. Add a database user account with the same username and password as the original.
   5. Provide the user with the full access to the imported database.
   6. Use a database administration tool to confirm that the user can login from the localhost.
   7. To modify any database connection information, go to the Confluence home directory and edit confluence.cfg.xml. The connection URL is set under hibernate.connection.url. Ensure it does not point to your production database server.
   8. If you are using internal user management, skip this step. For users who have JIRA or LDAP integration, provide the new server with network or local access to the same hosts as the original. If this is a true test instance, set up a test of your JIRA instance or LDAP server so as not to disrupt production systems and change the server.xml or atlassian-user.xml files to point to the appropriate test servers. Note that it might be acceptable to use a production connection here, as users won't be logging on to the test system in high volume.
   9. If appropriate, make sure no emails are sent out from the test system.
   10. Start Confluence.
   11. Go to Administration > License Details and add your development license key. You can generate one at http://my.atlassian.com. There are more details in Getting a License for a Staging Environment.
   12. If you configured Confluence as a Windows service, repeat those instructions.
   13. Add your development license key.

Transferring Confluence To Another Server Using a Different Operating System

Using database tools (preferred option)

If you are using the Production backup strategy, follow these steps:

1. Download the proper distribution (the same one you have from your original instance) from the Download Archive.
2. Copy your Confluence home (not install) directory from your original server (even if it was a different OS).
3. If you are changing the location of the home directory, open the Confluence install\confluence\WEB-INF\classes directory and edit confluence-init.properties by changing the line starting with 'confluence.home='.
4. For external databases stored locally, on the original server, create a manual database backup using a native db dump backup tool.
5. Copy the database backup to the new server.
6. On the new server, install or upgrade the database version to match the original server.
7. Import the database backup.
8. Add a database user account with the same username and password as the original.
9. Provide the user with the full access to the imported database.
10. Use a database administration tool to confirm that the user can login from the localhost.
11. To modify any database connection information, go to the Confluence home directory and edit confluence.cfg.xml. The connection URL is set under hibernate.connection.url. Ensure it does not point to your production database server.
12. If you are using internal user management, skip this step. For users who have JIRA or LDAP integration, provide the new server with network or local access to the same hosts as the original.
13. Copy server.xml, atlassian-user.xml, osuser.xml, any patches, and any other customized files velocity or properties files. If you are using internal user management, skip this step. For users who have JIRA or LDAP integration, provide the new server with network or local access to the same hosts as the original. If this is a true test instance, set up a test of your JIRA instance or LDAP server so as not to disrupt production systems and change the server.xml or atlassian-user.xml files to point to the appropriate test servers. Note that it might be acceptable to use a production connection here, as users won't be logging on to the test system in high volume.
14. If appropriate, make sure no emails are sent out from the test system.
15. Start Confluence.
16. Go to Administration > License Details and add your development license key. You can generate one at http://my.atlassian.com. There are more details in Getting a License for a Staging Environment.
17. If you configured Confluence as a Windows service, repeat those instructions.
18. Add your development license key.

For XML backups (only for small to medium sized installations)

If you're not yet using the Production backup strategy, you can do this with your regular XML backup. Create a backup and import into the new server.

1. Create a backup from Confluence:

   1. Go to the Confluence 'Administration Console'. To do this:

      • Open the 'Browse' menu and select 'Confluence Admin'. The 'Administration Console' view will open.
   2. Select 'Backup & Restore'.
   3. Check the 'Backup Attachments' option and select 'Backup'.
      
      
2. Identify the current version of Confluence your are using, displayed at the bottom of each Confluence page.
3. Download the same version as you are currently using to the new server, which may be the current Confluence release, or an older version.
4. Go to Administration > License Details and add your development license key. You can generate one at http://my.atlassian.com. There are more details in Getting a License for a Staging Environment.
5. Using the same version, follow the Upgrading Confluence guide.
6. Add your development license key.
7. Restore your XML Backup From <<Administration > Backup and Restore>>.
8. If appropriate, make sure no emails are sent out from the test system.

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:

   SELECT * FROM BANDANA WHERE BANDANAKEY = 'atlassian.confluence.smtp.mail.accounts';
   

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

   SELECT * FROM BANDANA WHERE BANDANAKEY = 'atlassian.confluence.space.mailaccounts';
   

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, JIRA macro, etc.). I They write content, or create unwanted load on external systems, they should be disabled promptly after starting the test instance.

Merging instances

If you wish to merge two instances, you can consider using the remote import plugin. This plugin is currently unsupported. The supported method would be to export a space and then import spaces one by one. The two instances must be the same version.