What Actually Survives a Jira Migration
Every migration vendor writes about what its tool carries. None of them write about what all of them drop. Here's the pattern, in three vendors' own published words — plus GForge, held to the same table.
New here? Start with the full lock-in audit for the complete picture, including app-locked data and structural coupling. This page is the single question at the center of it: what transfers, and what doesn't.
The Same Hole, Three Different Vendors
JetBrains' YouTrack migrator is, by its own documentation, the most capable Jira migration tool currently published. OpenProject's is the nearest open-source equivalent, still in beta four months after its last update. Cotera's account of moving 2,147 issues to Linear is a real customer's migration, not a vendor's pitch. Three different architectures, three different companies, and the same result: issues, comments, attachments, and history move. Workflows, permission schemes, boards, dashboards, saved filters, automation rules, and plugin configuration mostly don't — they get manually rebuilt, if anyone rebuilds them at all.
That isn't a knock on any one tool. It's the shape of the category. Nobody writes about it because every vendor's incentive is to describe what their importer carries, not what it drops — so the buyer currently has nowhere to read the honest version. This page is that version, and it names names, including ours.
The Comparison, in Their Own Words
Every claim below is sourced to the vendor's own published documentation or a customer's own published account — see Sources. carries partial rebuild from scratch
| What you're moving | JetBrains YouTrack | OpenProject (beta) | Cotera → Linear | GForge Next |
|---|---|---|---|---|
| Issues, comments, attachments, history | Issues, custom fields, comments, attachments, and history move, per JetBrains' own guide. | Migrator is still beta — “we do not recommend using it in production environments.” Only text, number, date, and select-list custom fields; relations, identifiers, and sprint assignments are marked “coming soon.” | 2,147 issues moved to Linear, but time tracking was abandoned outright in the move. | Issues, comments, attachments, history, users, and worklogs transfer. |
| Workflows (statuses, transitions) | “Workflows” are named explicitly in JetBrains' own list of what requires manual recreation. | “Project-level workflows, permissions and schemas” are marked coming later — not yet in the beta migrator. | 14 custom workflows collapsed to 4 in the destination. | Statuses and transitions port automatically. Conditions, validators, and post-functions bolted onto them still don't — same as everyone here. |
| Permission schemes | Not in JetBrains' carries list; falls under manual recreation. | Explicitly named alongside workflows as “coming later.” | “Transition-level permissions lost outright,” per Cotera's own account. | Rebuilt by GForge's migration team as part of the engagement, not auto-ported. No better, no worse. |
| Boards, dashboards, roadmaps | “Boards, reports, dashboards, roadmaps” named explicitly as manual-recreation items. | Not reached by the migrator; only field-level data is in scope so far. | Not itemized in Cotera's published account beyond the workflow and filter losses. | Rebuilt by GForge's migration team, same as the others on this table. |
| Saved filters / saved queries | Not carried; JetBrains' list doesn't include JQL or saved-filter migration. | Not in scope for the current beta migrator. | 23 saved JQL filters moved, but 5 were unreplicable in Linear's query model. | Saved filters translate automatically to GForge's query layer. |
| Automation rules | “Automations” named explicitly as a manual-recreation item. | Not in scope for the current beta migrator. | Not reported as carried in Cotera's account. | Rebuilt by GForge's migration team, same as the others on this table. |
| Plugin / third-party app configuration | “Jira plugins need individual assessment” — no blanket claim of support. | “Advanced custom fields, or plugin-based configurations, are not yet fully supported.” | Not addressed as a carried category. | Assessed app-by-app during the migration engagement, same as every vendor on this table — there's no universal plugin-export format to build against. |
GForge doesn't clear this table by much. Two rows carry automatically — workflows' statuses and transitions, and saved filters. Permission schemes, boards, dashboards, automation rules, and plugin configuration are rebuilt by GForge's migration team as part of the engagement, exactly like the other three. If a page claiming otherwise shows up anywhere, distrust it — including this one, if the product changes and this table doesn't get updated.
Sizing the Rebuild, Not the Export
The export is never the hard part — every serious destination has an importer for issues, comments, and users. The migration timeline is set by the configuration layer, because that has to be rebuilt by a person who understands why it exists. Four counts to run against your own instance before you estimate a timeline:
- Workflows and their bolted-on behavior. Count transitions that exist only to gate a condition or validator, and statuses that exist only for routing. That number is the configuration debt you'll carry into any destination — Cotera's real-world number was 14 workflows collapsing to 4.
- Saved filters and dashboards in active use. Not every saved filter needs to survive — most instances accumulate filters with zero viewers. Count the ones people actually open. Cotera moved 23 and found 5 unreplicable in the destination's query model; expect a similar ratio, not zero losses.
- Permission and notification scheme complexity. Years of accumulated who-can-see-what rarely map cleanly onto another tool's model. Most teams rebuild simpler, which is often an improvement — but it's a decision to make deliberately, not a default that happens to you mid-migration.
- Automation rules and what each one is actually for. Rules are faster to recreate than scripts, but only after someone documents what each is supposed to do — and instances routinely accumulate hundreds, many of them dead.
This is the same audit whether you're moving to Cloud, to an open-source tool, to Linear, or to GForge. It's worth running even if you decide to stay put — the number it produces is your actual switching cost, and knowing it changes how the next renewal conversation goes.
Related Reading
- The full lock-in audit — app-locked data, structural coupling, and a 2-minute estimator →
- Chapter 1: when your own renewal quote actually arrives →
- What Jira, Confluence, and Data Center actually cost a 100-person team →
- Once you know what breaks, here's how to actually run the move — the GForge Jira migration guide →
Know What You'd Rebuild. Then Price It.
The table above tells you what kind of rebuild you're facing. The sizing tool puts your actual Atlassian footprint next to what it would cost elsewhere — GForge included, same rules as everyone else.
Size My InstanceSources
- How to Migrate from Atlassian Jira and Confluence to YouTrack — JetBrains (updated 9 Sept 2026)
- OpenProject 17.4 Release — OpenProject (13 May 2026)
- Jira Migrator: custom field support — OpenProject (11 May 2026)
- Linear vs. Jira: a real migration account — Cotera (8 March 2026)
Compiled September 2026. Every quotation from a third party is verbatim from the linked source. Revisit this page whenever any named migrator ships workflow, permission, or scheme support — that's the event that dates it.