# Keep your Jira issue keys when you move to Linear

> Why ENG-1423 should stay ENG-1423 when you move from Jira to Linear, how identifiers work in both tools, and how to keep links, branches and PRs working.

Published October 20, 2026 · https://jira-to-linear.com/guides/keep-jira-issue-keys-in-linear/

Issue keys leak everywhere. `ENG-1423` is in commit messages, branch names, pull request titles, design docs, Slack threads, customer emails and a dozen browser bookmarks. If the key changes during a migration, every one of those references quietly stops pointing at anything. Keeping keys unchanged is one of the highest-value things a migration can do — and one of the easiest to get wrong.

## How keys work in Jira and in Linear

Both tools build keys the same way: a short prefix plus a number.

- **Jira:** the prefix is the project key, and numbers are assigned per project. `ENG-1423` is the 1,423rd issue created in the `ENG` project. Deleted or moved issues leave gaps.
- **Linear:** the prefix is the team key, and numbers are assigned per team, in creation order. `ENG-1423` is the 1,423rd issue created in the `ENG` team.

So keeping keys takes two things: the **same prefix**, and the **same numbers**.

## Step 1: keep the prefix

Give each Linear team the key of the Jira project it replaces. You set the key when creating the team and can change it later in the team's settings. If you merge several Jira projects into one Linear team, only one prefix survives — consider keeping separate teams until people stop typing the old keys.

## Step 2: keep the numbers

Because Linear numbers issues in creation order, matching numbers means creating issues in exactly the order of their Jira keys, into a team that's empty — and accounting for the gaps Jira left behind when issues were deleted or moved to another project.

Linear's built-in Jira importer can match identifiers this way, but only when importing into a new or empty team. Import into a team that already has issues and you get new numbers, with a backlink to the original Jira issue instead.

That has two practical consequences:

- **Import before anyone creates issues in the new team.** Even one test issue shifts every number after it.
- **Import each project once, in full.** Importing in batches — recent work now, history later — breaks the numbering for whichever batch comes second.

Tools built for full migrations, such as [Jira-to-Linear-importer](https://jira-to-linear.com/), keep the prefix and handle ordering for you.

## What identical keys buy you

### Links in docs fix themselves with one search-and-replace

A Jira issue lives at `https://your-site.atlassian.net/browse/ENG-1423`. A Linear issue lives at `https://linear.app/your-workspace/issue/ENG-1423`. When keys are identical, replacing the URL prefix in your wiki, README files and runbooks fixes every link at once. Without identical keys, every link needs a lookup.

### Branches and pull requests keep linking

Linear's GitHub integration links a pull request to an issue when the issue's identifier is in the branch name, or follows a magic word such as `Fixes ENG-1423` in the pull request's title or description. Branches named `eng-1423-fix-checkout` that were opened before the migration link to the right Linear issue as soon as you connect the integration — no renaming required.

### People's memory keeps working

"Wasn't that fixed in ENG-1388?" is how teams talk. Search in Linear finds `ENG-1388` the same way Jira did.

## If keys can't be kept

Sometimes they can't: two Jira projects merge into one team, or the target team already has issues. Then make the old key findable:

- Put the original Jira key on every imported issue — as a link, a label or the first line of the description — so searching for `ENG-1388` still finds it.
- Keep Jira read-only for a while so old links still resolve.
- Export a two-column mapping (old key, new key) and keep it with your migration notes.

## Checklist

- [ ] Create one Linear team per Jira project, with the same key
- [ ] Don't create any issues in those teams before the import
- [ ] Import each project in a single run, in key order
- [ ] Spot-check a few keys, including ones just after a deleted Jira issue
- [ ] Connect GitHub or GitLab and check an open pull request links correctly
- [ ] Replace the Jira URL prefix with the Linear one in docs and wikis

More on planning the whole move in the [step-by-step migration guide](https://jira-to-linear.com/guides/migrate-jira-to-linear/).