Migrating to New JIRA Workflow

Consequences of Migrating to New JIRA Flow

Each issue type in the JIRA process is controlled by a set of workflows. In order to migrate to the new JIRA flow, all current issues must be migrated to the new versions of these workflows.

All issue statuses must also be migrated to their counterpart in the JIRA flow.

It is important to mention that not all issue types and all kinds of JIRA workflows have been utilized by all customers, so some issues types or workflows may not have been available to you.

Workflow Migration

Currently all main tasks – change requests, bugs and bugs (non-production) – utilize the CDRator Main task workflow. This workflow will be substituted by the new main flow; the CDRator Workflow Main-Task 4.1 workflow.

The sub task flow, CDRator Development Workflow, will be substituted by the CDRator Workflow Sub-Task 4.1 workflow.
The QA flow, CDRator QA Workflow, will be substituted by the CDRator Workflow Sub-Task 4.1 workflow.
The Questions flow, CDRator Jira 2.0, will be substituted by the CDRator Open/Closed 1.0 workflow.

Migration of Main Workflow

The following table gives an overview of which workflow states map to each other in the new and old workflow.

Current state	New state	Migration comment
Open	Open	-
Analyzing	Analyzing	-
Ready for processing	Ready for processing	-
In progress	In progress	-
In QA	In QA	-
In review	In progress	This in review state has been removed and issues in review will be converted to be in progress with the review flag not set
Resolved	Resolved	-
Delivered	Closed	When an issue is delivered to the customer, it is considered closed.
Closed	Closed	When a resolved issue is accepted or rejected the state will be set to closed. Migrated issues will be closed as accepted.
Reopened	Open	Instead of reopening a task, a clone must be created.
On hold	On hold	-
Waiting	On hold	As that Waiting state has been substituted by On hold this state be migrated to that state

Migration of Sub-Task Workflow

The following table gives an overview of which workflow states map to each other in the new and old workflow.

Current state	New state	Migration comment
Analyzing	Open	As the analysis is handled as part of the main task, this state is migrated to open.
Ready for processing	Ready for processing	-
In progress	In progress	-
In review	In progress	This in review state has been removed and issues in review will be converted to be in progress with the review flag not set
Closed	Closed	When a resolved issue is accepted or rejected the state will be set to closed. Migrated issues will be closed as accepted.

Migration of CDRator QA Workflow

The following table gives an overview of which workflow states map to each other in the new and old workflow.

Current state	New state	Migration comment
Analyzing	Open	As the analysis is handled as part of the main task, this state is migrated to open.
Ready for processing	Ready for processing	-
In progress	In progress	-
In review	Ready for QA	When the task have been handled by product, it is up to QA to verify that the issue have been addressed, so it will go back to QA using the Ready for QA status.
Closed	Closed	When a resolved issue is accepted or rejected the state will be set to closed. Migrated issues will be closed as accepted.

Migration of CDRator JIRA 2.0 Workflow

The following table gives an overview of which workflow states map to each other in the new and old workflow.
This new flow, the CDRator Open/Closed 1.0 workflow, is a simple workflow, as the issue type using it does not require the same states as the main tasks.

Current state	New state	Migration comment
Open	Open	-
Analyzing	Open	Considered open.
Ready for Processing	Open	Considered open.
In Progress	Open	Considered open.
In review	Open	Considered open.
Resolved	Open	Considered open.
In QA	Open	Considered open.
On Hold	Open	Considered open.
Delivered	Closed	This state is obsolete, as tasks using this workflow do not follow the normal deployment procedure.
Closed	Closed	-
Waiting	Open	Considered open.
Reopened	Open	Considered open.

Migration of Issue Types

Change Requests

Change requests will still be change request and subtasks will remain subtasks. Only their respective JIRA workflows will change.

Bugs

Currently there are two kinds of bugs: production bugs and non-production bugs.
The non-production bugs will be omitted and instead the environment flag has been made mandatory.
All Bugs (non-production) issue types will be migrated to Bugs with their environment set to Test.

Other Issue Types

The issue type Question will be substituted by a new issue type: Customer request.
The issue type QA will be substituted by a new issues type: Bug subtask.