{noprint}{float:right|width=300px|background=lightgrey|border=solid blue 2px|margin=10px|padding=8px}
*Contents*
{toc:all=true|depth=4|excerpt=true|indent=14px}
{float}{noprint}{table-plus:enableSorting=false|width=665}
h2. Consequences of Migrating to New JIRA Flow

For each issue type the JIRA process is controlled by a set of flows, i.e 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 status must also be migrated to their counterpart in the JIRA flow.
\\
It is important to state 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.

h2. 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.

h3. 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 | Ready for release | Resolved is no longer the final state of the workflow and can now be mapped to this new state. |
| Delivered | Resolved | When an issue is delivered to the customer, it is considered resolved. The customer has the possibility to accept or decline the delivered solution. |
| 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 |

h3. 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. |

h3. 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. |

h3. 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. |
\\

h2. Migration of Issue Types


h3. Change Requests

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

h3. 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_.

h3. 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.
{table-plus}