Jira Cloud migration
This Page is an FAQ for upcoming migration of Qt's bug tracking system to the Atlassian cloud. The migration is planned for September 2025.
Rationale
In 2024 Atlassian discontinued the support for the Jira Server version. The only alternative option for Open Source usage is a Jira Cloud license. This means the current content from https://bugreports.qt.io must be migrated to https://qt-project.atlassian.net. After this migration bugreports will stay around as read-only reference for some time to come.
Migrated projects
The following projects were migrated to https://qt-project.atlassian.net.
| Coin (COIN) | Qt Design Studio (QDS) | Qt Tools for Android (QTTA) | Qt AS Partners Only (QTAUTO) |
| Qbs ("Cubes") (QBS) | Qt Extensions (QTEXT) | Qt Visual Studio Tools (QTVSADDINBUG) | Qt Product Management Organization (QTPMO) |
| Qt (QTBUG) | Qt Installer Framework (QTIFW) | Qt WebBrowser (QTWB) | Qt Requirements Management (QTPM) |
| Qt 3D Studio (QT3DS) | Qt Playground Projects (QTPLAYGROUND) | Qt for Python (PYSIDE) | Qt Product Installation Framework (QTPIF) |
| Qt Bugtracking interface (QTJIRA) | Qt Project Website (QTWEBSITE) | VS Code Extension (VSCODEEXT) | |
| Qt Creator (QTCREATORBUG) | Qt Quality Assurance Infrastructure (QTQAINFRA) | Qt Automotive Suite (AUTOSUITE) |
This is not the complete list of all projects on bugreports. In particular old projects or QtC internal projects were left behind. Other cases involve The Qt Company specific projects which were migrated to a different Jira Cloud instance.
Timeline & Target
The target server is https://qt-project.atlassian.net.
| State | Status | Time Line | Description |
|---|---|---|---|
| Test migrations | Ongoing | Started on 16. June 2025 | Admin working on playbook for migration. Users cannot log into the instance yet but the Jira cloud instance is publicly visible. |
| User acceptance tests | Not started | August 2025 | Voluntary testers collect first impressions, log in and can interact with a copy of the data. |
| Final migration | Not started | Planned for September | The day when the data is moved for good and bugreports becomes read-only. |
First login
During the migration the email of each user is migrated to the Atlassian user directory and an invitation is being sent out. The invite comes from id.atlassian.com and was sent by "Alex Blasche". You have to accept the invite which ultimately leads to an Atlassian login prompt.
If the user has an Atlassian identity/account with the same email already, your existing account will gain access to an additional Jira instance. Out of the box, Atlassian already offers a couple of identity provider integrations such as Google, Microsoft & Apple. Alternatively, you may use a simple email+password combination. If this is the first time that an Atlassian login is used and none of the existing identity providers matches, you may have to select the Can't log in? option to reset the account password.
Using qt.io Email address
if you are using a qt.io email address, please choose the Microsoft Identity provider option.
Adjusting personal setup after first login into the cloud instance
Update your personal setting
If you log into the system for the first time, please update your profile and personal settings. Quite a few personal options such as profile, privacy, security, email notification & account preferences can be found behind those links.
Filter adjustments
As mentioned above, not all projects migrated to the Jira cloud (details see above). However all filters (regardless what projects they refer to) were migrated. This option was chosen to avoid loss of filters due to the migration. As a consequence some filters may be broken or simply obsolete. Check for the following causes:
- Remove any filter which you no longer use or are unrelated to the set of projects which were moved to the cloud.
- Filter ids change during the migration as this is a running number. Therefore any JQL queries which refer to other filters should be changed such that they reference them by filter name.
- e.g. filter = 123456 → filter = "verbose filter name"
- A filter references a project that was not migrated. → Remove such project references. See the above list of migrated projects to see what is available.
- A filter references a custom field with the cf[<field id>] notation. In most cases the field ID will have changed. → Adjust the filter to the new ID
- For details see the JQL custom field documentation
- How to identify the custom ID: Use the second method highlighted by https://confluence.atlassian.com/jirakb/find-my-custom-field-id-number-in-jira-744522503.html
- The filter uses custom JQL extensions which are no longer supported. → Try to find a replacement
Dashboards
- Similar to filters (see previous section), all dashboards were migrated. If the board does not display properly there are generally two reasons:
- The dashboard's gadgets use filters which are broken
- Suggested fix: fix up your filters as described above.
- The dashboard gadget is no longer supported
- Suggested fix: replace it with a similar gadget
- The dashboard's gadgets use filters which are broken
- Remove any dashboards which you no longer use or are unrelated to the set of projects which were moved to the Jira cloud instance.
Agile Scrum/Kanban boards
You can find all migrated boards via https://qt-project.atlassian.net/jira/boards.
- Remove boards which you no longer use or are entirely related to projects which have not been migrated to the Atlassian cloud
- Sanitize boards for general functionality. The most likely reason for errors may be the board filter not being fixed yet (see Filter section above)
General FAQ
Migration limitations
Unfortunately the cloud migration has some limitations. Not all projects (in particular old ones) were migrated to the cloud. Consequently, it is no longer possible to create/maintain issue dependency links between projects on two different Jira servers and manage cross project filters/dashboards/boards. The migration team investigated workarounds but those had severe limitation. Jira admins may revisit further options at a later stage (after the Jira cloud migrations where completed).
Here are some recommendations how to deal with it
- If you have Mother-Child relation on tickets under migrated and non-migrated projects. E.g. an epic under QTPMO (migrated private project), and child User Story or Task under QTBUG (non-migrated public project). You should move the tickets to either the migrated or non-migrated projects before the transition deadline.
- If you have links between tickets under migrated private projects and non-migrated public projects, for example, a bug in QTMCU (migrated to Qt Company Jira cloud) that depends-on a User Story in QTBUG (migrated to OSS Jira). The link will disappear, or you need to move the tickets to another project before the transition deadline.
- Move some of the links into the task description or comment section. There is a link fixing process that can deal with ordinary text links. It fixes text links and distinguishes between migrated and non-migrated projects.
What was/will not be migrated?
The Jira cloud migration process does NOT migrate all data from the server to the cloud. Some data can be migrated via manual steps but others will stay behind. If you are interested in what does and what does not migrate please consult
https://support.atlassian.com/migration/docs/what-gets-migrated-with-the-jira-cloud-migration-assistant/
Notable examples are:
- Kanban board sub-filter
- Links to issues or entities that are not migrated (e.g. QTPM-2345 depends on QTBUG-555 where QTPM and QTBUG reside on different Jira servers/cloud instances)
- For work around see Limitations section above
- Activity streams
- User avatars: users will need to update their avatars after migrating
JQL
Referencing custom fields and their auto-completion in JQL
The usage of custom fields in JQL queries has increased in functionality compared to the Jira server version. A custom field is a field that extends the standard Jira issue fields with our own versions. The official documentation for custom fields can be found under https://support.atlassian.com/jira-software-cloud/docs/jql-fields/#Custom-field.
Using custom fields in a JQL allows multiple ways of referencing them like by name, by Custom field ID or combination of both. This functionality is available to identify any custom field with duplicate names. The best way to use custom field in a JQL is to start typing the name of the field and select the correct one from the auto-suggested values. For example, when you start typing "tag" into the query box, the suggestion starts populating as "Tags[Labels]". Please find below screenshot illustrating the fact:
If there are more custom fields with Tags as a name but different field type (like DropDown or Text) then the user can easily distinguish them and use the correct field.
This has consequences if you rely on auto completion for the field. There are different types of supported functions and operators for different types of custom fields. The auto-suggestions will suggest values according to their supported operator or functions. For example in the above case, it is a custom field of type Labels. The JQL field documentation contains a section of supported & un-supported functions and operators for all types of field. It clearly states that the operator (~) is not supported for labels and hence the suggestions are full values. Therefore simple Jira JQL that ignores specific typing like "Tags = " will not trigger auto-completion. Please check the Labels field documentation for supported and non supported operators for Labels fields.
JQL extensions
Some people use non-standard JQL functions/extensions. Unfortunately such extensions are not seemingly integrated anymore. There is a slightly modified way of setting them up. The Jira cloud instance provides a custom JQL extension via the ScriptRunner Enhanced Search plugin. Please consult the documentation for the plugin in order to adopt its feature set.
FAQ
- Why can I not find my project?
- The migration does not migrate all projects to the cloud. We use this as an opportunity to prune no longer used projects. For the time being the current Jira servers will remain for historical purposes, though all projects will be read-only. If you think a project should be migrated, please contact jira-admin@qt-project.org.
- Why do all issues have the same "updated" date?
- During the migration we needed to make some bulk changes, which unfortunately have changed the "updated" field on all modified issues. That means sorting by this field will be less useful for the time being.
Support
- Please use the extensive Jira documentation if you are looking for specific issues
- When you browse the Jira documentation please ensure that you always pick the cloud version. Looking at the header of a page you should be able to find an indication whether you are looking at a cloud version or the server/data-center version.
- If you cannot find a solution to your issues, please contact
- Email: jira-admin@qt-project.org