How to migrate from Jira without losing your history

What actually transfers

A migration is only useful if the context survives it. An import that brings issue titles but drops the comment thread explaining why a decision was made has moved your tickets and lost your history.

• Issues and subtasks, with their descriptions converted from Atlassian document format to Markdown.
• Comments, including their authors and threading.
• Epic links — the parent relationship is read from both the modern `parent` field and the older epic-link custom field, so both next-gen and classic projects resolve correctly.
• Attachments, downloaded as real binaries rather than linked back to Atlassian.
• Inline images embedded inside descriptions and comments, rewritten to point at your own storage.
• Workflow statuses, so the board you land on resembles the board you left.

How the import runs

You connect your Atlassian instance, select one or more projects, and start the import. Progress streams back live over the same request as it runs — phase by phase, with counts — rather than leaving you watching a spinner and guessing whether it is stuck.

Multiple projects can be selected and imported in one pass, so a migration is not a per-project ritual repeated twenty times.

What happens to people who are not in SPIREX yet

This is the part most migrations handle badly. Your Jira history is full of authors and assignees who do not have a SPIREX account — some of whom have left the company entirely. Dropping those names loses attribution; blocking the import until everyone signs up makes migration impossible.

SPIREX creates a placeholder user for each unmatched Jira account so authorship and assignment survive the import intact. When the real person joins later, you link the placeholder to their account and the historical references are reassigned to them.

Where an imported name closely matches an existing member, the import flags it so you can confirm the match rather than having the tool guess and quietly merge two different people.

What does not come across

An honest list, so nothing is a surprise on migration day. Jira automation rules, marketplace-app data, dashboards and filters, and Jira-specific configuration such as screens and permission schemes are not imported — those are Jira constructs without a SPIREX equivalent.

Plan for workflows and reporting views to be re-established on the SPIREX side. The work items and their history come across; the surrounding Jira administration does not.

A migration plan that does not require a big-bang cutover

You do not have to move everything at once, and you should not.

• Import one representative project into a free workspace first — ideally a noisy one with attachments, long comment threads and a custom workflow.
• Check the things you would actually miss: epic hierarchy, inline images inside descriptions, comment authorship, status names.
• Run one full sprint on it in parallel with Jira. Two weeks of real use answers questions no evaluation checklist can.
• Link placeholder users to real accounts as your team signs up, so attribution resolves as people arrive.
• Migrate the remaining projects once you trust the result, and keep Jira read-only for a while rather than cancelling it the same day.