Software companies
Moving from Jira to Linear: what history you lose and how to keep it
By SourceX Editorial · Updated
Short answer
Moving from Jira to Linear usually carries over issues, descriptions, comments and assignees, while field change history, worklogs, past sprints and many custom fields arrive flattened or not at all. The rule that protects you: build a complete Jira archive with changelogs and attachments, verify it, and keep it before the Jira subscription ends.
Key takeaways
- A tracker import moves the current state of work; the changelog showing how work moved usually stays behind.
- Attachments and links that point back to Jira can break once the old site closes, so check them in a test import.
- Keep a full Jira archive, reconciled against record counts, before canceling or downgrading Jira.
- Store the old Jira key on every imported issue so commits, pull requests and wiki pages still resolve.
- A verified archive keeps options open for audits, acquisitions and licensing reviews long after cutover.
What history do you lose moving from Jira to Linear?#
Moving from Jira to Linear mostly loses the layers of history underneath each issue: who changed a status or priority and when, how long work sat in each state, logged time, sprint membership and the custom fields teams invented over the years. Linear and third-party tools can import Jira projects, and the current text of most issues comes across.
The two tools model work differently. Jira lets every project carry its own workflow, issue types and fields, while Linear organizes work around teams, a compact set of workflow states, cycles and projects. Anything that does not map cleanly becomes a label, gets folded into the description or is dropped.
Importer behavior changes with versions and options, so treat the next section as a list of things to test rather than a guarantee of what will happen.
What transfers and what does not, concept by concept#
The concept map below shows where Jira history tends to land in Linear and what to check in a trial import. Run that trial on one busy project with long comment threads, attachments and linked issues, then compare a sample of issues side by side in both tools.
| Jira concept | Usual landing spot in Linear | What to check in a test import |
|---|---|---|
| Summary and description | Issue title and description | Formatting, mentions and embedded images |
| Comments | Comments, attributed by user matching | Authors who have left and comment order |
| Status and workflow | Team workflow states | Custom statuses collapsed into fewer states |
| Changelog (field history) | Usually not carried | Whether any transition history survives |
| Epics and parent links | Projects or parent issues | Child issues attached to the right parent |
| Sprints | Cycles going forward, rarely historical | Past sprint membership and scope changes |
| Custom fields | Labels, description text or dropped | Fields for severity, customer or root cause |
| Components and fix versions | Labels or project milestones | Release history tied to issues |
| Worklogs | No direct equivalent | Whether time data is needed for audits or billing |
| Issue links | Relations where types match | Duplicates, blocks and causes links |
| Attachments | Uploaded files or links back to Jira | Links that break once the Jira site closes |
Why the lost layers matter after cutover#
The lost layers are the part of Jira history that shows how work actually happened. A changelog reveals that a bug was reopened repeatedly, that its priority jumped after a customer escalation and that it sat in review far longer than planned.
Teams reach for that history in postmortems, security reviews, customer disputes and acquisition diligence. AI developers look for it too: an issue with its discussion, status changes, linked commits and final resolution is a record of real engineering judgment, while a flattened copy shows only the end state.
Custom fields deserve special attention. Fields such as root cause, affected customer tier or severity often hold the labels that make an issue history useful for analysis, and they are among the first things an importer converts or drops.
The keep-a-full-Jira-archive rule#
The keep-a-full-Jira-archive rule is simple: do not cancel or downgrade Jira until a complete archive exists, has been reconciled against record counts and has been opened successfully by someone other than the person who built it. The Linear import is a working copy; the archive is the record.
Jira's built-in exports and site backups are useful additions, but check what each includes on your plan. Atlassian's cloud change notes for February 2, 2026 say the Jira CSV export now handles many fields and large data sets but processes only one CSV export at a time, so a large site has to be exported in a queue. CSV also flattens changelogs, and a site backup is designed for restoring into Jira rather than for reading.
- Export every project through the Jira REST API with the changelog expanded, saving raw JSON rather than only CSV.
- Download attachments separately, keeping original filenames and the issue key each belongs to.
- Export users, groups, project roles, workflows, issue types and field configurations so the archive can be interpreted later.
- Capture sprint, board and version data, which often sits outside issue exports.
- Record Confluence pages, repository references and service desk queues that point into Jira.
- Reconcile counts per project between the live site and the archive, and read several long issues end to end.
- Store the archive read-only with an index, a short field guide and a named owner.
Keep old issue keys resolvable#
Old issue keys need to stay resolvable because years of commits, pull requests, runbooks and support tickets cite them. A commit message saying it fixes a Jira key is only useful if someone can still find that key after cutover.
Store the original Jira key on each imported Linear issue, as a label, a field or a line in the description, and keep a mapping file from old key to new identifier. Add the mapping to the archive index so a future reader can follow a commit to the archived issue and then to its Linear successor.
Choosing how much to migrate#
Choosing how much to migrate is a trade-off between a clean start and continuity. Whatever you choose, the archive rule still applies, because every option leaves some history only in the archive.
| Option | What goes to Linear | What lives only in the archive | Fits when |
|---|---|---|---|
| Full import | All projects, open and closed | Changelogs, worklogs, unmapped fields | Teams search old issues daily |
| Open work plus recent history | Active issues and a recent slice of closed ones | Older closed issues and all field history | Most lookups concern current product areas |
| Fresh start | Nothing, or a few open items recreated | Everything | Jira was cluttered or the product line is changing |
Illustrative: a cleaning-industry software team changes trackers#
Illustrative: a fictional software company that sells scheduling and quality-inspection tools to commercial cleaning contractors has used Jira for years across product, support escalation and platform projects. Engineering leadership wants Linear for speed, and finance wants to drop Jira at renewal.
A trial import of the escalation project shows that comments and assignees arrive, but the custom field holding the contractor-reported root cause becomes a label on some issues and vanishes on others, and attachments arrive as links to the old site. The CTO chooses open work plus recent history, stores each Jira key as a label and builds a full archive through the API with changelogs and attachments.
The archive is reconciled project by project, indexed and stored read-only, and finance keeps a minimal Jira license until that check is signed off. When an acquirer later asks how long contractor-reported defects took to resolve, the answer comes from the archive's changelog, not from Linear.
How SourceX treats issue history after a migration#
SourceX treats a verified Jira archive as a stronger record than a migrated copy, because it keeps status changes, linked commits and resolution fields intact. In the Supply step of the SourceX five-step transaction, the fit check asks which trackers the company has used, how far back each archive reaches and whether changelogs were kept.
Rights and Preparation follow: security, HR and legal issues are excluded, customer names and credentials are removed, and the SourceX Evidence Packet records provenance, including the path from Jira to Linear, so a buyer knows which system each record came from and what the supplier approved for release.
Frequently asked questions
Should we keep Jira read-only after moving to Linear?
Keeping a minimal Jira site read-only while the archive is checked is a sensible bridge. Once the archive has been reconciled, opened by a second person and indexed, many teams let the site lapse. Check legal holds and customer commitments first, since either can require keeping the original system available.
Does Jira Service Management history need the same treatment?
Yes, and often more care. Service desk requests carry customer identities, SLA timers and internal comments that matter in disputes and support analysis. Export them with request types, participants and comments, and keep them linked to the engineering issues they escalated into.
What happens to comments from people who have left?
Importers match comment authors to existing users, so departed employees may be attributed to a placeholder or to whoever ran the import. The archive keeps the original author identifiers. Note this in the archive index and avoid treating imported attribution as authoritative in any review.
Can we move back from Linear to Jira later?
Usually, but each move flattens history again. Linear admins can export workspace issue data as CSV from its Import/Export settings, but that export covers issue fields and may not include comments, and a return import faces the same mapping limits in the other direction. The Jira archive remains the most complete record of the years before Linear, which is one more reason to keep it verified and easy to find.
Are Confluence pages affected by the move?
Confluence pages are not moved by a tracker migration, but embedded Jira issue lists and links may stop working once the Jira site closes. List pages that embed Jira content, export them with the archive and keep the key mapping so readers can still follow references.
Sources
- Atlassian's Cloud changes notes for February 2, 2026 state that the Jira CSV export is faster, can handle many fields and large data sets, and only one CSV export can be processed at a time. Source
- Linear admins can export workspace issue data as CSV from Settings > Administration > Import/Export; the export covers issue fields and comments may not be included. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.