Backlog migration without losing what makes it work

Stefan-Iulian Tesoi · 24 September 2026 · 6 min read

Move the next two sprints properly and leave the rest where it is. The items you will actually work on need their criteria rewritten before an agent can act on them, work no importer does, and everything older is reference material cheaper to search than to move.

That is the whole recommendation, and it is unpopular because a backlog migration feels like a data problem. Moving tickets between tools is the half that works. What does not survive the trip is the part nobody thinks to check until a month later.

What does a backlog migration actually move?

Three layers, and importers handle exactly one of them well.

The first is records: titles, descriptions, comments, attachments, assignees, dates. These transfer reliably, and it is what a migration tool is demonstrating when it reports 4,000 issues moved successfully.

The second is structure: epics, milestones, dependency links, sprint membership. Some maps, most approximates, and the approximations are silent.

The third has no field. It is why this item sits above that one, which criterion the team argued about, what "done" meant to whoever wrote it. It was never stored, so nothing can move it. A migration reporting complete success has, accurately, moved everything that existed as data.

An importer moves rows. The reason those rows were in that order lived in a standup, and the standup is not in the export.

Why is importing everything the expensive option?

Because the cost of a migration is in review, not transfer, and a large import maximises review while making it feel unnecessary.

Four thousand imported issues look like a completed project management migration. What you have is four thousand items nobody has read, in a structure approximating the old one, carrying the thin descriptions that made the old backlog hard to work from. The tool changed, the problem did not, and the import disguised it.

Worse, it spends the one opportunity a move creates. A migration is the only moment anyone has a legitimate reason to reread every active item and ask whether it is still worth doing. Importing skips that question wholesale.

The arithmetic is not close. Rewriting an item properly takes fifteen to thirty minutes, so the twenty to forty items in two sprints cost one or two days of one person's attention. Reviewing four thousand imported items at two minutes each is a fortnight, and nobody does it, which is why imported backlogs stay unread.

What does an automated import silently drop?

The parts that were carrying meaning rather than data. Each of these transfers as something, which is why it goes unnoticed.

Six specifics worth checking on the other side, because each has bitten a team that assumed otherwise.

• Custom statuses collapse. "Blocked — external", "Ready for QA" and "Awaiting UAT" all land as In Progress. The distinction was the information, and it is gone rather than wrong.
• Transition history usually does not come. You get the current state without how it got there, so "why is this a P1" is unanswerable by anyone who was not in the room.
• Issue links flatten. Blocks, is-blocked-by and duplicates arrive as plain text or not at all. Sequencing is what a dependency graph was for.
• Comments arrive as a flat list. The decision is in there, unmarked, which is the same as absent once the thread runs two hundred lines.
• Custom fields land in the description. The acceptance-criteria field a team disciplined itself into using becomes a paragraph, and a structured backlog is prose again.
• Story points keep their numbers and lose their meaning. A 3 was a 3 relative to a history of threes that did not travel.

Atlassian's own CSV import documentation is clear that a mapping step exists, and mapping is where all six are decided — usually by whoever is clicking, without the people whose meaning is being mapped.

How do you run a two-sprint migration?

One team, one fortnight, a rewrite rather than an import. Six steps, in order.

1. Pick one team and freeze the scope. The current sprint and the next. Not the roadmap, not the other squads, not the epics nobody has touched since spring.
2. Recreate the structure by hand first. Epics and milestones are few — usually five to fifteen — and the meaning is densest there. Typing them out takes an hour and forces someone to say what each is for.
3. Rewrite each active item, do not paste it. Write a new one with criteria someone outside the discussion could check. If it cannot be written that way the item was not ready, and discovering that now is the point.
4. Carry the old key in the new item. Put PROJ-1234 in the text: old commits and documents reference it, and a searchable string costs nothing.
5. Stop new items in the old tool on a stated date. Two trackers accepting work is how a migration lasts nine months. Read access stays, write access ends.
6. Run one full sprint before moving anyone else. The second sprint is where the first one's shortcuts surface.

Laimonade has no importer, and that is the position rather than a gap in the roadmap: setup is a conversation about what you are building, from which the roadmap and first items are drafted. It is a real constraint, and a team that wants its history inside the new tool should weigh it seriously. Setup is described in getting started, connections in integrations, and the reasoning in what Laimonade is.

What should happen to the archive?

Leave it readable and stop writing to it. An archive is a search target, not a backlog, and the two want different things.

Closed work is consulted a few times a year, by one person, looking for one thing. That pattern does not justify a migration, and it is well served by the old system in read-only mode or a flat export kept somewhere searchable. Whether to migrate from Jira wholesale is largely a question about this archive, and for most teams the honest answer is that they would be paying to move records they will open twice.

The exception is regulated work, where an auditor has seen a system and expects to see it again. That is a different decision from where active work lives, and choosing between destinations is the subject of Jira alternatives when an agent reads your backlog.

Frequently asked questions

Can you run two trackers in parallel during migration?

For reading, yes; for writing, only briefly. Two systems accepting new work means two backlogs disagreeing about what exists, and the disagreement compounds daily. Set a date after which nothing new is created in the old tool, keep it readable, and accept a fortnight of awkwardness over a year of ambiguity.

What happens to ticket links in old commits?

They break as links and survive as strings, which is enough. A repository with years of history can carry thousands of PROJ-1234 references, and rewriting history to update them is far worse than leaving it. Put the old key in the new item so a search finds it, and keep the old tracker readable.

Should epics and milestones be recreated by hand?

Yes, and it is the step people try hardest to automate. There are rarely more than fifteen, they take about an hour, and typing them forces someone to state what each is for. An imported epic arrives with its name and none of its intent, which is how a roadmap becomes folders.

How long should a backlog migration take?

Two sprints of elapsed time and one or two days of concentrated work, for one team. An estimate in weeks of effort means the scope has grown to include the archive. An estimate in hours means items are being pasted rather than rewritten, and the new tool is about to inherit the old backlog's problems.