How to migrate from Jira without losing your sprint history

Most Jira migrations fail in the same place: someone exports a CSV, imports it, and discovers that estimates, sprint membership and parent links did not come across. Here is the field-by-field mapping that works, and the four things that genuinely cannot be preserved.

Export properly

Do not use the default CSV export. Use Issues → Export → Export Excel CSV (all fields), or better, pull from the REST API with /rest/api/3/search?jql=project=ABC&expand=changelog and page through it. The changelog is what lets you reconstruct status transition dates, and therefore cycle time.

The mapping that matters

• Issue type → task type. Epic becomes a parent task with the epic flag. Story, Task and Bug become tasks with a type field. Sub-task becomes a subtask.
• Epic Link → parent_id. Do this in a second pass, after all issues exist, or half your links will point at nothing.
• Status → status, and status category → category. Map to todo, in_progress, done or cancelled. Getting the category right is what makes reporting work afterwards.
• Story Points → points. The field ID is usually customfield_10016; confirm it in your instance.
• Original Estimate / Time Spent → estimated_hours / actual_minutes. Jira stores seconds. Divide.
• Sprint → sprint. The sprint field is an array; an issue that moved between sprints lists all of them. Take the last for current membership and keep the full array if you care about carry-over analysis.
• Issue links → dependencies. "blocks"/"is blocked by" become finish-to-start dependencies. "relates to" becomes a plain relation, not a schedule constraint — do not turn every relation into a dependency or your Gantt will be unusable.
• Comments → comments, preserving author and timestamp. Map Jira's wiki markup to HTML; the common cases are headings, lists, code blocks and {{monospace}}.
• Attachments → attachments. Download with an authenticated request; the URLs in the export are not public.

What does not survive, honestly

1. Workflow schemes with conditions and validators. A status graph with post-functions is Jira-specific. Rebuild the intent as automations — usually two or three rules replace a whole workflow scheme.
2. Permission schemes at issue-security level. Map to project roles and private tasks instead.
3. Marketplace app data. Anything living in an app's own tables is gone unless that app has its own export.
4. Exact historical burndown. You can reconstruct a good approximation from the changelog, but the numbers will differ slightly from Jira's cached reports. Keep a read-only Jira instance for one quarter if audit history matters.

A migration plan that does not blow up

Pick one finished project and import it. Verify counts: issues, comments, attachments, points totals. Then import one active project and run both tools in parallel for a single sprint, with a rule that all new work starts in the new tool. At the end of the sprint, make Jira read-only. Do not attempt a big-bang cutover across twelve projects on a Friday.

Budget half a day for a small instance, two to three days for a few hundred issues with attachments, and a week if you have custom fields nobody can explain.

---