In this page

Overview

Better PDF Exporter supports all the three Jira deployment types: Server, Data Center and Cloud. While the first two are essentially the same in terms of the app features, Cloud is a bit different.

This page is a summary of the differences plus a practical guide to migrate your app data to Cloud. It aims to help your team maintain the app functionality when moving from Server or Data Center to Cloud.

Differences between Server/Data Center and Cloud

When you consider moving to Cloud, you should be aware of the differences between your current deployment type and Cloud. This section is a summary of those.

Platform differences

Jira Server/Data Center Jira Cloud
Where are the app and its resources located? The app is running on the same server and in the same Java Virtual Machine (JVM ) as Jira does. The templates and scripts are saved to the Jira database. The app is running in the cloud, more precisely in an Amazon AWS environment operated by Midori. The templates and scripts are saved to a secure cloud-hosted database.
How can the app communicate with Jira and other Jira apps? Through the public Jira Java API and Jira REST API - inside the same JVM where Jira is running. (It is possible to access non-public Java API if required for your use case.) Through the public Jira Cloud REST API - over the public internet. (No access to non-public APIs.)

Feature differences

Note that the features not mentioned here are basically the same across all deployment types.

Jira Server/Data Center Jira Cloud
Integrations The integrated apps are different: see the integrations available on Server (Data Center is the same). The integrated apps are different: see the integrations available on Cloud.
Automation Available through the free Better PDF Automation for Jira app. Not available yet. If it would be useful for your team, please vote on the feature request!
REST API Available, see the REST API page. Not available yet. If it would be useful for your team, please vote on the feature request!
Dashboard exports The supported gadgets are different: see the supported gadgets on Server (Data Center is the same). The supported gadgets are different: see the supported gadgets on Cloud.
PDF view visibility Views can be optionally restricted to certain groups, users or issues (specified by JQL). Views are visible for all users. (We will add the access control feature later.)
Export limits Virtually unlimited. The capacity of your own systems are setting the limit for export computations. The number and the duration of the exports are limited by a quota system. It's a protection for extreme cases. Normal business usage will not be disturbed.

Migrating from Server/Data Center to Cloud

When you decided to move to Cloud, you need to migrate your existing PDF views and PDF resources.

Migrating PDF views

PDF views are the export options that appear in the "Export" menus on different Jira screens. You can manage these under the PDF Views administration section of the app.

When you install the app on Jira Cloud, the default PDF views are created automatically. If you are happy with these, then there is nothing to migrate.

If you changed the configuration the PDF views on Server (created new ones, edited some, deleted some), you just need re-apply those configuration changes on Cloud. The configuration options are 90% the same on Cloud and Server (to be precise, some options are missing on Cloud), therefore the migration is trivial.

Migrating PDF resources

PDF resources include the PDF templates, Groovy scripts and other configuration files. You can manage these under the PDF Templates administration section of the app.

If you haven't customized any resources on Server, there's absolutely nothing to do when you move to Cloud. Just install Better PDF Exporter for Jira Cloud, and all default resources will be created, similarly as in the Server version. You can start to use those immediately.

In case you have customized default resources or created custom resources (typically a new PDF template), you need to migrate those manually. Please read the following sections for practical hints. If you are unsure whether you are using custom resources or not, consult with your Jira administrator.

Migrating customized default resources

"Customized default resources" mean those PDF templates and Groovy scripts that came with the app built-in, but you modified them. If you have customized those resources, then you need to make sure to migrate those manually.

This should be done by comparing the content of your customized resource with the corresponding one in Cloud, and merging all changes you made in the former to the latter. For example, if you customized the issue-fo.vm template in your Server version, you should find the default issue-fo.vm template in the Cloud version, and merge those. Use a visual merge tool (like WinMerge or Eclipse's compare and merge editor).

Please note that a few default resources may not have their corresponding versions on Cloud. Those resources and features have been dropped intentionally, or have not been implemented yet. Please refer to the feature differences table above or check the known limitations to learn more.

Migrating custom resources

"Custom resources" are those PDF templates and Groovy scripts that you created from scratch. If you have a custom resource to migrate, then simply re-create it on Cloud: just create a new resource with the identical name on Cloud, and copy the content from the Server resource to this new one.

During the design of the app's Cloud version, we tried our best to make the app 100% compatible with the resources created in the Server version, although it's not always possible. Especially in case of Groovy scripts, there is a chance of required modifications. If you find that some template parts or Groovy code is not working on Cloud, please feel free to ask our team for help.

Questions?

Ask us any time.