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
Community Members
Community Events
Community Groups

AMA: How to plan ahead for Data Center - Expert advice from an Atlassian panel


This AMA is now closed

Hi! I'm Jacob Shepard a Product Marketing Manager on Atlassian’s Enterprise Team. We know that moving to Data Center is no small task. To do so effectively demands extensive planning and a team effort. We understand you might have a lot of questions so that’s why we’re hosting our first-ever Panel AMA on October 24th from 1:00pm-3:00pm PST!

Who is on the Panel?

  • Denise Unterwurzacher: Senior Operations Engineer

  • Kevin Allen: Senior Technical Account Manager

  • Benjamin King: Solutions Engineer
  • Katie Shoemaker: Customer Success Manager

Here's how it works:

Add your questions below any time before or during the AMA. Feel free to @ mention specific panelists in your question if you would like. Be sure to take a look at other community member’s questions and up-vote those that you find interesting.

At 1:00 pm PST on Thursday you can expect to see answers from the panel start rolling in. Watch the page and be ready to add follow-up questions and discuss further with other Community members. We'll wrap the event at 3:00 pm PST, but will be sure to answer any questions we didn't get to.

11 answers

11 votes

A few of the admin pages in Jira DC show information only about the Jira node you are logged into. Mail Errors, LDAP sync both come to mind. Any plans to make the Jira DC admin experience have a more overall view of what's going on?

Kevin Allen Atlassian Team Oct 24, 2019

Hi Matt,

Thanks for feedback! We are increasing our cross-product approach to development, so you will start to see a general trend towards consistency.

We are currently exploring a few areas around health and insights within Data Center. We’d be happy to chat more to learn more about your use case. Please let Anthony, your TAM, know if you are interested and we will connect you with the product team.

Also, I believe that he has recently added a document for you in TAM Cloud that touches on some of this.


Kevin, thank you for your reply to Matt's question. Is there a way the rest of us can get a copy of the document you mentioned that is available for Matt?

Thank you,


Like Matt Doar__ LinkedIn likes this
Kevin Allen Atlassian Team Oct 24, 2019

Hi Joe! 

Great question! Officially, no.

TAMs work under pretty tight privacy guidelines. We take a lot of commonly/publicly available information, synthesize it based on our experience and our Teams experience, evaluate what our developers and engineers are working on, then run it all through the lens of client context. In short, we take the general nature of this kind of question and refine it down to its root issues and address those. Likely this document is so specific it would be of little value beyond harnessing some links that you may already have. 

That said, you can get the outcome of this process, but you'd need to subscribe to the TAM service

Alternatively work with a lead or Senior consultant from your current Solution Partner. They may not have all the access to roadmaps or direct access to the product teams, but they can still help build a solid plan to help with rollouts, architecture, general solutions, and are experienced enough to identify work-arounds for experiences like this. 

Also, don't forget to comment on, watch, and vote for issues on It does matter. 

Like Joe Pursel likes this
7 votes

What's the plan for better support for DR in Data Center? The current copying of a snapshot of the data dir to a file system doesn't work well if the file system is on the other side of a continent. I'd love to see Jira and Confluence have a way to replicate attachments to another location. Happy to run another process on the remote side

+1 for this question. 

Like Joe Pursel likes this
Like Joe Pursel likes this

This is something the product teams are exploring at the moment. As @Kevin Allen mentioned to Matt earlier, we’d love to learn more about your needs in this area. If you are interested in chatting with our product teams more about this, let us know and we’ll reach out to you via email in the next week or so.

Having said that, if you use AWS Cloudformation, there is an unsupported tool called the Backup Machine, that we use to take snapshots of both database and filesystem and push those snapshots across regions. We then use the 'clone' cloudformation templates to restore the snapshots, both for creating staging environments, and for DR.

You could also look into use EFS DataSync to sync your data to another EFS in a different region, and fail over to using that as your file system in a DR scenario. This is new functionality that was just released in May, and we haven't as yet done any internal testing with it as far as I'm aware.

Like Tiago Vitorino likes this

Denise, thank you for this information, however I would like to know Atlassian's plans for DR for customers that do not use AWS, but host Jira in their site.

Thank you,


Like Matt Doar__ LinkedIn likes this

Gotcha. Would you like to chat to our product teams more about your requirement? As I said above, it's something they're looking into at the moment. We can get them to reach out in the next week or so over email if so, just let us know.

Like Joe Pursel likes this

Yes I would. Thank you for the opportunity.


Absolutely! They'll be in touch.

Like Joe Pursel likes this
6 votes
Mikael Sandberg Community Leader Oct 16, 2019

We are in the process of migrating over to Jira DC. Do you recommend taking the existing server and make it part of the nodes, or start with new nodes and do a migration from the old server? What are the pros and cons with each approach?

+1 for this question

Kevin Allen Atlassian Team Oct 24, 2019

@Kevin Allen

Hi Mikael, On the TAM team, we always joke that our number one answer is “it depends!”

That definitely applies here, but here’s some general guidance to influence your decision.

What you bring over on one node, is going to get replicated. I strongly encourage my teams to make efforts to clean up prior to a migration. If performance is good, or only lessened by being on an overloaded Server instance, then you are probably OK to proceed as you’ve described, but this is not my preferred path.

A couple of reasons (I'm sure I or the team will think of others):

  • is your Server going to be identical to the other nodes in your new cluster? close enough will likely cut it, but if you’re going to manipulate the old server, why not start fresh with a fully patched system, etc…

  • in the extremely unlikely situation that this all goes terribly wrong, what’s your fall back? that Server will look pretty tempting if you find some obscure firewall rule blocking your production rollout at the 11th hour. If you’ve upgraded it though, you’ll have a lot more work to get back in service.

I prefer to size out (include forecasted organic issue/artifact growth AND any M&A or consolidation work) and setup a clean environment. Think greenfield, all new. Migrate your cleaned data into a single node DC. Turn it on and compare your performance metrics, then add nodes based on the load you are comfortable with in your DC environment.

Like # people like this
Great question!
This is one we here over and over in our Customer Success deployment planning discussions with first year DC customers. It really depends on your organization. Will you be moving to new infrastructure? Is your organization moving to AWS or Azure? Then of course the answer is starting with new nodes. If you are going to stay on the current infrastructure and want to keep the risks minimal, then we recommend an in-place migration. Generally, in-place is preferred because there is less having to "move data around”. Side-by-side is preferred if you have strict policy around working in your production environment or are moving to new infrastructure. 
There are risks in both scenarios. As already stated, one of the risks in side-by-side is moving/migrating data. For in-place, you are working in your production environment. It’s important to have a rollback plan in place if anything goes wrong. 
When performing either a side-by-side or in-place migration, we always recommend cleaning up prior to migrating. 
Like # people like this

Kevin noted the rollback requirement. That was a big reason we went with brand new machines for our move to DC a couple of years ago

Like # people like this

Hi Kevin and Katie, planning to migrate to DC using Jira 8.5.x or later and using our own hardware, I would like to build a prototype DC cluster beginning with a single server connected to my Dev database and continuing my rollout in this manner so I do not have to move data as I go from Dev to Stage to Prod. Is this approach possible?

Thank you,



As you're testing you can use Dev data but you will still have to move production data from your current environment. So this approach is possible but doesn't avoid data migration. 



Like # people like this

Katie, my Prod database is copied to my Dev and Stage databases on a weekly basis so we always have a recent copy of Prod data for testing purposes.

Perhaps I was not clear in my request and I am sorry that I was not. My question should have said, can I use my DC for Dev and connect it to my Dev database?

Then if this approach is possible, I would like to perform the same process as I build my Stage DC and connect it to my Stage database, then followed by building my Prod DC and connecting it to my Prod database.

In each of these migrations, I plan to begin with one node and add nodes as needed.

Has this approach been used by any clients?

Thank you,


Like Katie Shoemaker likes this


Thank you for explaining. We actually recommend what you're suggesting, mirroring prod to test, as long as you are using a DEV license or evaluation license. This guide has some pretty detailed instructions on how to do this, including the license change.

Happy to help any further!



Thank you for confirming my approach. Also, thank you for the link to the document and I will obtain an evaluation license for DC to begin testing.



Like Katie Shoemaker likes this
6 votes
Deleted user Oct 07, 2019

Are you planning to support support AWS AutoScaling at some point in the future?  (Jira and Confluence DC specifically call this out as not supported)

Yes you are correct, we do not support AWS AutoScaling today. The only way we use or support autoscaling today is to ensure a minimum number of nodes in the cluster. We set min and max node counts to the same value, and if we have to terminate a node, or AWS terminates one (which can happen at any time), the autoscaling group will kick in and bring a new node into service to replace it.

The reason autoscaling in response to events like high CPU doesn't work very well is that new nodes start up with no index. It can take time for them to pull a working index from an existing node, eg on some of our larger instances it can take up to an hour. That means that if you scaled up in response to high CPU, your new node would only become available (and usable) after 1 hour.

Instead of autoscaling in response to thresholds, you could look into autoscaling based on load. Eg if your higher load times are 9-5pm CST, you could scale to add additional nodes around 8am PST, and destroy them when the load drops.

However, bear in mind with Jira that the new node won't have an index but _will_ be in the load balancer, so your users may report problems while the index is recovering. For Confluence though, the node won't come into service until the index restore is complete.

We are continuing to collect feedback on autoscaling, so please watch and add any commentary on this ticket for Jira. We will share any updates on future support here and in other related tickets. Thanks!

Like Daniel Eads likes this

What is the correct way to refresh a testing environment from a production environment?

OR: After transferring data from a production environment via xml-Export, how do i get rid of the node references in the database which result in a lot of error messages in the log?

Like Joe Pursel likes this
Kevin Allen Atlassian Team Oct 24, 2019

Hi Christian,

It's generally beneficial to get a Solutions Partner or TAM to help you with this. Most (maybe all) partners have a baseline automation harness that they customize for their customer engagements. No one wants to manually build out nodes through numerous cycles of experimentation and testing.

If that’s not available from your partner or you don’t have the budget, there are a few things you can do here to make your life easier:

  • Use the native Database tools vs XML - generally more reliable and faster

  • Automate - see above

  • Adopt templates from providers like AWS and Azure

  • Use Community to collaborate with other admins that have the same tool stack as you, share templates and recipes

There’s an existing feature request related to your ask:

But this is also mitigated in Jira versions from 8.1 on:

In addition to Kevin’s response, if you use AWS Cloudformation, there are ‘clone’ cloudformation templates that allow you to easily create testing environments from snapshots of production data.

There is also a public tool call the Backup Machine that my team built to automate the process of creating those snapshots.

For more information on how they all fit together, check out this webinar.

Regarding deleting the extra nodes, there is a workaround in the bug which Kevin linked ( which you can use to delete the old nodes from the database, if you’re not yet on Jira 8. We’d recommend doing that periodically on your production instance if you use AWS Cloudformation and are therefore destroying and recreating nodes frequently.

Are you going to support a no-sso url in the future in the Data Center SSO solution?


Like Joe Pursel likes this

Hi Christian. We’d love to understand a bit more about your use case or reason for this request.

Is this in regards to supporting the ability to log into applications without having to go through an SSO mechanism, such as an Okta integration or another SSO IDP? Is it related to wanting support for multiple IDPs (at the same time), or more about allowing local _and_ SAML auth, as described here?

If you can expand further about your use case, we’d be happy to help! Thanks!

Hi Denise, the use case would be to allow people that cannot use the e.g. ADFS SAML for some reasons to give them a fallback solution or to create the option to login as another user. So SAML + local auth would be the desired option.

What is your favorite or most unknown/hidden easter egg in any of the Atlassian applications? 

I would like the option to change our Confluence's favorite Color and Character to something else, open a feature request? /s

Serious question, with the recent acquisition of Code Barrel and strategic partnerships with companies like Slack, can we expect any features with these plugins to be built in or possible enhanced?  One example that comes to mind is in JSD there is the the default "Automation" option for projects, but if you have Automation for Jira installed there is an additional option for that plugin ("Project Automation").

Huge shout-out to Kevin Allen and Anthony Ferrari, they have been instrumental to our organization by guiding us on the correct path to use Atlassian products.

Kevin Allen Atlassian Team Oct 24, 2019

Easter Egg, etc:

Hmm, it’s well documented, but probably the most underused/ Easter eggy type of feature is per user settings in Jira and Confluence. As a solution partner, I used to harp on this constantly and wrote a couple of blogs about it.

Feature request: Maybe a Premier Support ticket, personally I’d stick with Blue :awesome:

Serious question: 

It’s likely a bit early for us to talk about these plans, even as your TAM. I know this one is important to you and we will keep you in the loop as best we can. Exciting stuff and glad to have that team back with Atlassian.

Shout out:

Thanks Eric! You’re a pleasure to work with!

Like Eric Vincent likes this

Some of my favourite easter eggs:

  2. As you mentioned, Confluence has a favourite colour and a favourite character, but they can't be changed. That's because they were originally used as a way of validating the product version. For those who haven't seen them, you can find them in System Information.
  3. There’s a ‘cheese' macro in Confluence DC that exists purely because our indomitable former architect Charles Miller needed a way to test whether macros work and really likes cheese.
  4. Type `s t a s h` on Bitbucket Server and it swaps the logo back to the old school Stash one.
  5. On Bitbucket Server, when taking a photo for your profile press `m` and it will detect your face and add a moustache.
  6. Not really an easter egg, but a bit of Atlassian culture that I love. Rosie Dabinett was an early employee of ours who was instrumental in setting up our initial documentation. She sadly passed away a few years ago, and we gave her a colour in the ADG palette (R50 - Rosie) in memorial, so she’ll always be with us.
Like # people like this

Older version of Jira had some kind of game you could play in the Credits page I think.

There are some snarky comments throughout the source code, but that's hardly unexpected to me :)

How is the feature looking about supporting Microsoft SQL Server feature "Always On Availability Groups". We're looking into it for our switch to datacenter with fully high availability (proxy, application servers, file share and databases). I know the latest JDBC driver supports this feature, but does the Atlassian software support it? For example will it work without issues if a database server reboots/loses connection.

It has been possible to use SQL Server’s Always On Availability Groups since Jira 7.5.0, as that was shipped with JDBC driver version 6.2.1:

There is some more information in that ticket, however it does note that it’s not an officially supported configuration.

While Confluence hasn’t made any public statements regarding Always On Availability Groups, it has bundled JDBC driver version 6.3.0 since Confluence 6.4.0, so any Confluence version 6.4.0 or higher should also be compatible (though also unsupported).

Bear in mind, there are a few rules of thumb regarding non standard database configurations:

  • So long as there is a single DNS endpoint that the application can use to connect to the database, it doesn’t much matter what happens on the back end - whether it is clustered, or fails over, it should be seamless to the application.
  • In a failover scenario, so long as the replacement database is read/write, the application should connect to it just fine.
  • Having said that, some configurations of Always On Availability Groups can result in data loss on failover (specifically Forced Manual Failover). I would stick with automatic failover.
  • If you do end up having problems, Support may ask you to disable this feature while troubleshooting, to rule it out as a potential cause. If it’s determined to be the cause, they would be limited in how much further they could help you, as it’s unsupported, so they may ask you to disable it permanently.

Thanks for your reply Denise! I will take your advise and share it in our team.

Specifically looking at Confluence here: When moving from Server to data-center there is a noticeable increase in just the Application license cost (not including any add-ons) and the main selling point is "The main distinction is that Server runs on a single node, while Data Center allows you to run on multiple nodes." per this Atlassian Blog. This is in addition to the recent increase in your base cost beginning this month. My question is as we move forward can we expect Atlassian to do more "included" enhancements (add-ons) and not rely so heavily on the community and other vendors to sell them? It would be nice if we had functionality built into the product since its not a question of whether it can be done (since they are already doing it). 

At the server level it makes sense because the cost is extremely reasonable and Atlassian is not (at least for Confluence) ready for Enterprise size cloud usage; therefore, upgrading to Data-Center quickly moves into the executive spotlight as you look at overall upgrade cost (hardware, Application License, and add-ons).

Looking forward to hearing from the team!

king Atlassian Team Oct 24, 2019

Hey William, good question! If you look back on how Data Center has progressed since it's introduction ~5 years ago, you'll see a kind of evolution occur. Early on, like you said, much of the value of Data Center was simply in the architecture (high availability, performance at scale from horizontal scaling, instant scalability, etc.).

But over the past few years we've started to make Data Center more than just the architecture. With things like project archiving and zero-downtime upgrades in Jira, and read-only mode and analytics for Confluence customers are starting to see Atlassian grow Data Center into a enterprise platform that includes enhanced hardware and enhanced software. I think you'll continue to see Data Center move in this direction.

Like # people like this

Will you work on a better description of self-managed CDN network for Jira DC. As DC is our mitigation to our current single server load problems, but CDN should be our mitigation to our far away remote side performance problems. But the current available documentation is far away form being complete/detailed enough to build up a private/own managed CDM network.

king Atlassian Team Oct 24, 2019

Hey Michael! Thanks for posting... As you know, support for CDN is a fairly new addition to DC. For a long time, Data Center didn't bring much to the table in terms of geographically distributed teams, so I'm super pleased to see that come to the forefront in the form of CDN support. 

Because it is such a new feature we are still in the process of making sure the feature set does exactly what our customers need it to do. Can you, or any other readers, share particular things you are looking to CDN for that you may not fully understand based on looking at our current documentation? How would you like to see our CDN support grow?

With this feedback we can continue to perfect the role that CDN plays in the DC implementation. 

Like # people like this

Hi Benjamin, is it possible for Atlassian to provide a webinar on how Enterprise clients are using CDN and telling us the performance improvements they are realizing?

Thank you,


king Atlassian Team Oct 24, 2019

Hey Joe, thats a great idea, I think that would make a fantastic webinar or topic at Summit. We spoke a bit on it at last years summit... I'll see what we can do for some additional materials on CDN and watch for talks at this years summit on the subject!

Like Joe Pursel likes this


It will be any specific documentation for configuring synchrony in confluence version 6 ( 6.5 - 6.15 ). Currently moving to datacenter testing the oldest EOL ( current version 6.5 ) even if synchrony is running we have the following issue:

" postConfigToSynchrony [Collab editing plugin] Synchrony connection failure: Could not generate/verify AppID/Secret for real-time collaboration service at http://localhost:8091/synchrony/v1 "

Comparing with Confluence 7 it is a lot easier to configure it even with different ports.

Suggest an answer

Log in or Sign up to answer

Atlassian Community Events