Last update: November 17th, 2023
If you are considering to migrate your Jira instance to Cloud we we would be happy to introduce our Release Management & Roadmap -Jira Cloud App. This post is mainly about “How to migrate?” and “What is the difference?” so you can make an educated decision.
Let’s start with so quick Q&A.
FAQ about Cloud App
Question | Answer |
---|---|
Is it secured? | Yes, we are Cloud security Participant in collaboration with Atlassian & Bugcrowd where 300+ researches are continuously trying to breach our security. As a result of this effort and meting reliability and resilience requirements we are now Cloud Fortified by Atlassian. |
Did they find any vulnerabilities? | Yes, |
a number items were reported. All of them are fixed on timely manner. We have a practice in place to communicate within 48hours any P1 and P2 items found and our action to eliminate. | |
Where the data is stored? | Distributed cluster in two location in Europe (Germany, Finland). Also backups in AWS (Germany). |
Is it GDPR/CCPA compliant? |
Yes, please check Data Processing Addendum (DPA) |
The biggest client tier using the App? |
(performance concerns) | 5000 (as of |
Nov 17th, |
2023) | |
Is there any automation migration tool? | Nope, but there are options to automate migration though. See below. |
Functionality is the same or different? | Both. Core functionality is the same. There’s approx. |
10% deviation in features. Some are pending development for another App. Others - we do not have plans to migrate. See below. | |
Do you plan to abandon Server Apps? | Nope, not at all. We have single code base for Server and DataCenter and we actually keep on investing in the Apps as the segment is keep on |
stable. So, while Atlassian allows upgrade of Server versions … clients will be receiving the same builds we are preparing for DataCenter edition. Read more here: Supporting Server Clients |
More details
Table of Contents | ||||
---|---|---|---|---|
|
Migration automation
As of now (Aug 8thOct 29th, 20212022) we do not have a tool for migration automation. We also do not have it on roadmap till EOY 20212024. Up-to-date roadmap could be always found here at our Server or DataCenter Apps BIO @ Atlassian Marketplace.
...
Server and DataCenter Apps:
...
Info |
---|
More details about Rest API for Datacenter App could be found here: Swagger: Rest API & Integrations |
Cloud Apps:
...
Info |
---|
More details about Rest API for Cloud App could be found here: Swagger: Rest API & Integrations |
When it comes to APIs we eat our own dog food and use the same API to build frontend of our Apps. So for sure you can use both to retrieve the information you want to migrate and create it with Cloud App.
Annex: Migration of Gadgets
Automated migration of Gadgets is not supported
As of now (Nov 17th, 2023) Jira Server/Datacenter to Cloud Migration tool does not support Jira Dashboards and Third Party Gadgets (Partner Gadgets) migration described in this feature request https://jira.atlassian.com/browse/MIG-164. That’s why we have equipped you with the following tips to help you with the manual migration of gadget configurations.
Assistance with manual migration of Gadgets
Once you migrated your Jira data from Server/Datacenter to Cloud, you need to manually recreate gadgets and their configurations. First, however, you need to know what gadgets were added to which dashboards.
You can fetch that information using SQL queries run in your Jira database.
Info |
---|
SQL snippets have been tested in Postgres and MySQL databases but should work in all other Jira-supported databases either as is or with minimal modifications. |
List of Dashboards where Release Gadgets are used
Postgres
Code Block | ||
---|---|---|
| ||
SELECT jira.baseurl || '/secure/Dashboard.jspa?selectPageId=' || pp.id as "dashboard_url",
pp.pagename as "dashboard_name",
pp.username as "dashboard_owner",
count(pc.id) as "gadget_count"
FROM portletconfiguration pc,
portalpage pp,
(select propertyvalue "baseurl"
from propertyentry PE join propertystring PS on PE.id=PS.id
where PE.property_key = 'jira.baseurl') "jira"
WHERE pc.portalpage = pp.id
AND pc.gadget_xml LIKE '%release-management%'
GROUP BY pp.id, jira.baseurl
ORDER BY "gadget_count" DESC; |
MySQL
Code Block | ||
---|---|---|
| ||
SELECT concat(jira.baseurl, '/secure/Dashboard.jspa?selectPageId=', pp.id) as "dashboard_url", pp.pagename as "dashboard_name", pp.username as "dashboard_owner", count(pc.id) as "gadget_count" FROM portletconfiguration pc, portalpage pp, (select propertyvalue "baseurl" from propertyentry PE join propertystring PS on PE.id=PS.id where PE.property_key = 'jira.baseurl') as jira WHERE pc.portalpage = pp.id AND pc.gadget_xml LIKE '%release-management%' GROUP BY pp.id, jira.baseurl ORDER BY "gadget_count" DESC; |
Result column / value details
Column | Value |
---|---|
dashboard_url | dashboard url that can be used for quick access to dashboard in the browser |
dashboard_name | dashboard name |
dashboard_owner | dashboard owner (Jira user name) |
gadget_count | number of gadgets on the dashboard |
List of Release Gadgets that are used across all Dashboards
Postgres
Code Block | ||
---|---|---|
| ||
SELECT substring(pc.gadget_xml, 'gadget/gadgets/(.*).xml') as "gadget_type",
count(pc.gadget_xml) as "gadget_count"
FROM portletconfiguration pc,
portalpage pp
WHERE pc.portalpage = pp.id
AND pc.gadget_xml LIKE '%release-management%'
GROUP BY pc.gadget_xml; |
MySQL
Code Block | ||
---|---|---|
| ||
SELECT trim(trailing '.xml' from substr(pc.gadget_xml, length(substring_index(pc.gadget_xml, '/', 6))+2)) as "gadget_type",
count(pc.gadget_xml) as "gadget_count"
FROM portletconfiguration pc,
portalpage pp
WHERE pc.portalpage = pp.id
AND pc.gadget_xml LIKE '%release-management%'
GROUP BY pc.gadget_xml; |
Result column / value details
Any assistance you might need on the way please contact our support team.
...
We have good parity for the core features of the app with maybe small adjustment - we started to use a notion of “Packages” in Cloud Apps instead of cross-project “Releases“ to avoid confusion with Jira Releases (that are de-facto versions).
Server and DataCenter App | Cloud App |
---|---|
Epics and JQL based) |
Epics, Sprints and JQL based) | |
Kanban-like, Roadmap and Calendar Views | |
Track source code changes (plus Builds and Deployments) | |
Custom Properties (plus User Type, Filters by Properties, Properties in Hooks, Release Notes) | |
Server, Datacenter only
Server and DataCenter App | Cloud App |
---|
No plans so far
Extended Roadmap Filtering
Q1, 2022
3rd party JQL functions are not supported by Jira Cloud Platform | |
Q1, |
Versions and Environments Tables in Release Notes
Q2, 2022
2023 |
Export Gadgets to Confluence |
3rd party Gadgets are not supported by Jira Cloud |
Comments and Transition History
Platform | |
Assignee & Watchers (plus notifications via email upon changes made to versions/releases) | Could be partially covered with Custom Properties of User Type (no notification is enabled thought) |
Statistics by Issue Count, Story Points and Ideal Hours | Statistics by Issue Count only |
Ask for “Release Date” upon Release | No plans so far |
Cloud only
Server and DataCenter App | Cloud App |
---|
No plans so far |
Q1, 2022
Partially. In-scope of Release only.
(no plans to align at the moment)
No plans so far | |
Swimlanes (Packages for Board view and Packages, Projects for Roadmap view) | Custom Swimlanes (Projects, Packages, Tag & Types across Board and Roadmap views) |
Predefined color schema | |
No plans so far | Epic start/due dates sync |
No plans so far | Amend Environment Types and custom Environment swimlanes |
No plans so far | Collapse header and gain more space |
No plans so far | Multi select on the Board view and Build operations |
No plans so far | Hide items older than ... |
No plans so far | Update versions status upon package move |
We suggest to kick off a trial with Cloud solution before you decide to migrate to check all the features you use in Server/Datacenter versions. Any assistance you might need on the way please contact our support team.