Migrate from Backlog to Jira

Backlog Projects map directly to Jira Projects as the top-level container. We preserve the project key, name, description, project-level categories, and notification settings. Each Backlog project becomes one Jira project with its own issue type scheme, workflow, and field configuration. Project-level permission schemes are noted for manual configuration in Jira because Jira handles project permissions through permission schemes and project roles rather than Backlog's role model.

Backlog Issues map to Jira Issues with the type determined by Backlog's issue type name. Standard Backlog issue types (Task, Bug, Story, Enhancement) map to their Jira equivalents via the issue type scheme we configure before migration. Issue summary, description, status, priority, assignee, reporter, due date, start date, estimated hours, and spent hours all map to typed Jira fields. We preserve issue key references and Backlog's issue ID in a custom field backlog_issue_id__c for traceability.

Backlog Subtasks map to Jira Subtask issue types linked to their parent Issue via the Jira Subtask issue link. We configure the Jira issue type scheme to include Subtask before migration. The subtask status, assignee, priority, and description migrate directly; estimated and logged hours are preserved as subtask fields. Parent issue ID is resolved at migration time using the backlog_issue_id__c custom field to maintain the parent-child relationship across the API import.

Backlog Custom Fields exist only on Premium and Enterprise plans. On Free, Starter, and Standard accounts, this step is skipped entirely — we detect the plan tier during discovery and proceed without custom field mapping if none are configured. On Premium accounts, we map Backlog field types (text, numeric, date, list, multi-list, checkboxes, radio, dropdown) to the closest Jira custom field type (Free Text, Number, Date Picker, Select, Multi-Select, Checkboxes, Radio Buttons, Cascading Select). Fields that cannot map directly become Jira Free Text fields, and any unmappable field type is flagged in the reconciliation report.

Backlog Tags are free-form flat labels applied to issues. They map directly to Jira Labels, which are single-value string fields on Jira issues. Backlog's tag set is reconstructed as a Jira label scheme. Jira Labels are not hierarchical, matching Backlog's tag model, so no structural transformation is required.

Backlog Milestones (called Versions in the Backlog UI) map to Jira Versions attached to the corresponding project. We preserve the milestone name, planned release date, and description. Issue-milestone associations migrate as Jira fixVersion references on each affected Issue, so the backlog of issues in a given release is visible directly in the Jira release report.

Backlog Categories group issues at the project level and can represent product areas, services, or team assignments. We map them to Jira Components within each project. Component lead, description, and assignee are preserved where configured in Backlog. Issues are linked to their Component via the Component field on the Jira issue.

Backlog Users are mapped to Jira Users by email address match. User display name, email, and role are extracted from Backlog. Any Backlog user without a matching Jira account is flagged in the reconciliation report for the customer's admin to provision before the record import phase. Jira requires an active or inactive user to be present before Owner or Assignee fields can be populated.

Backlog Teams are group-level assignments that can be assigned to issues rather than individual users. We map Teams to Jira Groups. Team membership and team-issue assignments are preserved as Jira group memberships on the relevant issues. Jira Groups are used for notifications and project role membership but do not replace individual User assignment as issue Owner or Assignee.

Backlog Wiki pages are project-scoped and use a custom Backlog wiki markup format. We extract page content, titles, hierarchy (parent-child page relationships), and internal wiki links. Backlog wiki markup is converted to plain text or Jira-supported wiki markup, preserving headings, lists, code blocks, tables, and internal page references. Pages without a clear markup equivalent are flagged in the handoff report for manual review. Jira does not have a native wiki — Confluence is the Atlassian wiki product — so migrated pages land as plain-text or lightly formatted pages in Jira's description and comments fields.

Backlog Git and Subversion repositories are project-scoped. Repository names, URLs, and the repository description migrate as Jira Software repository references if the destination Jira instance has Jira Software Development panel enabled. The actual source code does not migrate. We document repository URLs and any linked issue keys for the customer's development team to re-establish CI/CD links in their pipeline.

Backlog pull request metadata (title, description, reviewers, status, comments) linked to Git repositories migrates as Jira Development panel data associated with the mapped Jira issue. PR status (Open, Merged, Declined) is preserved as a comment on the Jira issue with PR title and link. Actual diff and code review comments do not migrate. PR-to-issue links are reconstructed using the Backlog issue key embedded in the PR title or description field.