Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Note

Migration from Server/Data Center to Cloud with The automatic migration of rich filter gadgets with JCMA is supported by Rich Filters for Jira Dashboard versions lower than the Jira Dashboards starting with version 2.1.27.0 is deprecated. Please We recommend you use the latest Rich Filters for the Jira DashboardsData Center app version to perform your migration. 

Contents:

Table of Contents
minLevel1
maxLevel4
outline3false
stylenone
typelist
printabletrue

Anchor
section1
section1
1. Introduction

Note

Before migrating Rich Filters for Jira Dashboards the app data from the Jira Server or Data Center to Jira Cloud, please first check out the Feature Parity—Serverparity – Cloud vs Server/Data Center vs. Cloud comparison documentation page.

The Rich Filters for Jira Dashboards app uses two different types of data that need to be migrated:

  1. The configuration of the rich filters defined on your Jira instance;

  2. The configuration of the rich filter gadgets used in dashboards on your Jira instance

...

  1. .

...

For the migration of the rich filters, you have two possible options:

  • Migrate your rich filters automatically using the Jira Cloud Migration Assistant (JCMA); the next documentation section describes this migration path in detail;

  • You must migrate your rich filters manually, recreating them manually from the Server/Data Center instance on your Cloud instance.

...

It is, of course, possible to migrate the app data manually, by recreating in the target Cloud instance the same configuration as in the source Server/Data Center instance. Consider this approach if you have few rich filters and rich filter gadgets to migrate, especially if you intend to use the migration as an opportunity to change some of your Jira and/or app configuration. There are no specific instructions for the manual migration of the app data, since it is a straightforward process. The rest of this page concerns the automatic migration of the app data.

Starting with the version 2.1.0 of the app, both the rich filters and the rich filter gadgets can be automatically migrated using the Jira Cloud Migration Assistant (JCMA) allows you to automate the migration of your rich filters from the Jira Server/Data Center to Jira Cloud. More precisely, during a migration run, JCMA first migrates your Jira data and then orchestrates the migration process for 3rd party apps that have added specific support for JCMA.our app.

Anchor
section2
section2
2. Automatic migration of the app data

Note

Migrating your data from Jira Server/Data Center to Jira Cloud using JCMA requires detailed planning and several configuration steps. For more details, see Use the Jira Cloud Migration Assistant to migrate. Below, we refer only to the configuration steps for migrating the rich filters.

I) Before launching the JCMA migration

...

that are related to the migration of the Rich Filters for Jira Dashboards app data.

Step #1 - Install required software

On your source Jira Server/Data Center instance, make sure ensure you have installed the following:

On your destination, target Jira Cloud instance, ensure you have installed and licensed the Rich Filters for the Jira Dashboards Cloud app.

Step #2 - Assess your apps

The first step in configuring preparing a JCMA before launching a migration is "1. ASSESS YOUR APPS" Assess your apps on the Migration Assistant home screen—more information is available here. In this step, you must choose which apps to migrate to the Cloud.

  • You need to mark Rich Filters for Jira Dashboards as Needed in cloud. Note that all the rich filters will be migrated.

  • If you also use rich filter extension apps, you must mark them all as Not needed in cloud.

On Cloud, the functionality provided by Rich Filters::Service Management Dashboards is available as part of the main Rich Filters for the Jira Dashboards app. Hence, when migrating the main rich filters app, the data provided by this rich filters extension is also migrated. Currently, the functionality provided by Rich Filters::Time Tracking Dashboards is not supported on the Cloud.

II) After completing the JCMA migration

After the JCMA migration, the following steps must be completed on the destination Jira Cloud instance.

...

Note

Migration best practices

JCMA allows you to run migrations from the same source Jira Server/Data Center instance to the same target Jira Cloud instance multiple times (for example, in order to migrate your projects gradually, if this is useful to you). We recommend you migrate your Jira data and your app data only once, i.e. in one migration run. If you need to migrate your Jira data in several migration runs, you must enable the migration of the Rich Filters app only once, in the last migration run. This is because, if the app data migration happens before all Jira data is migrated, any references to Jira objects (such as Jira filters, custom fields or dashboards) that are missing on Cloud will not be migrated, so your rich filters and/or rich filter gadgets might not be correctly migrated.

In the explanations below, we assume you follow the recommended path described above.

Step #3 - Configure JCMA to migrate all filters and dashboards

Rich filters are based on (have a reference to) saved Jira filters. It In order for this reference to be preserved during the migration, it is important that all the Jira filters that are referenced in rich filters be already migrated before when the rich filters are migrated (see the section Migration best practice below). JCMA allows you practices above).

The latest versions of JCMA provide support for Jira dashboard migration. The migration of dashboards with rich filter gadgets happens in two steps. In the first step, JCMA creates the dashboards on the target Cloud instance and migrates the native Jira gadgets (but not third-party gadgets). In the second step, the app migrates the rich filter gadgets on these dashboards. It is therefore important that all the dashboards that contain rich filter gadgets be already created by JCMA when the app data is migrated (see the section Migration best practices above).

Therefore, you should configure JCMA to migrate all Jira filters and all dashboards. To do this, and that is the option we recommend – in the JCMA migration configuration step Select dashboards, boards and filters you need to select the option options Dashboards/All dashboards and Boards and filters/All filters and cross-project boards in the setting Migrate boards and filters. For details see What gets migrated with the Jira Cloud Migration Assistant and How dashboards, boards and filters are migrated.

Step #4 - Enable app migration

To do this, in the JCMA migration configuration step Select apps you need to select the option All - marked as Needed in cloud with a migration path. If you have other apps marked as “Needed in cloud”, make sure you consult the migration documentation of those apps as well.

Step #5 - Start the migration

Once you start the migration, JCMA first migrates your Jira data and then orchestrates the migration process for the Rich Filters app. When the app has finished the migration, your migration details screen will show a status and a progress percentage for the app. If all the rich filters and all the rich filter gadgets are migrated successfully, the status will be COMPLETE and the progress will be 100%.

...

Anchor
section3
section3
3. Verification and adjustments

After the JCMA migration, the following steps must be completed on the destination Jira Cloud instance.

Step #1 - Check the base Jira filters

In this step, you need to check that all the migrated rich filters have a base Jira filter.

If any migrated rich filter doesn’t have a base Jira filter (i.e. the base Jira filter is NOT SET), you need to find out whether the corresponding Jira filter has been migrated prior to the migration of the rich filter. More precisely, the Jira filter must have been migrated in the same migration run as the rich filter , (or in a previous but recent migration runrun—see the section Migration best practices above). If these conditions are met, yet the reference is broken, please create a support ticket so that our team can investigate the issue. If these conditions are not met, you will need either a) to identify the cause and fix the problem, and then run the migration again from scratch, or b) to manually create the missing Jira filter and/or set it as a base filter in the configuration of the migrated rich filter. We remind you that rich filters can only administrators can edit rich filters be edited by their administrators (for more details, see the Rights and Permissions documentation page).

Tipexpand
titleHow to get a list of your rich filters

If you wish to obtain a flat list of rich filters together with their base Jira filters on the source Jira Server/Data Center instance, you can run the following SELECT SQL query on Jira's database:

Code Block
languagesql
SELECT rf.ID as rich_filter_id, rf.NAME as rich_filter_name, 
	   jf.id as jira_filter_id, jf.filtername as jira_filter_name, 
       jf.authorname as jira_filter_owner, jf.reqcontent as jira_filter_jql
FROM AO_24D977_QRFRFE0 rf INNER JOIN searchrequest jf ON rf.JIRA_FILTER_ID=jf.ID 
ORDER BY jira_filter_id, rich_filter_id;

If your database server is PostgreSQL, then you might need to add double quotes around the upper-case identifiers – see below: 

PostgreSQL
Code Block
languagesql
SELECT rf."ID" as rich_filter_id, rf."NAME" as rich_filter_name, 
	   jf.id as jira_filter_id, jf.filtername as jira_filter_name, 
       jf.authorname as jira_filter_owner, jf.reqcontent as jira_filter_jql
FROM "AO_24D977_QRFRFE0" rf INNER JOIN searchrequest jf ON rf."JIRA_FILTER_ID"=jf.id
ORDER BY jira_filter_id, rich_filter_id;

The SQL query above will return the list of rich filters (id and name) and the Jira filters they are based on (id and name), the author of those filters, and their JQL.

Step

...

Update custom field ID references in JQL.

Moreover, if any of your JQL clauses referred to a custom field using its cf[id] form, that reference is not automatically updated either. For example, if on your Jira Server/Data Center you used the JQL query cf[...] is not empty, then the reference to the custom field ID is not translated when migrating to the Cloud. The JQL clause is migrated as-is, but the ID of the migrated custom field might be different on Cloud. Hence, if you used any such custom field references in your JQL, you must manually update them on the Cloud.

Tip

We have asked Atlassian to help us automate this step. Please watch and vote for MIG-1021 – Provide API to convert all JQL from Server to Cloud.

Note

Migration best practice

JCMA allows you to run migrations from the same Jira Server/DC instance to the same Jira Cloud instance multiple times (for example, to migrate your projects gradually if this is useful to you). We recommend you migrate your Rich Filters for Jira Dashboards app data only once, after you have migrated all your Jira data. If you migrate your rich filter data before you have migrated all your Jira data, then references to missing Jira data will not be migrated, and your rich filters might not be completely migrated.

If you migrate the rich filter data multiple times, the already migrated rich filters will not be migrated a second time. Nevertheless, if you migrate a rich filter to the Cloud and then delete it, if you migrate the rich filters again, then the deleted rich filters will be migrated again. We don't recommend migrating rich filters multiple times unless it's absolutely necessary.

...

Alternatively, instead of using JCMA, you also have the option to migrate your rich filters manually—i.e., recreate the same rich filter configurations on your Cloud instance. One advantage of this approach is that you can decide not to migrate rich filters that are no longer used.

The SELECT SQL query provided in Step #3 above can be useful to obtain a flat list of rich filters on your Jira Server/Data Center instance.

...

Unfortunately, Atlassian does not currently provide support for the automatic migration of third-party gadgets from Jira Server/Data Center to Jira Cloud. For this reason, at least for now, you can only manually migrate your rich filter gadgets. You need to recreate the same dashboards as on the Jira Server/Data Center instance, using the migrated rich filters, as described above.

...

We hope Atlassian will soon provide the necessary technical framework so that we can automatically migrate the rich filter gadgets too. Please watch and vote for MIG-1937 – Support Third-Party Gadgets in JCMA Dashboards

...

#2 - Check the rich filter gadgets

In this step, you need to check that all the rich filters gadgets have been correctly migrated.

It is expected that Server/Data Center app features that are not supported on Cloud will result in misconfigured gadgets.

For example gadgets configured with features from the Rich Filters::Time Tracking Dashboards app extension will show an error in the migrated dashboard. The misconfigured gadgets will need to be manually reconfigured or deleted in the Cloud instance.

Expand
titleHow to get a list of your rich filter dashboards

If you wish to obtain a flat list of dashboards that use rich filter gadgets on the source Jira Server/Data Center instance, then you can run the following SELECT SQL query on Jira's database:

Code Block
languagesql
SELECT distinct d.id as dashboard_id, d.pagename as dashboard_name, d.username as dashboard_owner_username, 
       p.userprefvalue as rf_id, rf.NAME as rf_name
FROM portalpage d, portletconfiguration g, gadgetuserpreference p, AO_24D977_QRFRFE0 rf
WHERE d.id = g.portalpage
	AND g.id = p.portletconfiguration
	AND p.userprefkey = 'rf'
	AND p.userprefvalue = rf.ID
ORDER BY dashboard_id;

If your database server is PostgreSQL, then you might need to add double quotes around the upper-case identifiers and match the types of ID columns – see below: 

PostgreSQL
Code Block
languagesql
SELECT distinct d.id as dashboard_id, d.pagename as dashboard_name, d.username as dashboard_owner_username,
       p.userprefvalue as rf_id, rf."NAME" as rf_name
FROM portalpage d, portletconfiguration g, gadgetuserpreference p, "AO_24D977_QRFRFE0" rf
WHERE d.id = g.portalpage
    AND g.id = p.portletconfiguration
    AND p.userprefkey = 'rf'
    AND p.userprefvalue = cast(rf."ID" as varchar)
ORDER BY dashboard_id;

The SQL query above will return a list of dashboards that use at least one rich filter gadget. For each dashboard, the query returns the dashboard ID, dashboard name, dashboard owner, and the ID and name of the rich filter used in that dashboard. The same rich filter can be used in multiple dashboards, and each dashboard can use multiple rich filters. There is an n-to-n relationship between dashboards and rich filters.

Step #3 - Check the JQL clauses

Update custom field ID references in JQL

If any of your JQL clauses in the configuration of rich filters or rich filter gadgets refers to a custom field using the cf[id] form, that reference is not automatically updated during the migration. For example, if on your Jira Server/Data Center you used the JQL query cf[...] is not empty, then the reference to the custom field ID is not translated when migrating to the Cloud. The JQL clause is migrated as-is, but the ID of the migrated custom field might be different on Cloud. Hence, if you used any such custom field references in your JQL, you must manually update them on Cloud.

Tip

We have asked Atlassian to help us automate this step. Please watch and vote for MIG-1021 – Provide API to convert all JQL from Server to Cloud.