How to upgrade existing Confluence Server to Data Center on new hardware

Engineering Services

Our company is planning to move from Confluence Server (On-Prem) to Confluence Data Center (On-Prem). The Data Center is running all new hardware (Confluence Nodes AND Database), so we are not just ugprading Server to Data Center on the same server. What is the best way to migrate the data to the new hardware, while also going from Server to Data Center?

 

My current idea is like this. Install Data Center on the new server. Install the new Postgres Database on a different new server. Backup the data and database from the old Server and old Database.  Restore the data and database on the new Data Center server and new Postgres DB server.

Nic Brough -Adaptavist-

Welcome to the Atlassian Community!

There are a few options, although I will say only the first can be recommended, and it is pretty much exactly what you said.

There is another recommendation - do not try to upgrade as part of a migration.  It's fine to do it before or after the migration, but don't include it in the migration plan, it's a separate piece of work.  The same goes for database changes - never try to do something like swap from Oracle to PostGres during a Server -> DC migration, do it before or after.

• Recommended
  • Build your hardware (be it running the nodes on tin, AWS, GCP, whatever)
  • Build your (clustered) database server.  Ideally, use exactly the same version you have for your server (but accept smaller variations.  For example, I've got a Jira hooked up to a PostGres 9.5.  I am not scared of hitting "apt upgrade PostGres" to take it up to 9.6 when I get around to it, but I wouldn't risk going to 10.  Your testing will spot problems anyway)
  • Build your Confluence nodes.  Use exactly the same version of Confluence you are currently on - DC and Server version numbering are identical because they're the same code base.
  • Check the DC install is working ok with a simple demo space.
  • Get the DC system hooked up to your proxies, integrations, and, most importantly, user directory (you can use internal accounts, but I've never seen a corporate do that.  Most have an admin user or two in the internal directory and nothing else)
  • Test.  Test test test.  Make sure it works.  Don't worry about the data size, test that it can talk to everything, including that the collaborative editing is working.
• Your "go live" plan is now:
  • Kick everyone off both the Server and DC, ideally by simply stopping both
  • Dump the Server database, restore it into the DC database
  • Copy the attachments from Server to DC.  The home directory file systems may be quite different on Server and DC, depending on versions, but the stuff within the directory named "attachments" is in exactly the same shape.  If they were on the same disk, then you could say something like "cp -R /data/server/confluence/home/attachments/* /data/DC/confluence/home/attachments/*", and it would work fine (trick - most of us pre-load that, especially when you've got a lot of attachments - we use rsync running on a low priority for a while before migration so that on migration day, it only needs to update a handful of files)
  • Restart the DC nodes
  • Trigger a full re-index

 

• The cheap and quick option
  • Apply your DC licence to your server.  
  • Apply your DC licences for the apps to your server
  • Not recommended because while you now have a single-node DC, it's probably not set up the way DC nodes should be, and you're still going to have to do a lot of mucking around to get it set up properly, even if you don't want to add nodes.

 

• The really dirty hybrid option I've seen once:
  • Caveat:  This was a Jira DC migration, not Confluence, and I had been asked to take a look at a load of problems that the customer's users had reported after their go-live.  None of the problems turned out to be down to migration, I think it was more "oh, someone to talk to about existing problems that have not gone away."  
  • Set up at least one of your new DC nodes
  • Sync the attachments to shared storage
  • Tell your old server to use shared storage
  • Upgrade the existing database to a clustered version (server does not care whether the database is clustered or not)
  • Apply the DC licences to your server
  • Add your server as a node in the DC
  • Give it some time to get synced up (at the very least, trigger a full locking re-index) 
  • Add more nodes if you want them
  • Remove the old server from the cluster
• But, the short version of this is mostly what you are doing, just a couple of minor tweaks:
  
  Create new DC install (and check it works)
• Copy attachments
• Copy database
• Restart and Re-index