Migrating off Jira: export to JSON, then radial import --from jira

Most Jira migration guides are about moving from one Jira to another: Server or Data Center to Cloud, run the Jira Cloud Migration Assistant, plan the maintenance window, pre-load users. That is a real project, and Atlassian's tooling handles it. This guide is about the other migration: the one where you are leaving Jira for a focused tracker and the only thing standing between you and the switch is your data.

For Radial, that part is an export and an import. You export your Jira issues to JSON through Jira's REST search API (paged), dry-run radial import --from jira against the file to see counts and warnings, then run it again without --dry-run. It is one import command after the export, not one command end to end.

#The short version

With a Jira JSON export on disk:

npm i -g radial.build
radial import --from jira export.json --dry-run

The --dry-run flag does everything except write. It reports how many issues it would create, how many would fail, and the new labels and projects it would build, and it surfaces warnings for anything it cannot map cleanly. When the dry run looks right, drop the flag and run it for real:

radial import --from jira export.json -t ENG

The -t ENG puts the imported issues on your ENG team. Jira projects are not mapped, so every issue in the file lands in the team you pass.

#What actually comes across

From Jira, the import brings:

• Titles and descriptions. Descriptions in Atlassian Document Format are flattened to plain text.
• Statuses, matched by name, then by status category.
• Priorities. Highest becomes urgent, Lowest becomes low.
• Assignees, matched by email to a workspace member. An email with no matching member is left unassigned, with a warning.
• Labels, created as needed (the dry run tells you how many are new).
• Parent issues and issue links (blocks, duplicate, related).
• Comments, flattened to plain text, with their original timestamps.
• Due dates, created timestamps, and updated timestamps (except on sub-issues: linking the parent sets their updated time to the import time).

What does not come across: Jira projects and story points, attachments, sprints, custom fields, change history, watchers, and comment authors (imported comments are posted under the importing user's name).

When the run finishes, you get a one-line summary of what landed: issues created, any that failed, plus relations, comments, and new labels created, followed by up to ten warnings for anything that needed a judgment call. Because every command that returns data takes --json, you can also pipe that summary straight into a script if you are migrating several files in a loop:

radial import --from jira export.json --dry-run --json

One caveat worth stating up front: re-running the same file imports it again rather than reconciling, so there is no cross-run idempotency yet. Dry-run first, run once, verify. If you are moving many projects, do them one file at a time and check each summary.

#Why teams make this move, and why some shouldn't

People do not leave Jira because it is bad. They leave because they adopted it for engineering work and never needed its enterprise breadth, and the weight became a tax they pay every day. If a slow board and a workflow you configured for a week is your pain, a lighter tracker fixes it.

But the reason that the usual alternatives miss is the bill. Jira is per seat per month, and its AI layer, Rovo, ships a monthly credit allowance per seat with overage billing, and Rovo Dev is a further charge per developer. The subscription is the base; the AI is a meter. Switch to another per-seat-plus-meter tracker and you have changed the logo, not the trajectory.

Radial is a keyboard-first issue tracker priced at one flat number: $50 per user, per year, billed annually. There is no AI credit balance, no usage meter, and no overage line, because there is no AI in the product to meter. Agents are not billed as seats. The commitment behind that is the Plain Software Pledge, written down: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, we refund your subscription in full.

This is not anti-AI. Your agent doing real work is great. The point is that the tracker is not where that intelligence should live or get billed; it is the system of record your agent writes to over a real CLI, REST API, and MCP server.

A fair guide names the gaps, too. Radial does not have Jira's breadth: no portfolio or initiative layer, no burndown or velocity dashboards, no Gantt roadmap, no thousand-app marketplace, no cross-department workflow engine. If you run fifty teams with fifty workflows, Jira is built for that and Radial is not. Better to know before you export than to discover it after.

#FAQ

#What will replace Jira for my team?

There is no universal replacement, because teams leave Jira for different reasons. If the pain is speed, a focused tracker is the fix; if it is data ownership, the self-hosted field (Plane, OpenProject) is real; if it is the bill that keeps moving, you want a tool with one flat price and no AI meter. Pick by the reason you are leaving, not by whichever tool tops a listicle. We sorted the field in the best Jira alternative depends on what made you leave.

#How do I export my data from Jira?

Page through Jira's REST search API and save the issues, with their fields and comments, as one JSON file. Jira's built-in exports are CSV and XML, which the importer does not read. Once you have the JSON file, run radial import --from jira export.json --dry-run. The dry run reads the file and reports what it would create without writing anything, so you can confirm the mapping before the real run.

#Will I lose my comments and timestamps?

No. Comments come across as plain text with their original dates, and issues keep their original created dates. Updated dates are kept too, except on sub-issues: the importer links each parent in a second pass, and that write sets the sub-issue's updated time to the import time. Comment authors do not come across: imported comments are posted under the importing user's name. The field-by-field change history does not come across either. The dry-run summary counts issues, new labels and new projects, but not comments or relations (it reports 0 for both), so check those totals after the real run.

#Can my coding agent run the migration?

Yes. The import is available over the REST API (POST /v1/import) with a scoped API key, so an agent you authorize can run the move, or script it across several files. Agent members are not billed as seats, so wiring one up costs nothing extra. Once you are on Radial, your agent files, triages, and closes issues over the MCP server at mcp.radial.build too.

#The short version, again

Export your Jira issues to JSON, dry-run radial import --from jira, then import. Issues, statuses, priorities, assignees, labels, parents, links, comments and timestamps come across. Attachments, sprints, custom fields, history and Jira projects do not. What you migrate into is a tracker with one flat price, no AI meter, and a pledge that pays you if we ever add one.

See the one number on pricing, or read why is Jira so slow for the engineering reason the weight is not free.