Migrate your Jira data

Projects are the top-level container for all Jira work. They carry a project key (e.g., ENG, MKT), a type (business or software), and a default scheme for permissions and notifications. We migrate projects as-is and map the project key in the destination org. Schema is stable across Jira versions.

Issues are the primary record type in Jira. Standard fields include Summary, Description, Status, Priority, Assignee, Reporter, Labels, and Due Date. We preserve all standard fields 1:1. Custom field values are mapped individually.

Jira ships with Issue Types: Task, Story, Bug, Epic (on Software plans), and sub-task variants. We map these directly and flag where the destination plan lacks a specific issue type (e.g., sub-tasks require a parent issue to exist first).

Subtasks are a distinct issue type that must be linked to a parent issue. The parent must exist in the destination before the subtask can be created. We sequence subtask creation after parent issue creation and validate the linkage in the target.

Workflows define Statuses and Transitions between them. Jira allows unlimited custom statuses and complex transition rules. We preserve workflow definitions but flag that unsupported validators (e.g., transition validators not supported by JCMA) are skipped during migration, which can alter permission enforcement on specific transitions.

Jira supports an unlimited number of custom fields per project with no enforced global schema. Custom fields are stored per project context. We map each custom field by name and type, but we flag that some field types (e.g., cascading select, multi-user picker) may require reconfiguration in the destination or may lose pick-list metadata when migrated to a platform with a flat field model.

Attachments are stored at the issue level. Jira Cloud imposes attachment size limits and the Jira Cloud Migration Assistant can migrate them, but oversized or corrupted files can cause import failures. We chunk large attachment batches and flag any file that exceeds the destination platform's size limit before attempting migration.

Comments are stored as issue children with author, timestamp, and body. Jira Cloud natively exports comments to CSV. We preserve full comment text and metadata. Where the destination platform does not support threaded comments, we flatten into sequential comments and preserve the reply chain via timestamps.

Worklogs track time spent on issues. Jira Software includes built-in worklogging; Jira may require an add-on. We preserve worklog entries and map them to the destination's time-tracking schema, flagging whether the destination has native time-tracking or requires a plugin.

Sprints are time-boxed collections of issues in Jira Software. Jira does not have native sprint management — it is a project type distinction. When migrating from Jira Software to Jira, we convert active sprint assignments into labels or a custom field so the timing context is preserved even without a native Sprint object.

Boards (Kanban and Scrum) are a visualization layer on top of Projects and Filters. They are not independent data objects — they reference a saved filter. We preserve the board configuration and the underlying filter JQL, but the board must be re-created in the destination if the Jira project key changes.

Components are optional groupings within a Project, used to assign default Assignees or Component Leads. We preserve Component names and assignments. Components do not carry their own issue data; they are a label on the issue.

Versions represent releases or milestones within a Project (e.g., v2.1, Q3 Sprint). Issues can be linked to zero or more Versions. We preserve Version names, release dates, and released/archived status.

Labels are free-text tags applied to Issues. Jira allows unlimited labels per issue. We migrate labels as-is. Labels are case-sensitive in Jira, so we preserve the exact casing as stored in the source.

Jira supports multiple link types between issues (Blocks, Is Blocked by, Relates to, Duplicate, etc.). Linked issues must exist in the destination for the link to be functional. We migrate link types and target issue keys, but we flag any link where the target issue is not included in the migration scope as a dangling reference that must be resolved manually.

User accounts, group memberships, and Project Role assignments are migrated via Jira's user management export. We map users to their destination accounts and flag where a user in the source has no match in the destination, requiring either account creation or reassignment before migration.