Migrating from Linear to Radial: export to JSON, then radial import --from linear

Most people who search "migrate from linear" are not leaving because Linear is slow or badly built. It is neither. They are leaving because something about the shape of the tool stopped fitting: the seat math as the team grew, the AI features arriving whether they were asked for or not, or simply the pull toward a tracker their agents can drive without a per-vendor integration for each one. The decision is the hard part. The data move should not be.

For Radial, the data move is an export and an import. You export your Linear issues to JSON through Linear's GraphQL API (paged), dry-run radial import --from linear 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 Linear JSON export on disk:

npm i -g radial.build
radial import --from linear 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 linear export.json -t ENG

Issues keep the Linear team key from the export when it is present; -t ENG puts the rest on your ENG team.

#What actually comes across

From Linear, the import brings:

• Titles and descriptions (markdown).
• Statuses, matched by name, then by category.
• Priorities, estimates and due dates.
• Assignees, matched by email to a workspace member. An email with no matching member is left unassigned, with a warning.
• Labels and projects, created as needed (the dry run tells you how many labels are new).
• Parent issues and relations (blocks, related, duplicate).
• Comments, with their original timestamps.
• Created and updated timestamps (except the updated time on sub-issues: linking the parent sets it to the import time).

What does not come across: attachments, cycles, 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 linear 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 several teams, do them one file at a time and check each summary.

#What changes, and what stays the same

The fair thing to do in a migration guide is tell you what you are giving up, not just what you are gaining.

What stays the same. The core loop you are used to in Linear is the core loop in Radial: a keyboard-first board and list, issues with statuses and priorities and estimates, projects, and time-boxed cycles. Cycles themselves do not migrate, so recreate the current one by hand.

What you give up. Radial does not have Linear's full surface area. There is no roadmap or initiative timeline, no built-in insights or velocity dashboards, no Linear Asks-style intake from Slack, and the ecosystem of third-party integrations is smaller. If your team runs on Linear's roadmap and analytics views, that is a real gap to weigh before you export. Better to know now than to find out after.

What changes, if the bill was the reason. The most common thing people wire into a modern tracker is an agent, and a common thing that breaks is cost. A builder in r/Linear put it plainly while comparing agent-delegation setups: the biggest pain point is cost. Radial's answer is structural, not a discount. Agent members are not billed as seats, so your agents add nothing to the bill. And the price you pay is one flat number: $50 per user, per year, billed annually. No AI credit balance, no usage meter, no overage line, because there is no AI in the product to meter.

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. One surface, any agent, no per-vendor integration to bolt on for each new one.

#FAQ

#How do I export my data from Linear?

Page through Linear's GraphQL API and save the issues, with their labels, comments and relations, as one JSON file. Linear's built-in export (Settings, Administration, Import/Export) is CSV, which the importer does not read. Once you have the JSON file, run radial import --from linear 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.

#Does Radial have a CLI to run the migration?

Yes, and the CLI is how the migration runs. radial import --from linear is a first-party command, not a community wrapper. Linear has no official issue-management CLI (there are community CLIs and a GraphQL API), so if a terminal-native workflow is part of why you are switching, that is a real difference. See the Linear CLI Linear never shipped for the fuller story.

#Will I lose my comments and timestamps?

No. Comments come across with their original dates, and issues keep their original created dates and their relations. 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.

#Is Radial just a cheaper Linear?

No, and it is worth being precise: there are trackers cheaper than Radial, and Linear is an excellent tool. The difference is not the number, it is the shape. Radial is one flat price with agents not billed as seats and a pledge that pays you if AI billing ever shows up, versus a per-seat plan with an AI layer that can grow. Pick by what made you leave, not by which line item is smaller. We lay out the side-by-side in Radial vs Linear.

#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 Linear issues to JSON, dry-run radial import --from linear, then import. Issues, projects, statuses, priorities, assignees, labels, estimates, parents, relations, comments and timestamps come across. Attachments, cycles, custom fields and history do not. What you migrate into keeps the core loop, drops the surface you did not use, and holds one flat price with agents not billed as seats.

See the one number on pricing, or read Radial vs Linear for the full comparison before you export.