Jira to Linear mapping: epics, sprints, statuses and fields
How Jira concepts translate to Linear: projects and keys, epics, issue types, statuses, priorities, story points, sprints, versions, links and custom fields.
Linear is opinionated: fewer concepts, fewer settings, one workflow per team. That's why teams move to it — and why a Jira migration needs a plan for every concept that doesn't have a one-to-one equivalent. This is the mapping we recommend, field by field.
The full mapping
| Jira | Linear | Notes |
|---|---|---|
| Site | Workspace | One workspace for the whole company is typical |
| Project | Team | Use the Jira project key as the team key |
Issue key (ENG-1423) |
Issue identifier (ENG-1423) |
Same key if imported in order into an empty team |
| Epic | Project | Or a parent issue for small epics |
| Story, task, bug | Issue | Keep the type as a label: Bug, Story |
| Sub-task | Sub-issue | |
| Summary, description | Title, description | Jira rich text becomes Markdown |
| Status | Workflow state | Map many Jira statuses onto a few states |
| Resolution | Completed or canceled state | "Won't do" and "Duplicate" become canceled |
| Priority | Priority | See the priority table below |
| Story points | Estimate | Pick an estimate scale that fits your points |
| Sprint | Cycle (future), project (history) | Cycles run forward; see below |
| Fix version | Release | Business and Enterprise plans; otherwise a label |
| Affects version | Label | Rarely worth more than a label |
| Component | Label | Team-level labels keep them scoped |
| Label | Label | Merge near-duplicates first |
| Assignee, reporter | Assignee, creator | Matched by email address |
| Watchers | Subscribers | |
| Comments | Comments | Keep order, authors and timestamps |
| Attachments | Files uploaded to Linear | Don't leave them as links back to Jira |
| Issue links | Relations | Blocks, related, duplicate |
| Development panel (PRs) | Pull request links | |
| Due date | Due date | |
| Custom fields | Labels, description, or dropped | Decide per field |
| Board, filter | View | Recreate the handful people actually use |
Projects become teams
In Jira, a project owns its issues, workflow and key. In Linear, that's a team. Create one team per Jira project you're moving and give it the same key — ENG stays ENG — so issue identifiers keep their prefix. If several Jira projects belong to one real team, you can merge them into one Linear team, but then only one of the old prefixes survives.
Linear's projects are something else: time-boxed bodies of work with a goal, often spanning several teams. That's why Jira epics map best to Linear projects.
Epics become projects (usually)
A Jira epic that represents a deliverable — "New checkout", "SAML login" — becomes a Linear project, with its issues attached. Small epics that are really just a group of three tasks work better as a parent issue with sub-issues. Linear's own importer turns every epic into a project, so review the result and convert the small ones.
Issue types become labels
Linear has one kind of issue. Keep the Jira issue type as a label (Bug, Story, Task) so filters such as "all open bugs" still work. Many teams later drop Story and Task and keep only Bug.
Statuses become workflow states
Each Linear team has one workflow, made of states in fixed categories: triage, backlog, unstarted, started, completed and canceled. Jira projects often have more statuses than anyone remembers. Map them by meaning:
| Jira status (examples) | Linear state | Category |
|---|---|---|
| Open, Backlog, New | Backlog | Backlog |
| To Do, Selected for Development, Ready | Todo | Unstarted |
| In Progress, In Development, Doing | In Progress | Started |
| In Review, Code Review, QA | In Review | Started |
| Done, Closed, Resolved (fixed) | Done | Completed |
| Won't Do, Duplicate, Cannot Reproduce | Canceled | Canceled |
Add a state only if people genuinely act on the difference.
Priorities
Linear has four priorities plus "No priority". Jira has five by default.
| Jira | Linear |
|---|---|
| Highest | Urgent |
| High | High |
| Medium | Medium |
| Low | Low |
| Lowest | Low, or No priority |
Story points become estimates
Turn on estimates for the team and choose a scale — Linear offers exponential, Fibonacci, linear and t-shirt sizes. If your Jira points were Fibonacci, keep Fibonacci and values carry over directly. Velocity charts start fresh in Linear either way.
Sprints and fix versions
Linear cycles are the equivalent of sprints, but they're scheduled forward and roll unfinished work into the next cycle automatically, so recreating years of past sprints as cycles isn't practical. Keep sprint history as projects or labels and start cycles fresh on cut-over day. Fix versions become releases on Linear's Business and Enterprise plans, or labels on other plans. Both are covered in detail in moving Jira sprints and fix versions to Linear.
Issue links become relations
Linear supports three kinds of relation: blocks / blocked by, related, and duplicate. Map Jira's link types onto them: "blocks" and "is blocked by" stay as blocking relations, "duplicates" becomes a duplicate, and everything else ("relates to", "clones", "causes") becomes related.
Custom fields
Linear keeps issue fields deliberately minimal, and its built-in importer doesn't bring Jira custom fields across. For each custom field, choose one:
- Label — for fields with a few fixed values that people filter by, like Severity or Platform.
- Description — for free text worth keeping, like Steps to reproduce or Customer. Append it under a heading.
- Drop — for fields nobody has looked at in a year. Be honest; it's most of them.
Next steps
With the mapping decided, you're ready to plan the move itself. The step-by-step migration guide covers the rest, and the migration checklist keeps cut-over day boring.