Migrate from Jira to Microsoft Project

Each Jira Project maps to a single Microsoft Project plan (.mpp file or Project Online Project). Jira project key and name migrate to the Project Plan name field. Jira project description migrates as the Project Summary Task name or a project-level Notes field. We create the plan structure before importing any tasks to ensure the outline hierarchy has a root container. Project Plan 3 and Plan 5 support multiple concurrent plans; Plan 1 is view-only.

Jira Task-type issues map to MS Project Tasks. Jira Summary maps to Task Name; Jira Description maps to Notes (preserving rich text as plain text or HTML-formatted notes depending on destination). Jira Priority ( Highest, High, Medium, Low, Lowest ) maps to a custom Priority flag we add to the plan (Jira's Priority field has no native MS Project equivalent). Start and Finish dates are reconstructed from Jira Due Date plus an estimated duration derived from Jira's original estimate field ( Original Estimate in seconds converted to hours and assigned as Task Duration ).

Jira Story issues map to MS Project Summary Tasks with the Story's estimate stored as a custom field ( Story Points or Estimated Hours ) on the summary row. Stories that are parent to subtasks maintain their summary-rollup relationship by setting Outline Level on the MS Project side. Story labels and fix versions are recorded as custom text fields on the summary task row.

Jira Bug issues map to MS Project Tasks with a custom field IssueType__c set to 'Bug' to preserve the original classification. Bug priority maps to the same custom Priority flag as Tasks. Bug status maps to the nearest MS Project task status (In Progress for In Review, Completed for Done, Not Started for Open or Reopened). Jira bug Fix Version is recorded as a custom field for triage and release-planning purposes.

Jira Subtasks map to MS Project child Tasks at the next Outline Level. The Jira parent Issue must exist as a Task or Summary Task in MS Project before the Subtask is created to satisfy the outline hierarchy. Subtask Status, Priority, and Assignee migrate directly. Subtask Jira key is preserved in a custom field jira_key__c so cross-references can be maintained post-migration. MS Project supports unlimited outline levels, which accommodates typical Jira epic > story > task > subtask hierarchies.

Jira link types Blocks and Blocked By map to MS Project Finish-to-Start (FS) dependencies. The predecessor task is the Jira issue with the 'blocks' link; the successor task is the issue being blocked. Jira link type Relates To does not map to an MS Project dependency and is recorded as a custom text field ( Related_Jira_Issues__c ) for reference. Circular dependency detection is run post-mapping; any cycles are flagged for manual resolution before import.

Jira's unlimited custom field types (Date Picker, Multi-User Picker, Cascading Select, URL, Labels) are the most significant data-loss risk in this migration. MS Project supports only text-based custom fields. We identify every custom field in the source, classify its Jira type, and apply one of three strategies: (1) for text and URL fields, direct 1:1 migration; (2) for date fields, convert to MS Project Finish or Start date if not already mapped, or to a custom text date field; (3) for multi-select, user picker, and cascading select, flatten to a semicolon-delimited text string. Structured dropdown behavior, filtering, and cross-issue reporting on these fields are lost and documented as a manual-rebuild item in the handoff report.

Jira issue Comments are appended to the corresponding MS Project Task's Notes field in reverse-chronological order, prefixed with the comment author's name and timestamp. Jira supports unlimited comments per issue; MS Project Task Notes field has a practical limit of approximately 32 KB of text per task, so tasks with unusually large comment threads are flagged and the oldest comments are truncated to fit. We preserve as much comment history as the Notes field allows and flag the remainder for manual retrieval from the Jira export.

Jira issue attachments are not stored inside the MS Project plan file. We extract attachments to a local or SharePoint directory, generate a file path reference, and append the list of attachment names and URLs to the Task Notes field. For MS Project Online destinations connected to SharePoint, we create a document library mapping so attachments can be accessed directly from Teams or SharePoint. Jira's attachment size limits are checked against SharePoint upload limits (250 MB per file in most tenants); files exceeding this are flagged individually.

Jira Versions (releases and milestones) are converted to MS Project Milestone Tasks within each project plan. Version name becomes the Milestone Task Name; the scheduled release date becomes the Milestone date. Released and archived status from Jira is stored as a custom field on the milestone row. Issues linked to a Version are linked to the corresponding Milestone task via a predecessor dependency or a custom text field ( Jira_FixVersion__c ).

Jira Components (optional groupings with a default Assignee and Component Lead) are converted to a custom text field Component__c on each affected task. If the destination MS Project plan is connected to Project Online and SharePoint, components map to a SharePoint list or Microsoft 365 Group for team-based assignment. Component Lead does not have a direct MS Project equivalent and is noted as a role-based permission requiring manual assignment in the destination.

Jira Labels migrate to a custom text field Labels__c on each task, with multiple labels stored as a comma-separated string. MS Project does not support multi-select or tag-style fields natively, so exact Jira label filtering behavior is lost. Labels are preserved for informational purposes and to support manual categorization in the destination. Label casing is preserved exactly as stored in Jira.