Migrate from Project KickStart to Jira

Project KickStart Projects map directly to Jira Projects, preserving project name, description, planned start and end dates, and cost as custom fields on the Jira project record. The source Project ID is preserved as a custom reference field for audit traceability. We create the Jira project using the customer's chosen project template (Scrum Software Development, Kanban Software Development, or Business Project Management) before importing any issues into it.

Project KickStart Phases are the second level of the outline hierarchy and have no single native Jira equivalent. During scoping, we present two options: Jira Epics (for teams that want hierarchical Agile breakdown and swimlane organization on Scrum boards) or Jira Components (for teams that want flat organization and labeling). The choice depends on whether the customer's Jira plan enables Epic scoping on sprints. Phase dates, cost, and complete rate migrate as Epic or Component custom fields. We document the chosen strategy in the scoping output and apply it consistently across all Phases in the export.

Project KickStart Tasks map to Jira Issues (Story or Task issue type). Task name becomes Jira Summary. Planned dates map to Jira Start Date and Due Date on the Fields tab. Task cost and complete rate migrate as custom fields. Assignee resolves to Jira User by email or display name lookup. Task Description migrates as Jira Description (stored as Jira Document Format, ADF). The issue type default is Story for deliverables and Task for non-deliverable work items; we allow the customer to set this preference at scoping.

Project KickStart SubTasks nest under Tasks and map to Jira Subtask issues when Jira's Subtask setting is enabled on the target project. We resolve the parent Task's Jira Issue ID and set it as the parent of the Subtask. Where Jira's hierarchy does not support more than one level of nesting below Subtask, we flatten deeper SubTask chains by prefixing the name with the parent's full path for disambiguation. Jira enables Subtasks at the project configuration level; we configure this before migration begins.

Goals are a Project KickStart planning concept for defining project-level objectives. Jira has no native Goals object. We preserve Goals as a custom multi-line text field on the Jira Project record (for project-level goals) or on the Epic (for milestone-level goals). Customers should verify that their Jira plan allows project-level custom fields. We flag the mapping at scoping and let the customer's admin confirm the field placement before migration.

Obstacle and Risk entries are Project KickStart concepts for project-level risk tracking with title, description, and linked tasks. Jira has no native risk object, but Jira Issues with a Risk label or a custom Risk Status picklist serve as the equivalent. We map Obstacle title and description to a Jira Issue with the label risk_item, link it to the related Tasks via Jira issue links (blocks or relates to), and set the Jira Issue Type to Task. We flag this mapping during scoping and verify that the Jira plan supports sufficient custom fields.

Project KickStart Task assignees are named team members that we resolve to Jira User records by email address (primary key) or display name as a fallback. Any assignee that does not have a matching Jira User is flagged for the customer's Jira admin to provision before the relevant records are imported. Owner records on Project KickStart Projects also resolve to Jira Project leads via the same lookup mechanism. We do not create Jira users programmatically; all user provisioning is handled by the customer's admin.

Project KickStart generates explicit finish-to-start and start-to-start dependency links between Tasks. We reconstruct these as Jira Issue Links (blocks, is blocked by, relates to) using the Jira issue key generated during import. We capture the dependency type from the source export (Finish-to-Start maps to blocks; Start-to-Start maps to relates to with a note). Issue links require both issues to exist in Jira before the link can be created, so we create dependencies in a second pass after all issues are imported. The customer's Jira plan must enable the Issue Links feature, which is available on all Jira plans.

Project KickStart Notes are free-text entries at various hierarchy levels. We map them to Jira Comments on the corresponding issue (for task-level notes) or to the Description field (for project-level notes that are not comments). Note author and timestamp are preserved in the Jira Comment metadata. Where a Note references an attachment or another Note, we flag the cross-reference for manual verification.

Project KickStart attachments linked to Tasks and Projects migrate as Jira file attachments on the corresponding Jira Issue. File path references from the source export are replaced with the Jira attachment URL pattern. Jira's CSV importer does not handle binary file attachments directly; we migrate them via the Jira REST API as a parallel step to the CSV import. Jira's default attachment limit is 256 MB per file; we flag any files exceeding this limit during the pre-migration audit.

Project KickStart templates contain the outline structure, Phase placeholders, and default task libraries. Jira has a Project Template feature (based on the project template chosen at creation). We export the template as a Project from Project KickStart and re-create the structure in Jira by importing the template as a project using the customer's chosen Jira template, then map the Phase placeholders to the corresponding Epic or Component names. Gantt-specific formatting and wizard metadata do not carry over as they have no Jira equivalent.