Migrate from Jira: Export Issues, Keep Engineering Intact

Most teams that say they are leaving Jira are not. They are moving delivery planning, the dates, dependencies and portfolio view, out of a tool built to track tickets, while engineering keeps working in it.

To migrate from Jira, export the issues you want as CSV and import the file into Onplana as a spreadsheet. Jira Cloud supports exporting up to 10,000 work items at a time from the issue navigator (Atlassian export guidance, checked 2026-10-03), and Onplana's import wizard reads Excel and CSV files up to 50 MB.

The direct answer: A Jira migration is a scoping decision followed by a CSV import. Decide which issues are delivery plan and which are engineering work, export only the first group, and import it as a spreadsheet. Comments, attachments, workflows and issue history are not rows, so they do not travel as a project; keep Jira readable for them.

Should you coexist with Jira or replace it?

Coexistence is the common case and the lower-risk one. Choose by what the work needs, not by licence count.

Pattern	When it fits	What you export	Boundary
Coexist	Engineering works tickets; delivery needs dates and a portfolio view	Epics and milestone-level issues	Re-export on purpose; there is no live sync
Replace	The team never used Jira for engineering	Every open issue in scope	Jira goes read-only after a parallel run
Archive and start fresh	Years of closed issues nobody reads	Only open work	Keep Jira for history

Coexistence needs one rule written down: which tool owns the dates. Without it, two tools carry two schedules, and they will disagree within a sprint. The Onplana vs Jira comparison and the Jira plus Confluence comparison cover where each earns its place.

What does a Jira CSV export carry?

The export is a flat table of issue fields. Atlassian's CSV export guide describes the all-fields option, which adds each comment as its own column.

Jira item	In the CSV?	On import	Your action
Summary, status, assignee, dates	Yes	Arrive as columns	Map to name, status, owner, dates
Parent or epic link	Check your file	A parent column can rebuild hierarchy	Confirm the tree in the preview
Comments	With all fields, one column each	Not imported as comments	Copy out threads that matter
Attachments	Links only	Not imported	Download what you need to keep
Issue links, sprints	Check your file	Predecessors read by row number if present	Redraw links in the Gantt
Workflows, automation	No, behaviour	Not imported	Rebuild only what is still used

How do you migrate from Jira step by step?

Scope the export with a filter. Write a query for the delivery-plan issues only. A narrow filter keeps you under the 10,000-item limit and avoids the slow all-fields export Atlassian warns about for large sets.
Export as CSV from the issue list through the more-actions menu.
Import the file through the spreadsheet wizard, which reports each repair against its source row. The Excel and CSV import guide lists the signals it reads.
Check the result against the export. Compare the row count, hierarchy, dates and owners, line by line for the first project.
Run both for a short period, with Jira read-only for the migrated scope, as the switching guide describes.

What does not transfer from Jira?

Workflows, automation rules, boards and issue history stay in Jira, because none of them is a row. History is the one that matters later: a CSV is a snapshot, so if an audit or a postmortem may need who changed what, keep Jira readable instead of exporting it away.

Over 10,000 issues is a planning problem, not a blocker. Split by project, date range or status, export each batch and import them as separate projects.

Is Onplana the right destination?

If your Jira epics are really projects with dates and dependencies, the move gains a Gantt and a critical path on every plan including Free (read from src/lib/plans.ts, 2026-10-03). If the work is sprint-by-sprint engineering, Jira is built for it, and the Jira Plans comparison is candid about the overlap. The migration hub covers moving schedule files from other tools.

Start with one project. The Free plan allows 5 members and 2 projects, which is enough to import a real export and judge it before you move a team.

Frequently asked questions

How do I migrate from Jira to Onplana?

Export the issues you want from Jira as CSV, then import the file into Onplana as a spreadsheet. The wizard reads .xlsx and .csv up to 50 MB, so the decision that matters is which issues are delivery plan and which stay in Jira.

Do I have to leave Jira completely?

No, and many teams should not. A common pattern is to plan delivery in Onplana while engineering keeps working tickets in Jira. The boundary is whatever you export and import on purpose, because Onplana has no live Jira sync.

How many issues can Jira export at once?

Jira Cloud supports exporting up to 10,000 work items at a time from the issue navigator. For more, split the results with JQL by project, date range or status, export each batch, and merge the files.

Does Jira issue history come across?

Treat it as staying behind. A CSV is a snapshot of each issue's fields, and the all-fields export adds one column per comment, but it is not a changelog. Keep Jira readable for anything an audit might ask.

Do Jira attachments transfer?

Not as files. Atlassian notes that Jira Cloud does not natively support downloading attachments in bulk, though the CSV can carry attachment links. Download what you need to keep before you archive.

Is there a one-click Jira importer in Onplana?

No. The route is Jira's CSV export through Onplana's spreadsheet import, which is the same pipeline used for .mpp and XML. It is slower than a connector, but you can check every row before importing.

Can I test the migration first?

Yes. Export one project's issues and import them. Onplana's Free plan allows 5 members and 2 projects, enough to judge a real export, and importing changes nothing in Jira.