What moves from Jira and what needs manual review
A precise Jira data matrix: automatic migration, mapping and limitations.
Key takeaways
- Data, configuration and behavior are different things.
- Custom values are mapped before writes.
- Limitations are disclosed, not hidden.
The most expensive migration mistake is assuming that “import” means a perfect copy of an entire system. A good migration assistant separates data, configuration and behavior.
Migrated automatically
- Issues and epics with title, description, status and priority
- Story points, original estimate and due date
- Parent and subtask structure
- Sprints and project boundaries
- Comments with author and date when present in the export
- Blocks, relates to and duplicates links
- Labels, components and fix versions
- Jira Product Discovery opportunities, interviews, insights, solutions and experiments
Requires mapping
- Custom statuses and issue types
- Jira users to existing WorkThroughLine members
- Historical sprints when one item has several sprint values
- Custom priorities
- Sprint dates when absent from CSV
Preserved as migration metadata
Unsupported custom fields and attachment references can remain on the source mapping. Information is not silently discarded simply because it has no direct WorkThroughLine model.
Not transferred one-to-one
- Jira automations and workflow configuration
- Marketplace apps and their private data
- Dashboards, filters and permission schemes
- Physical attachment files through ordinary CSV
- Permanent two-way synchronization
Direct Jira Cloud connection is designed for physical attachments, but it is not advertised as active until production OAuth verification.
Reading with an AI tool?Open the clean Markdown version