Description
Things to know when migrating between platforms or needing to deal with both platform instances in your company. Since the origins of the Cloud and Server versions of Jira are the same, we are fortunate that the underlying REST API platform that the CLI depends on is largely the same including the same underlying constructs and concepts. The same Jira CLI client supports both Cloud and Server instances. This means interface definition and abstraction are identical. Our intention is to maintain this level of compatibility as much as possible in the future as well.
The CLI supports a wide range of Jira Server releases and that means that there may be release specific differences as Jira and CLI support improves over time. We do this normally in an upward compatible way to protect customer's investment in scripts as we add new actions, parameters, and output. For example, an action may only work successfully when used against an instance of Jira 7.5 or above. This is handled with the appropriate error messages and documentation. Cloud is treated similarly. There may be actions or capabilities that are only available on Cloud or specific releases of Server. The vast majority of functions are the same and then there are a few cases where there are differences and those differences may change depending on Jira Server version as time goes on.
Specific Differences
- Authorization and user management related actions - there are a number of underlying differences in information available and actions that can be done. Specifically, Cloud uses Atlassian id which has significant differences that standard Jira Server user management. Also, Cloud now support and recommends using Atlassian API tokens in place of passwords. In fact, password usage has been deprecated and likely be removed in 2018. This means usage of the CLI will require user's generate the appropriate key for their Atlassian id.
- Space link actions - Cloud only
- Add and remove application link actions - Server only
Migration Planning
You should be able to treat a migration similar to a application upgrade. Plan for some validation testing. Update your scripts for the server address and authorization changes. Review your scripts and automation documentation to understand areas of that may be affected by specific differences listed above.
We have no configuration or other data that needs to be migrated between instances.
