You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
We wanted to have the flexibility and superior add-ins available for Confluence Server rather than our existing Confluence Cloud site. We also don't always appreciate the continual UX 'improvements' in Cloud as much as Atlassian might like us to.
This doc describes the process I used to move from Confluence Cloud (https://mycompany.jira.com/wiki) to Confluence Server on a dedicated Amazon Web Services (AWS) virtual machine (https://confluence.mycompany.com).
The process includes installing a reverse proxy and SSL so that traffic is encrypted, and users get the https: browser padlock when they access the site from wherever they are.
I started with the general guide from Atlassian: https://support.atlassian.com/confluence-cloud/docs/migrate-from-confluence-cloud-to-server/ but there was an awful lot that went wrong along the way, or didn’t quite fit the guide.
I decided along the way to also move our Jira Cloud to Jira Server on a separate AWS instance. These steps mainly follow the confluence process with some slight variations.
There was a lot of two steps forward, one step back and these are the final set of instructions. Initially I installed the postgresql databases on the same AWS ‘machines’ as the confluence and jira servers, but I then went to using an AWS RDS database.
The trickiest task in this process was to fix old, hard-coded links in the databases, which pointed to my company’s previous confluence and jira systems over the last 15 years.
Even if you don’t want to move from Cloud, much of the process here could be used to validate a cloud backup strategy. If your company risk analysis has the item "What if Atlassian Cloud is compromised?" the mitigation could be: "Restore the latest backups to an on-prem or AWS server".
You don't want to be testing whether your backup process works after something has gone wrong. Having been through this, you will likely be disappointed.
This was originally just some notes written to myself. I am not a professional IT guy. I’m not going to accept any responsibility for any losses/issues/problems you have. I'm sure this doesn't always follow best practices and I'm sure there are more elegant and efficient methods of doing things. But I made them work for me. Use at your own risk.
I will use “mycompany” in code and URLs throughout this document, so do a search and replace for your own company name.
Of course, if you see any glaring security holes, I'd appreciate a contact asap so that I can adjust my system and this guide.
This guide was written during June-Sept 2020. Using different versions of software and operating systems may of course cause things to break for you. e.g. Files might be kept in different places by different versions. I am using:
Make sure you check with Atlassian docs – search “Supported Platforms” for each – especially the databases.
The process is this:
This discussion forum has a limit of 20,000 characters and I couldn't be bothered splitting my how-to up into smaller chunks. The full document is here:
I hope you find it useful. Cheers