# User Problem

## User

* Project managers


## Problem

* Project managers need a simple way to migrate basic Jira project data into a new OpenProject instance without manually recreating structures or copy-pasting issue content.


## Pain

* Current workarounds:

* Use incomplete third-party tools to migrate from Jira DC to OpenProject, e.g. Excel sheets.

* Migrate manually

* This is painful because:

* It is time-consuming and error-prone

* Third-party tools can become outdated quite soon

* Users cannot easily recover mistakes


# Begin of the insertion**Solution**End of the insertion Begin of the deletion Business CaseEnd of the deletion

Begin of the deletion ## Solution

End of the deletion The Begin of the insertionbasicEnd of the insertion Jira Begin of the insertionimport wizardEnd of the insertion Begin of the deletion Migration Tool V1End of the deletion provides a minimal, reliable way to migrate essential Jira project data into an OpenProject instance. Begin of the insertionWe focus on user-generated content first. In subsequent releases, when OpenProject's capabilities are extended to cover more Jira functionality, we will also extend the capabilities of this importer. For example, OpenProject first needs to support semantic work package identifiers (like ABC-123) before the Jira issue keys can be imported: ##71626.End of the insertion Begin of the deletion
V1 supports:End of the deletion

Begin of the insertion## **Import workflows**

This EPIC focuses on getting a solid foundation for importing large amounts of data from Jira to OpenProject. It will also allow typical import workflows where only a selection of projects get imported at a time. This will allow migrating people one team after the other. When a project gets imported, then typically it first needs to be reviewed. And only if the import gets approved then all migrated users get access to the project. In contrast, if the reviewer does not agree with the result, then the import can be fully undone, all created objects will be removed again as if the import had not happened.

## **Robustness**

The importer needs to be robust. Network, hardware and software can fail. The basic Jira import already will follow a design where failed imports can be safely removed or restarted.

## Scope

End of the insertion * Connecting to a Jira instance via a configured host and credentials

* Fetching the list of available Jira projects

* Letting the user select projects for import

* Fetching and caching the following data:

* Project

* Name

* Description

* Identifier

* Issue

* Subject

* Description Begin of the insertion

* Attachments

* Comments

* History of changesEnd of the insertion

* Issue Status

* Issue Type

* Issue Priority Begin of the insertion

* Users and Groups via APIEnd of the insertion

* \[Optional\] validation that target configuration is sufficient

* Auto-creation of missing OpenProject-side objects

* Status

* Project memberships

* Performing the creation of Projects, Work Packages, Statuses, Types from cached data and storing references to all created objects

* These references allow a one-click “Revert import” action

* "Revert import" action


## Out of Scope Begin of the insertionof this EPICEnd of the insertion Begin of the deletion for the MVCEnd of the deletion

* Migration of

* Custom Fields

* Permissions

* Issue relations

* Project level permissions migration Begin of the deletion


## Differentiation

* "Undo import" provides a way for users to test how migration works.End of the deletion