May 21, 2026 · 8 min read
Moving from Jira without losing history
Our Jira importer is in private beta. Here's what comes over, what doesn't, and a checklist for switching a team without a lost week.
Switching tools is rarely blocked by the new tool. It's blocked by the fear of losing years of history in the old one. We built the Jira importer so that fear doesn't have to decide.
What comes over
- Projects, epics, issues, and subtasks
- Assignees and reporters, matched by email
- Statuses, mapped to TaskD columns
- Comments, attachments, and the full change history
- Start dates, due dates, and original estimates
- Issue links, turned into dependencies where the link type means "blocks"
What doesn't
- Custom workflows with transition rules. TaskD keeps the statuses; the rules stay in Jira.
- Marketplace app data stored outside Jira's own fields.
- Permission schemes. You'll set roles again in TaskD, which usually takes minutes.
A checklist that works
- Pick one project first. Choose an active one with a real deadline, not the oldest.
- Clean up statuses. If you have twelve statuses, decide which five you actually use. The importer maps the rest.
- Run the import on a Friday. The importer is read-only, so Jira keeps working while it runs.
- Set start dates. Jira issues often have only a due date. TaskD will suggest start dates from estimates; review them once.
- Work in TaskD for a week. Keep Jira open read-only. Most teams stop opening it by Wednesday.
- Move the rest. Import remaining projects together, then archive them in Jira.
How long does it take? For a project with a few thousand issues, the import itself runs in minutes. The human part — agreeing on statuses and checking dates — is usually an afternoon.
The importer is in private beta. If you'd like early access, write to us from the contact page and mention the size of your Jira instance.