FROM a Confluence Server version TO a DataCenter self-hosted on public cloud

[PLESSY Laura]

Hi Atlassian Community,

Hope this is the right location to ask my question :)

We have a growing Confluence Server platform (2000 users, 180 GB) and we are now thinking of changing our subscription for a DataCenter version (more security and availability features) self-hosted on public cloud (AWS / Azure). 

Any feedback on such a scenario? Did someone already try the journey? An idea of the cost of such a change? 

Any inputs would be greatly appreciated,

Thanks,

Laura

[Nic Brough _Adaptavist_]

Lots of people are doing this, and in lots of different ways. 

The best way to think of it is in three distinct technical steps, even if you're going to do all of them at the same time, it is just a lot easier to do them sequentially and not mix up their components.  They are

• Move from Server to Data Centre
• Move off your servers and on to AWS/Azure/whatever
• Upgrade

The upgrade is optional and the order you do these things in does not technically matter.  However, I would recommend this order:

1. Upgrade.  Atlassian are making it progressively easier to move from Server to Data Center.  The best route for Jira and Confluence is "convert my server install so that it becomes the first node in a Data Centre install, and then add nodes".  Until recently, Server and DC had different directory structures, and converting to a "single node DC" was a long process of moving directories around, and faffing with up to twenty config files and internal settings, along with all sorts of fun with licences.  The latest versions of them are almost at a point where you can give it the new DC licence and it goes "hey, I'm a node now".  (Still some fiddling with config when you add nodes, but the initial Server -> single-node DC is getting a lot easier)
2. So, once upgraded, flip the server over so that it becomes a single node DC install
3. Finally, move that single node to AWS, and start adding more nodes as needed

There is a part I've left out.  I personally wouldn't just sling a flat copy of a single DC node onto AWS wholesale.  I would re-architect it and take full advantage of running Atlassian DC on AWS.  You're going to want to do some re-architecture anyway - running DC by "copy server and make it a new node" works, but it's sub-optimal, you should be looking at servers that are designed to act as clustered machines.

[PLESSY Laura]

Thanks a lot for this complete answer :) It answers a lot of our questions. Do you know where I could find more info about the pricing part of the story (except the Data Center cost I mean)? 

Thanks again for your insights,

Laura

[Nic Brough _Adaptavist_]

There's not a lot I can tell you about procing I'm afraid.

Yes, you can drop the maintenance cost of your current server licence, and instead pay for the Data Centre version (may be worth getting in touch with Atlassian or a partner about this - if, for example, you bought or renewed server in June, and you go to DC in August, you may be able to get the 9 months of server maintenance offset against your first DC bill)

The rest of the costs are in two parts:

• You'll need to pay AWS or Azure or whomever for the nodes you put into your DC installation.  Those will probably be proportional to the power and usage of the machines you ask them for.
• There is a one-off cost of migrating - this is pretty much down to the effort needed by some humans scoping, planning, testing and performing the whole process.

I do not know your level of ability, or desire to use your people's time, to do this, so my next suggestion is going to be very wide ranging:  You may get some value out of engaging an Atlassian parter for this project. 

Obvious advert here of course - I work for one such partner.

Some of us do migrations for people a lot, and at varying levels.  I did one the Thursday just gone, have another one next week, and my squad are currently planning and testing another eight for various clients. 

Our scale of involvement on these ten is very varied. 

• One end of the scale is "the client gave us a 'root' account on the source and target machines, a start time of 6pm Friday, and expect their people to be working on an upgraded and moved system when they start work on Monday morning"
• The other end is "the client got us to have a look at their current system, and their migration plan, just to see if they'd missed anything"  
  
  

Those are extreme cases and the second one has not quite happened in real life - the client was happy with the review of what they had, but asked us to have someone "on call" for their migration window as well.

Most partners will be happy to help you wherever they are on the scale I've just burbled about.