In this page

Migrate from Jira Server/Data Center to Jira Cloud

The Better Commit Policy for Jira app is available for all three Jira deployment types: Server (legacy), Data Center, and Cloud.

While Server and Data Center share the same app features, the Cloud version is built on a different infrastructure and REST API, which makes it work differently in key areas. This new environment required us to rebuild the app from the ground up, and we used the opportunity to make it even better by applying the knowledge and experience gained from the self-hosted versions.

This guide will help you transition the app from Jira Server/Data Center to Jira Cloud.

How to read this guide

We've broken the guide down into multiple sections. We recommend reading them in this order:

  1. Key changes: Terminology and design changes.
  2. Feature parity: A comparison of equivalent features.
  3. Step-by-step instructions: A clear, executable plan for carrying out the migration process.

Key changes

Migrating from the Server/Data Center to Cloud involves more than transferring configuration and data. It requires adapting to a platform with different terminology and different features, even if the core functionality remains the same.

Terminology changes

As you transition to the Cloud version, some terms may differ from those used in the Server/Data Center versions. This section explains these changes in terminology to help you easily adapt to the Cloud app's vocabulary.

Server/Data Center term Cloud term Notes
Local verification Local check We chose the less formal term “check” because most users already use it, and it’s becoming standard in the DevOps world.
(Push) verification Push check We chose "push" as more precise prefix, and it's also becoming standard.
Pull request verification Merge check We chose "merge check" because it's also becoming standard.

Product changes

The following changes have been implemented to align with the Atlassian Cloud platform's architecture and APIs and to improve the overall user experience. We also used this transition as an opportunity to expand the app's capabilities and introduce new features that weren't possible in the Server/Data Center versions.

Git is the primary Version Control System

The Server/Data Center versions support multiple Version Control Systems, including Git, Subversion, and Mercurial, through a generic architecture.

In the Cloud version, we focus primarily on Git, the most widely used VCS on the Atlassian Cloud platform. This focus allows us to optimize the app for Git’s model and workflows. It also lets us make full use of its capabilities on Bitbucket Cloud, GitHub and GitLab.

(Even with this focus, we may support Version Control System other than Git in the future.)

Commit policy as code approach

In the Server/Data Center versions, commit policies are configured through the Jira web interface.

In the Cloud version, we adopted an x-as-code approach. Commit policies are configured in a YAML file stored in the repository. This lets teams define flexible policies for different repositories or branches and maintain consistency across projects. It also enables collaboration via familiar workflows like pull requests, integration with other tools such as automation or security platforms, and a clear audit trail of policy changes.

Smarter connector apps

The commit checker mechanism is made up of two apps: the mandatory "Jira app" on the Jira side, and the optional "connector app" on the Version Control System side. The main difference lies in which parts of the functionality they handle.

In the Server/Data Center versions, a large part of the functionality (such as centralized management of commit policies) is handled by the Jira app. Only "deep integration" features, like displaying pull request verification results, are handled by the connector app.

This approach makes sense because it allows support for Version Control Systems without a web management interface, and therefore without a connector app, like Subversion. However, many users find it confusing when looking for certain functionality on the connector app's side.

In the Cloud version, all end-user functionality is implemented in the connector app. This provides more seamless integration with Bitbucket Cloud, GitHub, and GitLab, offering a more native and consistent user experience.

More flexible rules and conditions

In the Server/Data Center versions, commit policies are configured through a web form. While intuitive and easy to use, the UI has limitations that make complex rules difficult. For example, logical combinations like "A and (B or C)" are not supported.

In the Cloud version, we introduce a much more flexible system for rules and conditions using a configuration language. As it evolves, it will enable more complex and tailored commit policies. (We have several exciting ideas in store for both declarative and imperative policy definitions!)

In the Server/Data Center versions, Jira and Bitbucket are connected using application links. They are the standard and secure way to integrate Atlassian products, but work only within the Atlassian ecosystem.

In the Cloud version, we replaced application links with VCS connections. A VCS connection is a generic way to connect to external Version Control Systems, including Bitbucket Cloud, GitHub, GitLab and others.

Feature parity

Core features are still available, though their locations and how they work may have changed. This section helps you find and use them quickly.

Server/Data Center feature Cloud feature Notes
Local verification Local check Although it's not available yet, we are already working on this feature! It will be a significantly improved reimplementation of the Data Center version, using Git's modern core.hooksPath option for centralized hook management.
(Push) verification Push check For now, push checks can't be implemented for Bitbucket Cloud due to an Atlassian platform limitation. Once this limitation is resolved, we'll be able to add push checks.
Linking commit policies to Jira projects Configuration file Anyone with write access to the .commitpolicy.yml configuration file in a repository can modify the commit policy. This follows the typical "x-as-code" permission model.
Tag rules Not available yet This feature is on our mid-term roadmap.
Branch rules Not available yet This feature is on our mid-term roadmap. (Conditions for pull request source and destination branches are already available!)
Scope limiting to branches Not available yet This feature is on our mid-term roadmap.
Scope limiting to paths Not available yet This feature is on our mid-term roadmap.
Global settings Configuration file Global settings were moved to the .commitpolicy.yml configuration file so that it can server as a single, self-contained unit.
Subversion specific global settings Removed Subversion is not supported anymore. That's why "Subversion branch pattern" and "Subversion tag pattern" have no equivalent.

Migration guide

Coming soon!

Questions?

Ask us any time.