Move confluence data to another server with newer Confluence version

[Arthur Jones]

Hello,

Please help to move all confluence data (including security groups, spaces, attachments ...) to another server with newer application version.

From: Confluence 6.4.0 server, centos 7, mysql

To: Confluence 7.4.6 server, centos 8, mysql

[Nic Brough _Adaptavist_]

The best way to do this is to upgrade the 6.4 and then copy the resulting system on to the new server.  Or copy the current 6.4 system to the new server and upgrade it.

The second best way to do this is faster, but may not work - take a full backup of the 6.4 (the built-in xml backup) and import it into the new system.  It should try to upgrade the data during the restoration, but this is not always possible, and if it fails, it's because there's something in the data that 7.4 is unable to upgrade.

[Arthur Jones]

Appreciate your very quick response :)

I am afraid about full backup, because the data is ~35 gb (not sure is it a lot or not)..

And also one question this XML backup method, also backing up DB ?

[Nic Brough _Adaptavist_]

Ok, let's rule out the xml for now.

To move Confluence on another server, let's look at the minimum viable backup.  You need a copy of the database somehow, and a copy of the attachments directory.  With just those two items, you can recreate a new copy by

• installing Confluence empty,
• installing (but don't bother licencing or configuring) all the apps you had on the original system that you want to carry on using in the new one,
• restoring the database into the target database
• copying the attachments verbatim (I won't mention attachments again, they really are a simple flat copy of a pile of files on a disk)

The xml backup is one way to get a copy of the database.  A better way is, as you suspect, a backup of the database.  It's probably smaller and certainly faster than xml (The xml has one advantage in that it is database agnostic - you can use it to go from MS-SQL to Postgres if you wanted to)

Note that in there, I've not mentioned upgrading - the source and restored versions of Confluence need to be the same to do this safely.

In theory, you could get your new Confluence running on 7.4 with an empty database, shut it down, restore the 6.4 database and restart it - it will detect the difference in the data and it should try to upgrade that.  But if it fails, you will be left with a non-functional Confluence and an unusable database behind it!

What I would do is simply test the process before booking a change time.  If 7.4 happily upgrades the database when it first sees the older data, great.  If it fails, plan a separate upgrade step in the migration plan.

[Arthur Jones]

Very good. Am I understood you correctly, all my data (created docs), is saved on DB, and if I can successfully import the DB, I will have all my docs? (on this example I excluded attachments, installed apps, and specific configures)