Migrating from Jira without losing your history

Ask a team why they're still on Jira when nobody on it seems to like it, and you'll rarely hear a defense of the tool. You'll hear a fear about the data. Years of issues, the comment threads where decisions actually got made, the epic hierarchy that encodes how the org thinks, the issue keys that are hard-linked from a thousand pull requests and Slack messages and Confluence pages — all of it feels load-bearing, and all of it feels like it would evaporate in a migration. So the team stays, not out of loyalty, but out of a reasonable terror of arriving somewhere new with amnesia.

That fear is the real lock-in, and it's worth taking seriously instead of waving away. A migration that drops your history isn't a migration — it's starting over with a worse search index. The bar for moving off Jira honestly isn't 'can we get the open issues across.' It's 'can we get the open issues, the closed ones, the comments, the hierarchy, the keys, and the external links across, such that the new system answers every question the old one could.' This piece walks through how to clear that bar.

Decide what 'history' actually means to you

Before you export a single CSV, get specific about which history is load-bearing, because the answer shapes the whole migration. For most teams it's four things. First, the issues themselves — open and closed, because a closed issue is often the only record of why something works the way it does. Second, the discussion: comments are where the real reasoning lives, and a tracker without them is a filing cabinet of decisions with the explanations torn out. Third, the structure: the epic/story/sub-task hierarchy and the cross-issue links that encode dependencies and duplicates. Fourth — and most underrated — the identifiers: the ENG-1234 keys that external systems point at.

Naming these explicitly does two useful things. It tells you what a successful migration looks like, so you can verify it instead of hoping. And it surfaces the history you can safely leave behind — the noise that feels precious but isn't. Nobody needs the fourteen status transitions on a ticket from 2021. Carrying everything is how migrations stall; carrying what's load-bearing is how they finish.

Export everything, not just the open issues

The most common migration mistake is exporting only the active backlog because it's smaller and feels like the part that matters. It's a trap. The closed issues are where your institutional memory lives — the bug that explains a weird workaround, the spike that justified an architecture choice, the feature request you've now been asked about three times. Export the full history: every project, every status, all fields. In Jira that's Issues → Export → CSV with all fields selected, run per project so the export doesn't truncate.

Pull the comments too, which the default CSV handles as additional columns, and confirm the export includes the parent/epic link fields — those columns are how the hierarchy survives the trip. If your Jira has custom fields you genuinely use, note which ones; they'll map to labels or typed fields on the other side, and knowing the list in advance turns the import preview from a guessing game into a confirmation. The goal of this step is a complete, boring artifact: a set of CSVs that contain everything, so the import has everything to work with.

Keep your issue keys so external links survive

Here's the detail that makes or breaks whether the migration feels lossless: the keys. Every ENG-1234 in a merged pull request, a Slack thread, a Confluence page, or a customer email is a hard-coded pointer into your old tracker. Change the keys and all of those become dangling references — technically the issue still exists, but nobody can get to it from where they actually look. The history is preserved and simultaneously unreachable, which is the worst of both worlds.

So preserve them. In Planoda, create a team per Jira project and keep the existing project key, so an imported issue keeps the identifier it had. ENG-1234 in Jira becomes ENG-1234 here, and every old link resolves to the migrated issue. This single decision is the difference between a migration your team feels as continuity and one they feel as a rupture — the issues are all there either way, but only one version lets people find them the way they already know how.

Map the fields once, then let the importer do the work

With complete CSVs in hand, the import is mostly a mapping exercise, and it's worth doing carefully rather than fast. Jira issue types map to Planoda issue types; statuses map to workflow states; priorities and assignees map directly. The epic/story/sub-task hierarchy maps to parent issues and sub-issues, and the cross-issue links — blocks, duplicates, relates-to — come across as the equivalent relationships so dependencies aren't flattened into prose. Custom fields map to labels or typed issue fields. The importer auto-suggests most of this from the column names; your job is to review the preview and correct the handful it can't infer.

Treat the preview as the real migration, not a formality. It's the one moment where you see exactly how the old model lands in the new one before anything is committed, and a five-minute review here saves a week of 'why did all our P2s become P3s' later. Confirm the status mapping especially — it's where teams' subtle, undocumented workflow conventions hide, and where a wrong mapping quietly mis-sorts the entire backlog. Once the mapping is right, the importer brings issues, comments, hierarchy, and links across in a single pass.

Cut over a team at a time, not all at once

Even with a clean import, a big-bang cutover where the whole org switches on a Monday is asking for trouble. The healthier pattern is to migrate one team at a time. Import that team's projects, let them work in Planoda for a full cycle, and keep the Jira project read-only as a safety net rather than deleting it. A single team is small enough to support closely, surfaces any mapping issues while they're cheap to fix, and produces the internal reference — 'the platform team moved and it went fine' — that makes the next team's move a non-event instead of a fight.

During this window, point your Git provider at Planoda so new PRs link to the migrated issues, while old PRs still resolve through the preserved keys. The two states coexist cleanly because the keys are shared. When the team has worked a cycle without reaching back into Jira, archive the Jira project — and notice that you're archiving, not deleting in a panic, because everything that mattered already came across and you verified it did.

Verify against the questions, not the row count

The last step is the one teams skip and then regret: actually verifying the migration answered the questions the old system could. Row counts are necessary but not sufficient — the right number of issues with the wrong mapping is still a broken migration. Instead, verify against real questions. Open a few closed issues from years ago and confirm the comment threads came across. Click an old PR's issue link and confirm it lands on the right migrated issue. Pull up an epic and confirm its children are still its children. Search for a term you know lived in an old ticket and confirm it surfaces.

If those spot checks pass, you haven't just moved your data — you've moved your memory, which is the whole point. The fear that keeps teams on Jira is the fear of arriving somewhere new and not being able to find anything they used to know. A migration that preserves the issues, the discussion, the structure, and the keys, and that you've verified by asking it the questions you used to ask Jira, dissolves that fear completely. You don't lose your history. You just stop paying the tool that held it hostage.