I frequently talk to customers who are considering moving from an on-premise version of Jira--either Jira Server or Jira Data Center—to Jira Cloud. While functionally the applications are very similar, stakeholders should be aware that there are subtle governance and administration differences between them based on how Atlassian built them and design choices they made.
In this post, I’ll walk through the three different types of Jira stakeholders and the differences in how Jira Server and Jira Cloud are administrated that they should be aware of.
Jira Governance: Three Types of Stakeholders
While we’re not going to spend a lot of time on governance in this article, it’s worth reviewing the three types of stakeholders and their roles in Jira governance.
- Business stakeholders: accountable for the decision to fund the total cost of the tool
- Tools administrators (Jira Administrators): accountable for maintaining the tool so that it is useful for the entire organization and complies with corporate policies and standards
- Team leaders (Project Administrators): accountable for adapting the tool configurations to the needs of the specific teams they represent
Next, I will explain what changes to expect when migrating from Server to Cloud in context with each of these stakeholder roles.
Why Does an Atlassian Cloud Migration Mean for Business Stakeholders?
Migrating from Jira Server to Jira Cloud results in some pretty dramatic changes to tool governance. To be candid, it’s often business stakeholders that decide an organization should migrate because of the benefits of outsourcing tool administration. Letting Atlassian be responsible for the availability, security, and reliability of Jira, where there is significant competency, is a pretty big win! Still, there are some trade offs, all of which are pretty straightforward to navigate.
- Business stakeholders need to review and agree on how Atlassian addresses important governance policies. From a tool governance perspective, it is important to understand how Atlassian approaches these key policies. Atlassian is very open and transparent about these topics, so it’s really just a matter of reviewing the information Atlassian provides and ensuring it meets an organization’s standards.
Also of note...by migrating from Server to Cloud, disaster recovery, data security (at rest and in transit), identity/GDPR, and many other responsibilities that come with running a server are now no longer “your problem” from a tool administration perspective.
- Organizations gain the flexibility to let teams maintain configurations if they choose to. This one is a bit more subtle, but most business stakeholders consider it an advantage. Cloud customers tend to value team autonomy more than Server customers. To this end, Atlassian provides a lot of features on Cloud that are probably never going to be released for Server. The best example of this is next-gen project configurations. There are many teams that benefit from more team autonomy, and it’s really, really nice to have the option of letting teams run their own project configurations. It’s still Jira under the hood, though, so if you want to have shared configurations, workflow (process) enforcement, webhooks, and triggers based on events and updates to Jira data, it’s all still there.
- It’s not about cost saving; it’s about increasing flexibility, outsourcing competency, and where to make the best investments. A decision to move from a server-based to a cloud application is not generally a decision just based on cost. I really like to think of it as all about modernization. Today’s teams have learned to ask for and expect to receive a lot more autonomy with regards to tool choice, and are far more accustomed to taking on responsibility for tool configurations themselves.
Jira Administrators Can Apply their Skills More Strategically with Cloud
Most experienced Jira administrators initially consider Jira Cloud less capable than the Server or Data Center versions. To a pretty small degree, they are right. A more rigorous investigation reveals that the majority of features used by Jira Server administrators, while not always exactly the same, are fully supported in Jira Cloud. Notable exceptions include:
- You don’t have access to the underlying database. It’s interesting and fun to look at Jira data in combination with data from other systems (for example, the data in a corporate data lake). With Jira Cloud, there is no way to query the Jira Server database. To interact with data in Jira (Cloud, Server, Data Center) is to use the Rest API to interact with Jira data.
- Atlassian takes care of authentication—tool administrators provide access to the Atlassian Cloud tools. With Atlassian Server, tool administrators can authenticate and provide access to Atlassian tools like Jira. With Atlassian Cloud, Atlassian handles the authentication, while tool administrators provide access to the cloud products. Organizations with enterprise standards for authentication will want to add Atlassian Access to their Atlassian Cloud subscription. This will allow them to connect LDAP directory (like Active Directory), enforce specific password security policies, and integrate with an Identity Provider, which is useful if an organization uses an SSO solution.
- Jira administrators have to review new changes that are coming because these will eventually “just show up” for your users. This is the tradeoff for never having to schedule an upgrade for your Jira application ever again. Atlassian rolls out new features all the time. The more disruptive the changes are, the more lead time and feedback Atlassian solicits. This gives Jira administrators the opportunity to evaluate new features, provide feedback, and importantly, engage in change management so that as these new capabilities are rolled out, Jira users will be well prepared rather than disrupted.
Project Team Leaders Often Ask for Forgiveness...Until Now
There are a lot of cloud applications these days, and integrating between two cloud applications is much easier than integrating between server and cloud applications. For example, GSuite integration is much, much easier with Jira Cloud. Since most reasonably mature cloud applications provide REST API access, it’s easier to address team-specific integrations with a small, compute-based services approach than a monolithic, enterprise application-based approach. This is an especially powerful idea considering that most teams are comfortable doing their own scripting and maintaining team-specific configurations.
Moving from Server to Cloud Means A Different Way of Thinking
No matter how you look at it, Jira Cloud and Jira Server are mostly the same...but with some important differences. I really enjoy helping our customers evaluate the decision to move from Server to Cloud and navigate these differences. I always like to start with identifying the specific outcomes that an organization is most interested in. This keeps all three of these audiences focused on how a move like this will affect them and how the organization as a whole will benefit.