Migration to Cloud
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. Also please check https://releasemanagement.atlassian.net/wiki/spaces/TRUSTRM/pages/2615869441/Data+Processing+Addendum+DPA#EXHIBIT-B:-Technical-and-Organizational-Security-Measures |
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 https://releasemanagement.atlassian.net/wiki/spaces/TRUSTRM/pages/2615869441 |
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: https://releasemanagement.atlassian.net/wiki/spaces/RM4J/pages/2573828097 |
More details
Migration automation
As of now (Oct 29th, 2022) we do not have a tool for migration automation. We also do not have it on roadmap till EOY 2024. Up-to-date roadmap could be always found here at our Server or DataCenter Apps BIO @ Atlassian Marketplace.
What are the options?
If you have a decent amount of Boards with created Releases, Notes Templates, Environments and Milestones you might consider to automate the migration. There’s a technical possibility to do so. For this you would need an engineering arm in your organization or engage with one of Atlassian solution partners to advice with complete migration.
Both Apps have REST API available.
Server and DataCenter Apps:
More details about Rest API for Datacenter App could be found here:
Cloud Apps:
More details about Rest API for Cloud App could be found here:
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.
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
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
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
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
Result column / value details
Column | Value |
|---|---|
gadget_type | Type of gadget:
|
gadget_count | number of gadgets |
Any assistance you might need on the way please contact our support team.
Functionality parity
Core functionality
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 |
|---|---|
Virtual Versions (Epics and JQL based) | Virtual Versions (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 |
|---|---|
3rd party JQL functions are not supported by Jira Cloud Platform | |
Q1, 2023 | |
Export Gadgets to Confluence | 3rd party Gadgets are not supported by Jira Cloud 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 | |
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.