Migrating from Jira is easy to start and hard to finish well. Self-managed teams are being pushed to move: Atlassian ended Server support on February 15, 2024, and Data Center reaches end of life on March 28, 2029, when its subscriptions and Marketplace apps expire and become read-only. Cloud teams move for price or fit. Either way the risk is the same. An import that looks complete on day one can be missing the comment thread that explains why a decision was made, and you only notice months later. The fix is to decide in advance what moves, what stays, and where the history lives.
1. Know What the Export Contains
Most migrations start from Jira's CSV export. Atlassian's own guidance is worth reading before you click: to get comments you need the all-fields export, and each comment is written to its own Comment column, in chronological order. Jira Cloud also does not download attachment files in bulk; the CSV can carry attachment URLs, but the files stay in Jira unless you use a Marketplace app. The asynchronous CSV export handles up to 10,000 work items, and Atlassian recommends choosing the fields you need rather than exporting all of them, because all-fields files are slow and hard to manage.
2. Ask Every Importer What It Drops
No importer carries everything, and the honest ones say so. ClickUp's comparison page lists that its Jira importer brings issues, subtasks, assignees, comments, attachments up to 1GB and statuses, while recurring tasks, timestamps, the priority field and user-defined custom fields do not transfer. Linear has a dedicated Jira importer that only a workspace admin can start. Kavanah imports a Jira CSV: it reads Summary, Description, Status, Priority, Assignee, Due date, Labels and Comment, up to 1,000 rows at a time, and it reads only the first Labels column and the first Comment column. Issue keys, issue types, sprints, parent links, versions, story points and attachments are not imported. Put each tool's list next to the fields your reports use before you choose.
3. Pilot One Project, Not the Company
Move one live project first and run it for two sprints. If the new tool can work beside Jira, the pilot is safer still. Linear offers a two-way Jira Sync for this. Kavanah's Jira connector lets its agent search issues with JQL, create issues, edit summary, description and due date and move status by workflow transition, with every write waiting for approval by default; it does not mirror issues into Kavanah tasks automatically. Either way, the pilot answers the question an import report cannot: does the team still find what it needs?
4. Keep Jira as the Archive
The history you are most likely to lose is the long tail: comments after the first, edits, linked issues, attachments. Do not try to carry all of it. Keep the full CSV export, keep the Jira site readable for a period you choose, and say in the new tool where the old record lives, for example in each imported project's description. If you are on Data Center, plan the archive around March 28, 2029, when Atlassian says Data Center products become read-only.
5. Fix the Links That Break
Two kinds of reference break in every migration. People's names: an importer matches assignees to members, and anyone who has not joined yet arrives as plain text, so invite people before the import or reassign after it. And keys: old pull requests and documents say ENG-412. In Kavanah, new pull requests should reference the task as fixes #123 or task 123, which links them; a Jira key in an old pull request title will not.
A migration without regrets is mostly a list: what moves, what stays, and where the rest is kept. For the full comparison of what Kavanah, Linear, ClickUp and monday dev bring across from Jira, see our Jira alternative page.
