Moving Jira sprints and fix versions to Linear
Jira sprints and Linear cycles work differently. How to keep sprint and fix version history when you migrate, and switch without cutting a sprint in half.
Sprints and fix versions are where a Jira history keeps its context: which work happened when, and which release it shipped in. They're also the two things most Jira-to-Linear migrations quietly drop. Here's how they translate, and how to keep the history.
Jira sprints vs Linear cycles
Linear's equivalent of a sprint is a cycle, but the two behave differently:
| Jira sprint | Linear cycle | |
|---|---|---|
| Created | By hand, per board | Automatically, on a schedule set per team |
| Length | Anything you choose each time | Fixed duration, such as one or two weeks |
| Unfinished work | Moved by hand when the sprint closes | Rolls into the next cycle automatically |
| Scope | A board, which can span projects | One team |
Cycles are designed to run forward from today. That makes them great for the team's future work and a poor fit for recreating two years of past sprints.
Three ways to keep sprint history
- Don't keep it. Import issues without sprints and start cycles fresh. Fine if nobody looks at old sprints.
- Sprint labels. Add a label like
Sprint 42to each issue. Cheap and searchable, but a long list of labels clutters every label picker. - Sprints as projects. Create one Linear project per past sprint, containing that sprint's issues. History stays browsable — you can open Sprint 42 and see what was in it and how much got done — without polluting labels or cycles.
Jira-to-Linear-importer uses the third approach: every sprint is imported as a project, and the team starts using cycles from cut-over day.
Fix versions become releases
Fix versions answer "what shipped in 2.14?" — the question behind release notes, changelogs and incident reviews. Carry them over as Linear releases, keeping:
- the version name (
v2.14.0), - the release date, and whether it was released or still planned,
- the issues that were fixed in it.
Releases are available on Linear's Business and Enterprise plans. On other plans, keep each fix version as a label (v2.14.0) so "what shipped in 2.14?" is still one filter away.
Affects versions are used far less. A label (affects-2.13) is usually enough.
Linear's built-in Jira importer doesn't bring over sprints or fix versions; see what it leaves behind.
Story points and velocity
Turn on estimates for the team and choose the scale that matches your Jira points, so values carry across unchanged — Fibonacci points stay Fibonacci. Velocity starts fresh in Linear, and it takes three or four cycles before cycle reports are useful for planning. Keep the last few Jira velocity numbers handy until then.
Time the cut-over between sprints
Moving mid-sprint means half the sprint lives in each tool. Instead:
- Pick a cut-over date at a sprint boundary.
- Close the last Jira sprint as usual, moving unfinished issues to the backlog.
- Run the final import or sync.
- Configure cycles for each team to start on cut-over day, with the same length as your sprints.
- Plan the first cycle in Linear from the imported backlog.
If you import early and sync incrementally, the team keeps sprinting in Jira until that boundary and nothing needs to freeze.
Boards become views
Jira boards and saved filters become Linear views. Don't recreate all of them — ask each team which three boards they open every day and rebuild those. Linear's default views (active cycle, backlog, my issues) cover most of the rest.
For everything else that changes, see the Jira to Linear mapping guide.