Migrating from Jira: Import custom fields into OpenProject 17.4
Many teams are currently looking for alternatives to Jira. Often under time pressure to find a solution that fits their needs. Migrating, however, requires more than just moving data from one tool to another. It means understanding how your existing setup translates to a new system, as well as being open to workarounds, compromises, and potential improvements.
With the OpenProject Jira Migrator, we support this process step by step. On May 13, it will be available without a feature flag as part of OpenProject 17.4. In addition to the basic functionality already available, it will support the import of basic custom fields — an essential part of task and project management.
In this article, we explain what this means for your Jira exit.
Migrating from Jira is not a one-to-one process
While many core concepts such as work packages, workflows, or custom fields exist in both systems, they are often named, structured, and handled differently.
In Jira, configurations are frequently tailored to individual projects and extended with plugins. Some plugin-based configurations in Jira do not have a direct equivalent in OpenProject and may require alternative approaches. In OpenProject, similar use cases can often be achieved, but sometimes require a different setup or approach. This means that migrating your data is not only about transferring information, but also about adapting it to a new system.
As a result, workarounds and adjustments are often part of the process. Being open to these changes is key to a successful migration, and can also be an opportunity to simplify and improve existing structures.
Preview of OpenProject 17.4: Jira Migrator available without a feature flag
With OpenProject 17.4 (scheduled for May 13), the Jira Migrator will be available and can be used directly. While it is already functional, it is not yet feature complete and is therefore released as a Beta version.
Image: OpenProject Jira Migrator version 17.4, to be released on May 13, 2026.
This approach is part of how we develop OpenProject. With monthly releases, we continuously deliver improvements and make features available once they provide real value, even if they are not yet fully finished. This allows teams to start working with new functionality earlier, test it in real scenarios, and provide feedback that directly influences further development.
At the same time, it also means that some limitations still exist and that certain workflows may require adjustments. We believe that this transparent and iterative approach helps us improve the Jira Migrator together with our Community. See our roadmap to learn how OpenProject plans to further support Jira migration and Jira fundamentals.
Image: The OpenProject Jira Migrator after a successful import.
Good to know: The Jira Migrator itself is designed as a guided wizard, making the migration process accessible and easy to follow, even for users without deep technical knowledge. See the Jira migration documentation for a step-by-step guide.
Import custom fields from Jira to OpenProject
With OpenProject 17.4, the Jira Migrator will support the import of basic custom fields, an essential part of task and project management. Learn more about custom fields in OpenProject.
Some field types may appear differently in OpenProject compared to Jira. For example, checkboxes in Jira are represented as lists, but offer similar functionality in OpenProject. While the underlying functionality is often comparable, the way these fields are configured and used can differ between Jira and OpenProject.
To help you understand better, here is an example of a work package that was imported from Jira to OpenProject with various basic custom fields:
*Preview image of OpenProject 17.4 coming Mai 13, 2026: Comparison between Jira (right) and OpenProject (left), with highlight on imported custom fields of different types.
As we develop in the open, you can follow the specifications for “Jira Migrator imports custom fields” in this work package.
How custom fields are handled during migration
One key difference between Jira and OpenProject is how custom fields are managed: In Jira, custom fields can be configured differently for each project. In OpenProject, custom fields are defined system-wide and then activated for specific projects.
During migration, the Jira Migrator adapts to this difference. If a custom field is used consistently across projects, it will be created as a single custom field in OpenProject. If the same field is configured differently via “Field context” in multiple Jira projects, it will be split into separate custom fields.
To make this transparent, the Migrator adds a suffix with the project identifier to each split field. This allows you to clearly see which field belongs to which project.
Placement of imported custom fields
When custom fields are imported, they need to be placed within the work package layout. To ensure that all imported fields are visible, the Jira Migrator adds them to a dedicated group section called Jira import. From there, administrators can review and adjust the placement of these fields as needed.
What to expect when working with imported data
As with any migration, some adjustments may be required after the import. For example, custom fields may need to be activated for specific projects or reorganized within the work package layout. In addition, users are imported in an inactive state to allow a smooth import process, especially for larger datasets and licensing constraints.
While these steps require some manual review, they ensure that your data is transferred in a consistent and manageable way.
Frequently asked questions (FAQ) about Jira migration
A quick overview of common questions about migrating from Jira and working with the Jira Migrator.
Should I already use the Jira Migrator in its current state?
The Jira Migrator is functional and can already be used, but it is still under active development. It is best suited for testing, evaluation, and early migration scenarios where you are open to adjustments. See our blog article on the Jira Migrator for an overview.
What are the current limitations of the Jira Migrator?
Some features, such as advanced custom fields, or plugin-based configurations, are not yet fully supported. Depending on your Jira setup, certain elements may require manual adjustments or alternative configurations. The following features are coming soon: project & issues identifiers, relations between issues and sprint assignments. Project-level workflows, permissions and schemas coming later. Please have a look at our full development roadmap for a up-to-date list.
How much manual work should I expect after migration?
Migration is not a fully automated process. While core data can be transferred, reviewing custom fields, adjusting configurations, and validating your setup are important steps after the import.
Why does OpenProject release the Jira Migrator before it is fully complete?
OpenProject follows an iterative development approach with monthly releases. By making features available early, users can test them in real scenarios and provide feedback that directly shapes further development.
We ask for our users’ understanding that early availability also means that not everything may work perfectly yet. Feedback from the Community — for example through bug reports — helps us identify issues quickly and address them in upcoming releases.
Help us improve the Jira Migrator
We invite you to try the Jira Migrator with OpenProject 17.4 and explore how it works with your own data. Your feedback is an important part of further development. If you encounter issues or have suggestions, we encourage you to share them with us. This helps us improve the Jira Migrator and better support real-world migration scenarios. Learn how to contribute and share feedback in our Community, for example by reporting bugs.
If you would like to share anonymized data from your migration to support our development team, please reach out to us. We are happy to sign an NDA to ensure confidentiality. We look forward to your feedback and to continuing to improve the Jira Migrator together with our Community.
