Software companies
Jira to Linear (or other tracker) migration: preserving issue history
By SourceX Editorial · Updated
Short answer
A Jira migration to Linear or another tracker usually carries over current issues, descriptions, comments and assignees, but changelogs, status transitions, worklogs and many links often do not arrive intact. Before cutover, take a full Jira export with changelogs and attachments, keep the old site readable, and map old issue keys to new IDs so commits and tickets still resolve.
Key takeaways
- Importers are built to move current work, so they carry the latest state of an issue more reliably than its history.
- The changelog, which records every status, assignee and priority change with timestamps, is the part most often lost.
- Take the full export before cutover, while Jira is still the system of record and nothing has drifted.
- A key map from old Jira keys to new tracker IDs keeps commit messages, pull requests and support tickets meaningful.
- Test the importer on one real project and compare the result field by field before migrating everything.
What does a Jira migration actually move?#
A Jira migration moves the current state of your work far more reliably than the history of how it got there. Importers for Linear and other trackers are designed so a team can keep working the next morning: titles, descriptions, comments, assignees, labels and current status come across, while the record of every change along the way is often flattened or dropped.
What exactly carries over varies by importer, by Jira edition and by how heavily your instance was customized, so treat the table as a starting hypothesis. Run the importer against one real project, then compare a sample of issues side by side with Jira before trusting any row.
| Jira element | Typically migrates | Often lost or flattened | How to keep it |
|---|---|---|---|
| Summary, description, comments | Yes, as text | Formatting, mentions and comment authorship when users are unmapped | Map users before import; keep raw export |
| Current status, assignee, priority | Yes, mapped to new values | Workflow states that have no equivalent | Record the state mapping table |
| Changelog of field changes | Rarely | Every past status, assignee and priority change | Pull changelogs through the API before cutover |
| Custom fields | Partly | Fields folded into labels or description text | Export field definitions and values |
| Sprints, versions, epics | Partly | Sprint membership history and version dates | Export boards, sprints and versions separately |
| Worklogs and time tracking | Rarely | Who logged time and when | Export worklogs through the API |
| Attachments | Often, with limits | Large files and inline images | Download attachments keyed by issue |
| Issue links and remote links | Partly | Links to Zendesk, Confluence and GitHub | Export remote links per issue |
| Issue keys | No, new IDs are assigned | Every reference to the old key | Build and publish a key map |
What the lost history was telling you#
Lost Jira history is the record of how work actually moved, and it answers questions the current state cannot. Time spent in each status, how often an issue bounced between QA and development, which bugs were reopened after release and when priority was escalated all live in the changelog, not in the fields you see on the issue today.
Engineering leaders use that history for cycle-time analysis, incident reviews and audits. It also matters if the company later considers licensing engineering records: AI developers training or evaluating coding agents look for the sequence of a fix, from report to triage to pull request to release, and a tracker that kept only final states shows the destination without the route.
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
The full-export step before cutover#
The full export is a separate project from the migration and should finish before the importer runs. Once the team starts working in the new tracker, Jira stops being the system of record, and any later export captures a site that is already drifting.
Assign it to one engineer with admin rights and give it a written definition of done. The steps below assume Jira Cloud or Data Center with API access; adjust for your edition and plan.
- Freeze schema changes in Jira: no new custom fields, workflows or project restructures until the export is complete.
- Take a full site or instance backup through the edition's own backup tool and store it outside Atlassian.
- Pull every issue's changelog, worklogs and remote links through the REST API, saved as raw JSON keyed by issue key.
- Save every attachment under a folder for its issue key and log each download that fails.
- Export workflows, field definitions, boards, sprints and versions so the history can be interpreted later.
- Save the user directory with account IDs and display names, including departed users.
- If you also want a flat CSV index, note that Atlassian supports Jira Cloud CSV exports of up to 10,000 work items at a time and recommends splitting larger exports into JQL batches, for example by date range.
- Count issues per project in the export and in Jira, and spot-check changelogs on issues you know well.
- Cancel or downgrade only after verification. Atlassian says a cancelled site stays accessible for 15 days after the subscription period ends before deactivation, which is too short to rely on for a first export.
Keep old issue keys resolvable#
Old issue keys keep working only if someone maps them deliberately. Commit messages, branch names, pull request titles, Zendesk tickets, Slack threads and Confluence pages all reference keys like the ones in your project prefixes, and after migration those references point at nothing unless a key map exists.
Build a simple table of old key, new tracker ID and archive location, and store the old key as a field or label on each migrated issue. If the budget allows, keep the Jira site on a reduced plan in read-only mode until the archive has been tested; if not, publish the key map next to the exported archive so engineers and support staff can still trace an old reference.
Migrate everything, migrate open work, or start fresh?#
The migration scope decision is mostly about how much history the team needs inside the new tool versus beside it. Each option is reasonable when the full export already exists; none is safe without it.
| Option | Fits when | Main risk | Archive need |
|---|---|---|---|
| Import everything | Teams search old issues daily inside the tracker | Clutter and flattened history presented as complete | Still required for changelogs and worklogs |
| Import open work only | Most old issues are closed and rarely revisited | Engineers lose quick search across old bugs | Required, and must be searchable |
| Start fresh | The old backlog no longer reflects the product | Context for recurring bugs disappears | Required, with key map published |
| Phase by project | Teams move at different times | Two trackers in use, links split across both | Export each project before its move |
Illustrative: a construction scheduling software company moves to Linear#
Illustrative: a fictional company whose project scheduling product is used by general contractors decided to move engineering from Jira Cloud to Linear. Its Jira history covered many years of bugs, feature work and incidents, and its GitHub commit messages and Zendesk escalations referenced Jira keys throughout.
The CTO split the work in two. One engineer ran the full export first: site backup, changelogs and worklogs through the API, attachments by issue key, workflows and the user directory. Only then did the team import open issues and the current quarter's closed work into Linear, with the old Jira key stored on each issue.
The key map went into the engineering wiki beside the archive, and Jira dropped to a reduced plan in read-only mode until spot checks passed. When the company later inventoried its records for a data licensing fit check, the archive showed full report-to-release sequences that the Linear workspace alone could not.
How SourceX looks at migrated issue history#
SourceX treats issue histories as a record family whose value depends on linkage and completeness, both of which a migration can quietly reduce. During a metadata-only fit check, SourceX asks which trackers the company has used, how far back history is still accessible and whether changelogs survived, without asking for any files.
If records proceed through the SourceX five-step transaction, the exported archive stays in the company's own storage, and the SourceX Evidence Packet records provenance, including which tracker each record came from and how the export was produced.
Frequently asked questions
Can we re-import the Jira archive into Linear later?
Sometimes, but expect the same losses the first import had, plus new problems with users and states that changed since. Treat the archive as the authoritative history and the new tracker as the place for current work, rather than trying to merge them after the fact.
Will a Linear export capture everything later if we move again?
Not necessarily. Linear's admin CSV export covers workspace issue fields, and its documentation indicates comments may not be included; the emailed download link expires after 12 hours. If you rely on Linear history, plan an API-based archive the same way you did for Jira.
How long should we keep the old Jira site running?
Keep it until the archive has been verified and the key map has been tested on real references from commits and tickets. After that, the decision is a cost tradeoff. Many teams downgrade to a reduced read-only plan for a period rather than deleting the site on cutover day.
Do we need to export Confluence too?
If Jira issues link to Confluence pages for specs, runbooks or postmortems, yes. Those remote links break when either system goes away, and the pages often explain why an issue was handled the way it was. Export the linked spaces with page history at the same time as Jira.
What happens to issues created by people who have left?
Importers usually need a user mapping, and departed users may be mapped to a placeholder or to the person running the import, which misattributes history. Save the Jira user directory with account IDs before cutover so the archive can still show who did what.
Does the same advice apply to moving from Jira to GitHub Issues or Azure Boards?
Yes. The specific fields that survive differ by tool, but the pattern holds: current state migrates, history and links are at risk, and issue keys change. Run the full export first, test the importer on one project, and publish a key map whatever the destination.
Sources
- Atlassian states that exporting up to 10,000 work items using the asynchronous Export CSV feature from the Jira Cloud Issue Navigator is supported, and recommends splitting larger exports into JQL batches (for example by date range) of fewer than 10,000 work items each. Source
- Atlassian states that cancellation takes effect at the end of the billing period and the site remains accessible for 15 more days after the subscription period ends before deactivation. Source
- Linear admins can export workspace issue data as CSV from Settings > Administration > Import/Export; the emailed download link expires after 12 hours, and the workspace export covers issue fields while comments may not be included. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.