How safe is it to restore and upgrade Confluence Server to a new environment all at once?

Nick Reilingh

I am moving from Confluence 5.10.7 on an unsupported version of MySQL to Confluence 6.15.7 on PostgreSQL, and am planning out the steps I will take out during my maintenance window.

The general approach I want to take is to configure a brand new environment running the new version and database, populate it with a copy of our current data for QA, and then eventually take a maintenance window to shut down the old server, do a final refresh of data on the new server, and cut over the DNS name to the new server.

When I follow all of the migration and upgrade docs to the letter, the workflow to populate the new server with data from the old one looks like this:

1. Spin up a temporary VM and install Confluence 5.10.7 against a new Postgres database.
2. Do an XML backup and restore from the old server to the temporary server, including copying the attachments directory separately.
3. Manually install all add-ons on the temp server
4. Run the confluence installer to upgrade the temp server to 6.15.7
5. Do a Postgres database dump from the temp server and restore it into the new production server running Postgres. Also copy the attachments directory from the temp server to the new server.

However, this is looking like a lot of work that might be pointless. An alternative would be:

1. Install the new server like a production server running 6.15.7 and current versions of all addons, and license everything like a production instance.
2. Do an XML backup and restore from the old 5.10.7 server to the new 6.15.7 server, and copy over the attachments directory.
3. There is no step 3?

My instance size is about 1.1GB of attachments and like 25MB of XML backup data. I know that:

• XML backups don't contain add-ons
• Database backups do contain add-ons
• XML restores on Confluence 6.15 are theoretically supported all the way back to Confluence 4.0
• Since I'm migrating from MySQL to Postgres, I can't avoid doing an XML restore at some point in the process and reinstalling all the add-ons

So this all seems to suggest I should go the direct restore route. But what I'm worried about is:

• Are there really no other directories in <confluence-home> besides attachments that store persistent state?
• Will a newer version of an addon be fine reading XML data saved by an older version of the same addon? (Or is it possible for the addon upgrade process to change state in a way that would be missed by the XML restore)
• Why does the database migration document say you must match confluence versions? Is there database-specific information in an XML backup that would mess up a restore into a newer version of confluence running on a different database?

Peter Hamilton-Harding

If you have adequate downtime and backups to make it safe and no user impact, I'd actually recommend upgrading to latest in-place first of all. This way you can hit any addon/deprecated feature issues in the head before dealing with the added joys of DB and server migration. There's a lot of significant improvements to backup and troubleshooting tools since 5.10.

Once you're up and healthy on 6.15, your two-step alternative plan will work like a breeze. I haven't had any issues doing it this way before, the add-ons can be a little painful to do manually depending on how many you have but it's a great task for those brain-dead times post-4pm.

Re your closing questions:

• Seems wacky right, I still can't believe it - create yourself a test instance and creatively break/fix it :P
• This is why I recommend getting all up to date in-place first. Will vary addon to addon
• Probably, I'm not confident to test