Content
Updated by Parimal Satyal 11 months ago
**As a** project team currently using Jira and interested in switching to OpenProjet
**I want to** be able to start migrating my data form Jira to OpenProject
**so that** I can validate the decision to switch projects to OpenProject
#### **Context**
Currently, OpenProject does not offer As a native migration tool specifically for transferring data from Jira to OpenProject. We are receiving more and more requests to be able to migrate from Jira to OpenProject, even if most of them are happy to first conduct a smaller-scale test of some sort. We do offer an [Excel synchronisation tool that some have used successfully to sync data](https://www.openproject.org/blog/healthcare-testimonial-migration-jira/) across the two platforms, but the tool is rather limited.
This feature describes a possible three-step approach to how we can model a successful migration.
#### Migration model
To have a broader scope that also allows keeping the history, a custom migration tool will need to be be developed to facilitate the transition of data between the two platforms. This tool will have the capability to connect to the Jira API and enable administrators to create a mapping of Jira objects to corresponding OpenProject objects. The mapping process will involve aligning various elements Ticket types, custom fields and project roles (see the table below for more details).
<img class="image_resized op-uc-image op-uc-image_inline" style="width:566px;" src="/api/v3/attachments/199249/content">
The migration process will be structured into three key steps:
1. **Manual Configuration**: In this initial step, an administrator will manually configure OpenProject by setting up the necessary configuration settings like hostname, access control and calendar preferences. It also includes setting up basic structures like work package types, statuses, roles and work flows.
2. **Mapping**: All data is fetched from the Jira source system and the mapping tool will be utilised to establish the associations between Jira objects and corresponding OpenProject objects, creating a detailed configuration file that guides the migration process.
3. **Data Import**: Subsequently, Jira data will be imported into OpenProject using the previously-defined configuration, aiming for a transition of user-generated project data from one platform to another.
The configuration and basic data created in the first step is created manually for two reasons:
1. the configuration fetched from Jira will to a large extent likely not be mappable to OpenProject configuration and
2. it allows updating and consolidating the configuration. For example, over the course of a project management tool's lifetime, types and statuses tend to increase and the migration now provides an occasion for cleaning up.
OpenProject has successfully migrated customer data into OpenProject instances:
* combining multiple OpenProject instance's data into a single one;
* from a non OpenProject solution;
These experiences indicate that it is important to anticipate potential performance challenges during the migration, with the possibility of migrations taking a significant amount of time. Both the performance and rate limits of the source system (Jira) from which data is fetched, as well as the performance of the sink system (OpenProject) will determine the overall time taken. One large factor will also be the size of the attachments. It is crucial to collaborate closely to define the scope of the migration, with a primary focus on transferring essential ticket data such as title, status, description, assignee and relations).
Another challenge learned from past experiences is data consistency. In systems that have existed for some time, data tends to become invalid when applying today's configuration. This oftentimes happens when data that was valid once and is then not touched any more when configuration changes. Another scenario would be when a new version of the software changes constraints which are not applied to already existing data. We would like to also specify that objects that may exist in the Jira instances that are _not_ supported by OpenProject will not be included in the migration. This approach aims to prioritise the accurate transfer of essential project information while addressing any limitations or discrepancies between the two platforms.
#### Mapping table
The following is a non-exhaustive list of data types in Jira and how they will be mapped to data types in OpenProject:
<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell" style="background-color:hsl(0, 0%, 90%);"><p class="op-uc-p">Jira</p></td><td class="op-uc-table--cell" style="background-color:hsl(0, 0%, 90%);"><p class="op-uc-p">OpenProject</p></td><td class="op-uc-table--cell" style="background-color:hsl(0, 0%, 90%);"><p class="op-uc-p">Jira API</p></td><td class="op-uc-table--cell" style="background-color:hsl(0, 0%, 90%);"><p class="op-uc-p">Comment</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Custom field & Custom field option</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Custom field & custom option</p></td><td class="op-uc-table--cell"><p class="op-uc-p"><a class="op-uc-link" href="https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-fields/#api-group-issue-fields">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-fields/#api-group-issue-fields</a><br><br>https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-custom-field-options/#api-group-issue-custom-field-options</p></td><td class="op-uc-table--cell"><p class="op-uc-p"></p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Filter</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Query</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-filters/#api-rest-api-3-filter-post</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Summarise dashboards" (understood to be filters) as requested in #54096.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue</p></td><td class="op-uc-table--cell"><p class="op-uc-p">WorkPackage</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-group-issues</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all ticket information" as requested by #54099.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue attachments</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Attachment</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-attachments/#api-group-issue-attachments</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all ticket information" as requested by #54099.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue comment</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Comment in journal</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/#api-rest-api-3-comment-list-post</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all ticket information" as requested by #54099.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue field configuration & issue custom field context</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Work package form configuration & project configuration</p></td><td class="op-uc-table--cell"><p class="op-uc-p"><a class="op-uc-link" href="https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-field-configurations/#api-group-issue-field-configurations">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-field-configurations/#api-group-issue-field-configurations</a><br>https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-custom-field-contexts/#api-group-issue-custom-field-contexts</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Keep all the configuration of ticket CRUD screens" as requested in #54094</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue history</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Journal</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-changelog-get</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all the ticket types used in the projects" as requested by #54099.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue link</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Relation</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-link-types/#api-group-issue-link-types</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Dynamically created link types will have to be matched to the fixed set in OP</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue types</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Type</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-types/#api-rest-api-3-issuetype-get</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all the ticket types used in the projects" as requested by #54099.</p><p class="op-uc-p">Best done manually</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Project role</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Project role</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-project-roles/#api-group-project-roles</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Best done manually as permissions are not provided by the API and would have to be remapped because of the different systems anyway.<br>The association between role and user is done via the concept of an actor. Fetching that information enables fulfilling requirement "Keep all user configuration (groups and assignment to projects)" as requested in #54096.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Project version & Sprint</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Version</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-project-versions/#api-rest-api-3-project-projectidorkey-version-get</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all sprints and their content" as requested by #54099.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">User & Groups</p></td><td class="op-uc-table--cell"><p class="op-uc-p">User</p></td><td class="op-uc-table--cell"><p class="op-uc-p"><a class="op-uc-link" href="https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-users/#api-group-users">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-users/#api-group-users</a><br>https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-groups/#api-group-groups</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Keep all user configuration (groups and assignment to projects)" as requested in #54096.</p></td></tr></tbody></table></figure>
The text in the topics and problem descriptions, and also in the comments in Jira, uses a variant of the Textile format, whereas OpenProject stores its text data internally in the Markdown format. As the text was previously stored in Textile in OpenProject, there is already code in place for this part of the migration.
> ### Archived original feature
>
> As a Jira user
>
> I want to receive support in the form of documentation, easy migration and so on
>
>
to change to OpenProject smoothly and efficiently.
>
>
**Further specification based on support ticket 12338**
>
> Our requirements for a migration are fairly straightforward:
> We want to be able to migrate all the data and metadata, but not the
> detailed Jira configurations. In our opinion, manual adjustments are
> are unavoidable, as Jira and OpenProject differ significantly.
>
> However, the migration should be so comprehensive that subsequent
> adjustments are only necessary at project level/configuration level and not on individual issues/tickets. In our case, the latter would be
> would not be feasible due to the large number of tickets.
>
> We would therefore like the following data migration from Jira to
> OpenProject:
>
> _Migration of all Jira Projects, including:_
> \- Project details (name, key, URL, project type, project category, Project avatar)
> \- Ticket data (description, comments -> including author and date/time)
> \- Issue Types (Task, Sub-Task, Bug, Epic, Story, etc.)
> \- Default Fields (Type, Priority, Components, Label, Status, Resolution,
> Assignee, Reporter, Watchers, Created Date, Updated Date, Issue Links, Epic)
> \- Custom Fields
> \- Workflows
> \- Components
> \- Priorities
> \- Versions
> \- Labels (are global in Jira, not project-related)
> \- Assignment of ticket users (creator, assignee) based on username
> \- Specification of a fallback user for migration if Jira
> ticket user is not found in OpenProject
>
> What we explicitly do NOT see as part of this migration:
>
> \- User and roles, Permissions, Issue Security
> \- Notifications
> \- E-Mail interfaces (inbound/outbound)
> \- individual user settings, Dashboards and saved views
> \- Kanban Boards (nice to have though)
**I want to** be able to start migrating my data form Jira to OpenProject
**so that** I can validate the decision to switch projects to OpenProject
#### **Context**
Currently, OpenProject does not offer
This feature describes a possible three-step approach to how we can model a successful migration.
#### Migration model
To have a broader scope that also allows keeping the history, a custom migration tool will need to be be developed to facilitate the transition of data between the two platforms. This tool will have the capability to connect to the Jira API and enable administrators to create a mapping of Jira objects to corresponding OpenProject objects. The mapping process will involve aligning various elements Ticket types, custom fields and project roles (see the table below for more details).
<img class="image_resized op-uc-image op-uc-image_inline" style="width:566px;" src="/api/v3/attachments/199249/content">
The migration process will be structured into three key steps:
1. **Manual Configuration**: In this initial step, an administrator will manually configure OpenProject by setting up the necessary configuration settings like hostname, access control and calendar preferences. It also includes setting up basic structures like work package types, statuses, roles and work flows.
2. **Mapping**: All data is fetched from the Jira source system and the mapping tool will be utilised to establish the associations between Jira objects and corresponding OpenProject objects, creating a detailed configuration file that guides the migration process.
3. **Data Import**: Subsequently, Jira data will be imported into OpenProject using the previously-defined configuration, aiming for a transition of user-generated project data from one platform to another.
The configuration and basic data created in the first step is created manually for two reasons:
1. the configuration fetched from Jira will to a large extent likely not be mappable to OpenProject configuration and
2. it allows updating and consolidating the configuration. For example, over the course of a project management tool's lifetime, types and statuses tend to increase and the migration now provides an occasion for cleaning up.
OpenProject has successfully migrated customer data into OpenProject instances:
* combining multiple OpenProject instance's data into a single one;
* from a non OpenProject solution;
These experiences indicate that it is important to anticipate potential performance challenges during the migration, with the possibility of migrations taking a significant amount of time. Both the performance and rate limits of the source system (Jira) from which data is fetched, as well as the performance of the sink system (OpenProject) will determine the overall time taken. One large factor will also be the size of the attachments. It is crucial to collaborate closely to define the scope of the migration, with a primary focus on transferring essential ticket data such as title, status, description, assignee and relations).
Another challenge learned from past experiences is data consistency. In systems that have existed for some time, data tends to become invalid when applying today's configuration. This oftentimes happens when data that was valid once and is then not touched any more when configuration changes. Another scenario would be when a new version of the software changes constraints which are not applied to already existing data. We would like to also specify that objects that may exist in the Jira instances that are _not_ supported by OpenProject will not be included in the migration. This approach aims to prioritise the accurate transfer of essential project information while addressing any limitations or discrepancies between the two platforms.
#### Mapping table
The following is a non-exhaustive list of data types in Jira and how they will be mapped to data types in OpenProject:
<figure class="table op-uc-figure_align-center op-uc-figure"><table class="op-uc-table"><tbody><tr class="op-uc-table--row"><td class="op-uc-table--cell" style="background-color:hsl(0, 0%, 90%);"><p class="op-uc-p">Jira</p></td><td class="op-uc-table--cell" style="background-color:hsl(0, 0%, 90%);"><p class="op-uc-p">OpenProject</p></td><td class="op-uc-table--cell" style="background-color:hsl(0, 0%, 90%);"><p class="op-uc-p">Jira API</p></td><td class="op-uc-table--cell" style="background-color:hsl(0, 0%, 90%);"><p class="op-uc-p">Comment</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Custom field & Custom field option</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Custom field & custom option</p></td><td class="op-uc-table--cell"><p class="op-uc-p"><a class="op-uc-link" href="https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-fields/#api-group-issue-fields">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-fields/#api-group-issue-fields</a><br><br>https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-custom-field-options/#api-group-issue-custom-field-options</p></td><td class="op-uc-table--cell"><p class="op-uc-p"></p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Filter</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Query</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-filters/#api-rest-api-3-filter-post</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Summarise dashboards" (understood to be filters) as requested in #54096.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue</p></td><td class="op-uc-table--cell"><p class="op-uc-p">WorkPackage</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-group-issues</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all ticket information" as requested by #54099.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue attachments</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Attachment</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-attachments/#api-group-issue-attachments</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all ticket information" as requested by #54099.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue comment</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Comment in journal</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-comments/#api-rest-api-3-comment-list-post</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all ticket information" as requested by #54099.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue field configuration & issue custom field context</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Work package form configuration & project configuration</p></td><td class="op-uc-table--cell"><p class="op-uc-p"><a class="op-uc-link" href="https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-field-configurations/#api-group-issue-field-configurations">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-field-configurations/#api-group-issue-field-configurations</a><br>https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-custom-field-contexts/#api-group-issue-custom-field-contexts</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Keep all the configuration of ticket CRUD screens" as requested in #54094</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue history</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Journal</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issues/#api-rest-api-3-issue-issueidorkey-changelog-get</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all the ticket types used in the projects" as requested by #54099.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue link</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Relation</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-link-types/#api-group-issue-link-types</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Dynamically created link types will have to be matched to the fixed set in OP</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Issue types</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Type</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-issue-types/#api-rest-api-3-issuetype-get</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all the ticket types used in the projects" as requested by #54099.</p><p class="op-uc-p">Best done manually</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Project role</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Project role</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-project-roles/#api-group-project-roles</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Best done manually as permissions are not provided by the API and would have to be remapped because of the different systems anyway.<br>The association between role and user is done via the concept of an actor. Fetching that information enables fulfilling requirement "Keep all user configuration (groups and assignment to projects)" as requested in #54096.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">Project version & Sprint</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Version</p></td><td class="op-uc-table--cell"><p class="op-uc-p">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-project-versions/#api-rest-api-3-project-projectidorkey-version-get</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Include all sprints and their content" as requested by #54099.</p></td></tr><tr class="op-uc-table--row"><td class="op-uc-table--cell"><p class="op-uc-p">User & Groups</p></td><td class="op-uc-table--cell"><p class="op-uc-p">User</p></td><td class="op-uc-table--cell"><p class="op-uc-p"><a class="op-uc-link" href="https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-users/#api-group-users">https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-users/#api-group-users</a><br>https://developer.atlassian.com/cloud/jira/platform/rest/v3/api-group-groups/#api-group-groups</p></td><td class="op-uc-table--cell"><p class="op-uc-p">Enables fulfilling requirement "Keep all user configuration (groups and assignment to projects)" as requested in #54096.</p></td></tr></tbody></table></figure>
The text in the topics and problem descriptions, and also in the comments in Jira, uses a variant of the Textile format, whereas OpenProject stores its text data internally in the Markdown format. As the text was previously stored in Textile in OpenProject, there is already code in place for this part of the migration.
> ### Archived original feature
>
> As a Jira user
>
> I want to receive support in the form of documentation, easy migration and so on
>
>
>
>
>
> We want to be able to migrate all the data and metadata, but not the
> detailed Jira configurations. In our opinion, manual adjustments are
> are unavoidable, as Jira and OpenProject differ significantly.
>
> However, the migration should be so comprehensive that subsequent
> adjustments are only necessary at project level/configuration level and not on individual issues/tickets. In our case, the latter would be
> would not be feasible due to the large number of tickets.
>
> We would therefore like the following data migration from Jira to
> OpenProject:
>
> _Migration of all Jira Projects, including:_
> \- Project details (name, key, URL, project type, project category, Project avatar)
> \- Ticket data (description, comments -> including author and date/time)
> \- Issue Types (Task, Sub-Task, Bug, Epic, Story, etc.)
> \- Default Fields (Type, Priority, Components, Label, Status, Resolution,
> Assignee, Reporter, Watchers, Created Date, Updated Date, Issue Links, Epic)
> \- Custom Fields
> \- Workflows
> \- Components
> \- Priorities
> \- Versions
> \- Labels (are global in Jira, not project-related)
> \- Assignment of ticket users (creator, assignee) based on username
> \- Specification of a fallback user for migration if Jira
> ticket user is not found in OpenProject
>
> What we explicitly do NOT see as part of this migration:
>
> \- User and roles, Permissions, Issue Security
> \- Notifications
> \- E-Mail interfaces (inbound/outbound)
> \- individual user settings, Dashboards and saved views
> \- Kanban Boards (nice to have though)