How to Migrate from Jira, Trello or Linear Without Retyping Your Backlog

The Real Reason Migrations Fail

Almost nobody abandons a tool migration because the import didn't work. They abandon it because they tried to bring everything across, spent two weeks recreating the exact structure of the tool they were trying to escape, and ended up with the same mess in a new interface.

The mechanical part - getting rows from one system into another - is a couple of hours. The part that decides whether the migration succeeds is what you choose not to bring. This guide covers both, but the second one matters more.

What FlowBoard Can Import

From Settings → Import, FlowBoard takes tasks from Jira, Trello, Linear, Notion and any CSV or JSON export, up to 10MB per file. Nothing is hard-wired to a particular vendor - you map the columns yourself, so any tool that produces a CSV with a header row works.

There's also a Paste Text List mode: paste a plain bullet list and every line becomes a task. It's easy to miss and worth knowing about, because plenty of backlogs don't live in a tool at all - they live in a meeting note or a Slack thread, and those don't need converting to CSV first.

The importer gives you four things:

• Field mapping - decide which source column becomes which FlowBoard field
• Row filters - contains, equals, starts with, ends with, greater than, less than
• Destination choice - a specific flow, the Ideas Board, or the Bugs Board
• Duplicate detection - incoming rows are scored against existing tasks, and you choose skip, update or create for each match

That last one is what makes the whole thing low-risk. A first attempt with the wrong mapping isn't a disaster; fix it and run the same file again without doubling your board.

Step 1: Decide What Not to Bring

Do this before you export anything. The default instinct - "migrate everything, we might need it" - is what produces a new tool that's as unusable as the old one on day one.

Leave behind:

• Closed and completed work. Years of done tickets add weight and no value. The old tool keeps the history; make it read-only rather than deleting it.
• Custom fields nobody fills in. Every team has half a dozen. Migration is the one moment you can drop them without a meeting.
• Statuses you invented and stopped using. Map them onto FlowBoard's actual statuses instead of recreating a nine-column workflow.
• Anything in a project that's effectively dead. If it hasn't moved in a year, it isn't a backlog, it's an archive.

A useful test: if a task has been open for more than a year and nobody has commented on it, importing it is a decision to look at it again. Usually it isn't.

Step 2: Export

• Jira: run a filter for the issues you want and export the results to CSV. Jira's export carries far more columns than you need - that's fine, unmapped columns are ignored.
• Trello: export a board to CSV or JSON. Your lists usually become either status or tags - decide which before you map.
• Linear: export issues to CSV.
• Anything else: any CSV with a header row.

If your export mixes bugs, feature requests and actual work items, split the file first. Each import targets one destination, and separating them at the file level is far less painful than untangling them on the board afterwards.

Step 3: Set Up FlowBoard First

Importing into an empty workspace produces a pile. Importing into a shape produces a backlog. Before your first real import:

• Create your flows - usually one per product area or client, not one per Jira project
• Decide your tag vocabulary, so imported labels land somewhere sensible
• Set your priority formula
• Invite the people who'll be assignees, so assignee mapping resolves

Step 4: Map the Fields

Match each source column to a FlowBoard field - title, description, assignee, status, type, estimate, tags. The usual mappings:

• Jira Summary → title, Description → description, Story Points → estimate
• Trello Card Name → title, List → status or tag, Labels → tags
• Linear Title → title, Estimate → estimate, Labels → tags

Anything you don't map is dropped, and dropping is usually correct. Most teams migrating are carrying fields they stopped caring about years ago, and faithfully importing them recreates the clutter they were trying to leave.

Step 5: Give Everything a Priority Score

This is the step people skip, and it's the one that determines whether the new board is actually better.

FlowBoard sorts a single backlog by a priority score computed from impact, client demand and technical ease. Your export contains none of those, because no other tool tracks them. So you supply defaults at import time and every incoming task arrives with a valid score.

Give everything the same middling defaults. Yes, that means everything starts equal - which sounds useless, but a backlog where everything scores the same is still more useful than one where nothing scores at all, because the machinery works and you can fix items individually. Then re-rank the top thirty by hand. You will never work the bottom two hundred, so scoring them precisely is wasted effort.

Step 6: Trial Run, Then the Rest

1. Import one project's open work
2. Open twenty tasks and check the mapping actually landed where you expected
3. Fix the mapping if it didn't, and re-import - duplicate detection makes this safe
4. Import the remaining projects
5. Re-rank the top of the backlog
6. Leave the old tool read-only for a few months

Resist running both tools in parallel for long. Two weeks is a sensible overlap. Three months of dual-entry is how migrations die - people keep updating the old tool because it's where the history is, and the new one never becomes real.

What Doesn't Come Across

Set expectations before you start, because these are the surprises that cause complaints:

• Comment threads and attachments. The exports mostly don't contain them. This is the main reason to keep the old tool readable.
• Rich formatting. Jira and Notion flatten their own descriptions on export; there's nothing on the receiving end that can restore it.
• Deep hierarchies. FlowBoard has one level of subtasks. An epic-story-subtask tree needs a decision: epics usually become tags or flows, stories become tasks.
• Sprints. There's nothing to map them to, by design. If you're keeping sprints, you're migrating to the wrong tool.

The Honest Version

A migration is a rare licence to throw things away. The mechanics take an afternoon; the value comes from the decisions you make while doing it. Teams that import 800 tickets to be safe end up exactly where they started. Teams that import 120 and delete the rest get the fresh start they were actually after.

Get started with FlowBoard, or see how it compares to Jira and Trello.

Frequently Asked Questions

Can I import my Jira issues into FlowBoard?

Yes. Export your Jira issues to CSV and import under Settings → Import, mapping Jira's columns onto FlowBoard fields. You can filter which rows come across and send them to a flow, the Ideas Board or the Bugs Board.

What file formats does the importer accept?

CSV and JSON, up to 10MB per file. Larger backlogs can be split across several imports.

What if I get the field mapping wrong?

Fix it and import the same file again. Incoming rows are checked against existing tasks and likely duplicates are flagged, so you choose skip, update or create rather than ending up with two copies of everything.

Will my comments and attachments transfer?

No - the exports from most tools don't include them. Keep the old tool in read-only mode and link to it from task descriptions if you need the history.

How long does a migration take?

The import itself is minutes. Deciding what to bring, setting up flows and tags, and re-ranking the top of the backlog is where the time goes - budget a day for a mid-sized team, most of it spent deleting things.