Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,465,086
Community Members
 
Community Events
176
Community Groups

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

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.

1 answer

0 votes

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

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events