How should I approach a confluence upgrade/database migration/relocation?

[jhodgson91]

We are running an old version of confluence on a Windows 2008 machine connected to a local postgres database.

We would like to do three things at once, we are currently on 4.3. we would like to upgrade to latest, move to a linux machine and connect to a central database server we have. We would also like to stop using crowd for our user authentication and move to confluences in-build ldap connector.

The ideal situation would be to create a blank confluence server with the right user authentication and then simply dump the database to the new one and copy the data folder across. Would this be possible? Or is the newest confluence likely to have issues with old confluences data?

[Stephen Gurnick · Accepted solution]

I will echo Milo's response as we went through the same procedure about two years ago (moving from Windows to Linux and moving to a centralized DB). Your best bet is to:

1. Set-up your new Linux system in tandem with your production Windows host.
2. Install the same version of Confluence on Linux that you have in production
3. If your database isn't too large, you should be able to use Confluence's built-in XML export function to obtain a copy of the database. You can then import this during the install on the Linux host.
   1. Be warned if you have a large database (many GBs) the XML backup can be troublesome.
   2. If you are moving to a centralized database that is the same as your local one (e.g. MySQL to MySQL or MSSQL to MSSQL) then you can use your database back-up tools to export. However, if you are moving to a different database (e.g. MSSQL to MySQL or MySQL to PostgreSQL) using Confluence's XML export function to obtain a copy of the database is the best option regardless of the database size.
4. Depending on where your attachments are stored (filesystem or database) and how many add-ons you have, installed you may or may not need to grab a copy of the Confluence home directory:
   1. If your attachments are stored in the database then the XML export or database tool backup will grab these for you. If they're stored in the file system, make sure you create a backup of the Confluence Home Directory to be moved over to the Linux host.
   2. With regard to add-ons, if you don't have many installed or don't care too much about them, then of course there is no need to worry about them. You can always re-install them later if necessary. If you do care about any add-ons then the back-up of the Confluence Home directory will capture them.
5. Restore your data into the test Linux host and verify functionality. If you don't want Crowd anymore, this is your opportunity to link to your LDAP source directly through Confluence.
6. Once you get everything working the way you want, I suggest putting this new Linux host into production and demote your Windows host. Let this older version of Confluence run in production for a bit to make sure all is well.
7. After some time has passed and there are no issues, find a good maintenance window to upgrade Confluence on your new Linux production machine to the latest version.

Atlassian wrote these two articles that should also be useful for you:

Migrating Confluence Between Servers

Restoring a Test Instance from Production - I mention this one since this is essentially what you are doing. You're creating a new test server on a Linux machine from a production windows host.

Hope this helps get you going.

-- Stephen

[Milo Test]

You definitely want both servers at the same major release.

So you can install an older (4.x) release on the new server, move the site, then upgrade the new server, OR upgrade the current server, install the latest on the new server and move the site.

We never used Crowd, but configuring LDAP went smoothly.