Migrate from Orangescrum to Jira

Orangescrum Projects map to Jira Projects with a 1:1 correspondence. Each Project carries name, description, start/end dates, status, and budget fields. We migrate name and description directly; dates migrate as project start and end dates in Jira's project settings. Orangescrum's budget field has no direct Jira equivalent and is preserved as a custom number field budget__c on the Jira project. Project-level status (Active, on Hold, Completed) maps to Jira's project state where supported, or to a custom picklist field project_status__c.

Orangescrum Tasks are the primary work unit and map to Jira Issues. We map task title to Issue summary, description to Issue description (converted to Jira's wiki markup or plain text), priority (Low, Medium, High, Urgent) to Jira Priority, and status (New, In Progress, Completed) to Jira Status. Orangescrum's task type subtypes (if any) map to Jira Issue Type (Task, Story, Bug). Due dates and assignee resolve to Jira Due Date and Assignee fields. Custom field values on Tasks migrate to their mapped Jira custom field equivalents.

Orangescrum Subtasks inherit parent project and task context. We map them as Jira Sub-Task issues linked to their parent Jira Issue via the Parent Link field. Subtask nesting depth is preserved up to two levels. Jira requires Sub-Task issue type to be enabled per project, which we configure during project schema setup.

Orangescrum Sprints (available on Agile-enabled projects only) map to Jira Sprints. Each Sprint carries a start date, end date, goal, and linked tasks. We preserve sprint association by mapping Orangescrum sprint_id to Jira sprint_id via the board-sprint linkage. Orangescrum sprints without a linked Jira board (e.g., if the source project was not Agile-enabled) are migrated as Jira Backlog items ranked by RICE order or by Orangescrum's backlog position index. Sprints with zero tasks are not migrated.

Orangescrum's backlog holds unassigned stories not yet placed in a sprint. We migrate these as Jira Issues in the Backlog with ranking preserved using Jira's Rank field or the backlog order index from Orangescrum. Backlog grouping by Epic or Feature (Orangescrum Premium feature) maps to Jira Epic Link on each issue where the parent Epic exists in the destination.

Orangescrum Epics and Features (Premium and Enterprise tiers) are hierarchical containers above Tasks. We map them to Jira Epic issues with the Epic Name and Epic Status fields populated from Orangescrum's epic name and status. Tasks under an Epic are linked via Jira's Epic Link custom field. If the destination project does not have the Epic issue type enabled, we map Epics to Jira Stories and preserve the hierarchy in a custom field epic_parent__c with an admin-rebuild note.

Orangescrum custom fields (text, number, date, dropdown, checkbox) on tasks and projects require explicit per-field type mapping to Jira custom field types. We create Jira custom fields of the matching type during project schema setup before any issue data is loaded. Orangescrum dropdown options map to Jira custom field options. Multi-select or tag-style custom fields may need to be mapped to Jira Labels or a multi-select custom field depending on the target project configuration. Custom field values do not migrate as code; we document every custom field's source name, type, and destination equivalent in the mapping specification.

Orangescrum Time Logs (hours, date, billing notes, linked to a task and a user) map to Jira Issue Worklog entries. We map hours to Time Spent in Jira format (e.g., 2h 30m), date to Worklog Start Date, and the Orangescrum billing note to a custom Worklog comment field. Jira Worklog requires a matching Jira User for the author; we resolve by email against the Jira User table. If the original Orangescrum time logger has no Jira User, we assign the worklog to the issue's default assignee with a migration flag for admin review.

Orangescrum Bug records are a task subtype with severity (Low, Medium, High, Critical), reproduction steps, and status fields. We map them to Jira Issues with Issue Type = Bug. Orangescrum severity maps to Jira Priority (Low, Medium, High, Highest). The reproduction steps from Orangescrum's bug description migrate to the Jira issue description. Bug status follows the same status-to-Jira-Status mapping as Tasks. If Orangescrum used a separate Bug tracking module, the same mapping applies.

Orangescrum Users (name, email, role, active/inactive) map to Jira Users. We resolve by email match against the Jira destination User table. Any Orangescrum user without a matching Jira account is held in a reconciliation queue for the customer's Jira admin to provision before record import. Inactive Orangescrum users migrate as inactive Jira users so that historical assignment and worklog attribution is preserved. Role mapping (Orangescrum role to Jira project role) is documented during scoping; the customer's admin assigns project roles post-migration.

Orangescrum distinguishes between internal Team Members and external Client contacts. Client records include company name, contact info, and billing details. Jira does not have a native Client object. We map Clients to Jira Project Roles (e.g., Client Viewer) and optionally to Jira user accounts if the client needs access. If the customer uses Jira Service Management, Client contacts may map to Customer records instead. The mapping approach is confirmed during scoping.

Orangescrum Wiki pages contain rich-text content linked to Projects and organized by Categories and Sub-Categories. Jira has no native Wiki; Confluence is a separate product. We migrate Wiki page content as plain-text Issue descriptions on a designated documentation issue (Issue Type = Task, titled with the original page name) or as a text file attachment on the relevant Jira project. Category hierarchy is not preserved natively; we document it in the mapping specification for the customer to rebuild in Confluence if needed. Links between Wiki pages are not preserved as live links.