A unique part of the way we serve our customers at Atlassian is the variety of deployment options we provide. Customers choose Cloud, Server, or Data Center based on what best suits their needs. This is a great thing for customers because their teams can take advantage of our tools regardless of infrastructure requirements or other preferences in their organization. We’re proud to offer this array of choices.

What isn’t so obvious, though, is how we decide which features go into each of the three deployment options, and when they go in.

In the past, we aimed to keep the three deployment options in lock-step. But now, with the help of your feedback (thank you!), we’re tailoring each option’s evolution to the needs of its core customers.

So let’s take a peek behind the curtain and get a better understanding of how we prioritize development.

Different deployment options for different needs

First, an overview of each option and who its customers are.

Server: This is our original offering, and for many of you, your first experience of Atlassian products. You download our software and install it on a single server that you control. It’s great for teams of virtually all sizes – especially those with specialized needs because of the vast array of add-ons available to help you customize and configure.

Data Center: Many of our Server customers told us that during either planned or unplanned downtime, when Atlassian tools aren’t available to their users, the whole company grinds to a halt. So we introduced the Atlassian Data Center product line. Our Data Center offerings run in a customer’s own data center, or on top of an Infrastructure-as-a-Service provider like Amazon Web Services (AWS). Data Center’s focus is high availability, scalability, performance, and control of your infrastructure. Data Center customers are typically larger companies, often distributed around the globe, for whom reliability, stability, and performance at scale is critical.

Cloud: An increasing proportion of our customers prefer to opt out of managing the infrastructure that supports their Atlassian tools (as well as maintaining or upgrading to newer versions). Many organizations are doing this for all their apps: they don’t want to own any hardware or manage any infrastructure themselves. Cloud customers prefer the software-as-a-service model and like that they are always on the latest and greatest versions of our tools.

As each of our deployment options grows increasingly popular, we’re noticing the feedback we’re getting from each set of customers is increasingly distinct. 

For example, Server customers are asking for easier upgrades, which simply isn’t a concern for Cloud customers. Data Center customers want to reduce latency for their globally-distributed teams, which isn’t an issue for most Server customers. And our Cloud customers are clamoring for integrations with other cloud-based services like PagerDuty or Invision.

In response, we’re making an important change: we will no longer keep our deployment options in lockstep or aim for feature parity across them. Instead, we will prioritize the improvements to each deployment option according to the specific needs of its customers.

How we prioritize updates to each deployment option

All our end-users tell us they love compelling features like real-time collaborative editing in Confluence or code-aware search in Bitbucket. But some sets of customers also have specific data privacy regulations to comply with. Meanwhile, Data Center customers have thousands of users who depend on our tools and place a higher priority on scale and control over their infrastructure.

So you might see us ship design updates or a new feature to Cloud end-users while simultaneously making the version upgrade experience easier for Server admins. The feature will then ship to Server customers at a later date. Backlogs for kanban boards in Jira Software is a perfect example of this: we shipped it to Cloud first, and it’s now available in Jira Software 7.4 in Server.

Sometimes the features flow through in the opposite direction. Take the support for program management in Portfolio for Jira. Program management as a practice is mostly an enterprise thing, so it made sense to ship this feature to Server and Data Center customers (where our larger customers are concentrated) before bringing it to Cloud.

Features that depend on cloud-only services or technology will not be in the Server roadmap. Features that are only relevant for Server or Data Center customers, such as improved installers, won’t be on the Cloud roadmap.

Your preferences, your priorities

With Cloud, Server, and Data Center no longer marching forward in unison, we can tailor each option’s path to best suit your needs. In building out the roadmaps for each deployment option, we look to two of our values in particular: “build with heart and balance”, and “don’t #@!% the customer”. Regardless of your deployment preference – Cloud, Server, or Data Center – we are improving each of them every day in a way that reflects your priorities. And we continue to support your ability to migrate between options as your needs change.

Your feedback will continue to help us shape the future of each deployment option, so keep that feedback coming! While we don’t always get a chance to respond to every request, they do have an impact on our roadmap. Your feedback via Atlassian Community, on our public Jira instance, at Summit, and in all other forums, is how we get better.

For more details on what we’ve been up to and what’s coming soon to each deployment option, check out my contribution to the keynote address at Summit Europe in May. Best part? There’s no pressure to laugh at my jokes. You will do that of your own free will (I assume).

. . .

Which deployment option is right for your team? Explore discussions about Cloud vs. Server vs. Data Center, ask questions, and get answers from Atlassian users who’ve been there and done that.


Explore the Atlassian Community site

Prioritizing updates in Cloud, Server, and Data Ce...