# 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.

Published October 20, 2026 · https://jira-to-linear.com/guides/jira-to-linear-field-mapping/

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](https://jira-to-linear.com/guides/jira-sprints-and-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](https://jira-to-linear.com/guides/migrate-jira-to-linear/) covers the rest, and the [migration checklist](https://jira-to-linear.com/guides/jira-to-linear-migration-checklist/) keeps cut-over day boring.