How to migrate from Jira without losing the history that matters

Every guide to leaving a tracker skips the same part. It explains how to get data out and how to get data in, and says nothing about the fact that the data you are most afraid of losing is the data that survives an export least well.

This is for a team of three to fifteen that has decided to go. Moving off Jira to another tool is a decision problem more than a data problem, so the useful version of how to migrate from Jira is mostly about what you agree to leave behind. Done looks like this: everyone opens the new tool on Monday without asking where something went, and the two or three times a year someone needs a decision from eighteen months ago, they can still find it.

Some teams should stay

Three things make the cost real rather than theoretical. If you rely on Jira's reporting — burndown, velocity chart, control chart, cumulative flow diagram, sprint report and the rest of the documented set (support.atlassian.com) — nothing smaller has an equivalent, and you will not rebuild a control chart in a spreadsheet. If a Marketplace app is load-bearing, you are leaving an ecosystem Atlassian advertises as 6,000+ apps and integrations (developer.atlassian.com), and the replacement for your specific app may not exist. And if other teams depend on an org-wide permission model, the migration is not yours to make alone.

Those are not reasons to feel stuck. They are reasons to stop reading.

How to migrate from Jira, in seven steps

1. Decide what "history" means to you

"We can't lose our history" is five requirements wearing one coat, and they cost wildly different amounts:

Most teams need the first and read-only access to the second. Almost nobody needs the fifth, and the teams that genuinely do — a regulator or a contract asks — should read that as a reason to keep the old instance alive, not to hunt for a cleverer importer.

2. Export Jira issues before you cancel anything

The one step with no undo. Everything else here can be done badly and fixed later. Losing access to the instance cannot. Two ways out, and you want both.

The CSV export, from the issue navigator. Atlassian supports exporting up to 10,000 work items asynchronously, and tells you to split a bigger result set into JQL batches and merge the files yourself (support.atlassian.com). Use the all-fields variant — Atlassian's guidance is that it contains all fields "including each comment made" (support.atlassian.com). That page also carries the bad news about attachments: Jira Cloud does not natively support downloading the files in bulk, only exporting their URLs.

The full site export, from Backup Manager. Atlassian lists what it contains: work items and field content, board and sprint data, users and group settings, comments, and media files including attachments "if selected" (support.atlassian.com). Tick the additional-files option or the attachments are not in there. The same page notes you must allow 48 hours between backups that include media — so not the afternoon before you cancel.

For attachment files rather than links, Atlassian's own knowledge base says plainly that "there is no direct functionality in Jira Cloud's UI to export all attachments from a project", then walks you through a REST API loop that pages through work items in batches of 100 and downloads each URL (support.atlassian.com). An afternoon of scripting, and the only path.

The audit trail is the other gap. The CSV page describes fields and comments; the site export page lists work items, fields, boards, sprints, users, comments and media. Neither lists the per-field change history, so getting that means the REST API issue by issue — thousands of requests for data nobody will open.

Then put the files somewhere you own, not one person's Downloads folder. Atlassian's cancellation page says that after your subscription period ends "you'll be able to access your site for 15 more days" (support.atlassian.com), which is not long enough to write a script in.

3. Move open work by hand, deliberately

Filter to open issues and decide on each: still real, or quietly dead? A large part of any old backlog is neither open nor closed but abandoned, and retyping is the only process that reliably surfaces it. This is the cheapest backlog cleanup you will ever get, and it works exactly once. The volume is smaller than the dread suggests — a five-person team with a year of history has hundreds of issues and a few dozen open ones. Two people, one afternoon.

We should be direct about our own product here, since it is the obvious conflict. Kevta has no Jira importer. The import and export screen in workspace settings lists Jira, GitHub Issues, Trello and CSV and says on its own face that none of them move any data yet, and there is no export either. Moving to Kevta means retyping — a real cost, and not one we are going to call a feature. It is also why we suggest starting on your next piece of work rather than the backlog. Kevta has no story points, no sprints, no burndown and no reporting layer either; if the audit trail mattered in step one, we are not your answer. What it has is stable issue keys, full per-task history from the day you start, and board, list, table and calendar views over the same work.

4. Leave the closed issues in the export

The instinct is to import everything so the new tool "has the history". Resist it. A thousand imported closed issues with mangled comments, missing attachments and a creation date of today is not history — it is noise that makes every search in your new tracker worse, permanently. Closed work gets read in one pattern: someone needs to know why a decision was made, twice a year. Grep in a CSV serves that fine.

Better still, keep the old instance. Jira's Free plan covers up to 10 users (support.atlassian.com), so a team that was paying can often downgrade rather than cancel and keep a searchable archive at no cost.

5. Deal with the issue keys before someone asks

PROJ-412 is in commit messages, branch names, PR titles, Slack threads, runbooks and a design doc from last spring. Those references are permanent and no migration preserves them. Your new tool assigns its own keys starting from one — Kevta lets you set a board's key prefix, but the sequence still starts fresh, and so does everyone else's.

So record the mapping: a two-column CSV of old key to new key, committed to the repo. Ten minutes, and it is the difference between an old commit message being a lead and a dead end. Nobody will reconstruct it later.

6. Run both for a short, fixed overlap

Overlap is fine as long as one tool is unambiguously where new work gets created and the overlap has an end date announced at the start. Two weeks is plenty. Without a date the old tool never dies, and six months later half the team is still filing bugs into an instance nobody reads.

On the last day, bulk-change everything still open in Jira into a closed or archived status, so the old instance cannot be mistaken for live. Atlassian caps that at 1,000 work items at a time (support.atlassian.com), which at this size is one pass. Do not build a two-way sync in the meantime — that is a project, and you are trying to finish one.

7. Tell people once, plainly

One message: where work goes now, from when, where the old stuff lives, who to ask. Not a rollout plan, not a training session. Then move the links people actually use — the bookmark in the repo README, the pinned message in the channel, the row in the onboarding doc. Migrations fail at the link nobody updated, not at the data.

What done looks like

The export is a file you own and could restore from. Open work is in the new tool and shorter than it was, because you read it. Closed work is searchable somewhere, probably still in Jira on a free plan. The key mapping is committed. The old instance is read-only with a date on it.

Notice what is not on that list: a replica of your Jira instance in another tool. That was never the goal, and chasing it is how a two-afternoon migration becomes a quarter.

If you are still deciding what to move to, the shortlist is in Jira alternatives for small teams, and the case for leaving at all in why small teams outgrow spreadsheets but drown in Jira. Kevta is in beta with a waitlist — if a tracker that expects you to retype your open backlog and nothing else sounds right, put your name down.