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 Confluence 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 Confluence 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 Confluence Server releases and that means that there may be release specific differences as Confluence 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 Confluence 6.0 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 Confluence Server version as time goes on.

Specific Differences

1. 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 Confluence 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.
2. 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. 

Customers may have scripts using add or store page or similar with wiki or storage format page content. That content may contain macros that are not available on the target instance. That content should be reviewed and updated where needed. There may also be Confluence storage format differences that may cause problems, however, storage format is usually upward compatible. 

We have no configuration or other data that needs to be migrated between instances.