Migration Import Loses Links and Reopens Closed Work
A team is migrating 8,500 issues from a legacy tracker into a company-managed Jira project using CSV import. The CSV includes summary, description, status, assignee email, created date, resolved date, and a column of legacy IDs. The target project has a workflow with statuses To Do, In Progress, In Review, Done. The legacy system had statuses Open, Working, QA, Closed, and Reopened. The import maps Open to To Do, Working to In Progress, QA to In Review, Closed to Done, and Reopened to To Do. After import, 1,100 issues that were Closed in the legacy system show as To Do, and no issue links exist between related tickets. The team also notices that resolved dates are blank on many imported issues.
1. Diagnose the status mapping failure and the missing resolved dates.
Read the worked answer
The status mapping is the first issue. The CSV import maps legacy status values to target statuses by name. If the legacy value "Closed" does not exactly match the mapped target, or if the mapping was configured for a different case or spelling, issues fall back to the default status, which is typically the first status in the workflow (To Do). The report that 1,100 Closed issues show as To Do suggests those rows either had a status value the importer did not recognize or the mapping was not applied to them, for example because the column contained trailing spaces, mixed case, or a different label such as "Closed " or "CLOSED".
The resolved date is a separate mapping concern. The Resolved field is set by the workflow when an issue transitions to a status in the Done category, and the CSV importer can only set it if the resolved date column is mapped to the Resolved field and the value parses in the expected date format. If the column was left unmapped, or the format did not match the importer's expected format, the field stays blank. Also, if issues landed in To Do instead of Done, the resolved date would not be set by workflow either.
The absence of issue links is expected: CSV import does not create issue links from an ID column unless a second import or a linking step is performed. Legacy IDs can be stored in a custom field for later reconciliation.
2. Design a corrected migration approach, including validation steps before and after import.
Read the worked answer
Before import: (1) Profile the CSV. Count distinct status values and show exact strings, including whitespace and case. (2) Normalize values to the exact target status names, or configure explicit value mappings for each distinct legacy value. (3) Confirm the target workflow allows the statuses being imported; the importer can set a status only if it exists in the workflow. (4) Map the resolved date column to the Resolved field and verify the date format matches the importer's expectation; test with a small sample. (5) Store legacy IDs in a dedicated custom field and keep the original CSV as the source of truth.
Pilot import: import 50 to 100 representative issues into a staging project, including at least one of each legacy status and several with resolved dates. Verify status, resolved date, assignee resolution by email, and created date. Check that assignees resolve to active users; unresolved emails become unassigned or the import fails depending on configuration.
Full import: run in batches if volume is large, and record the batch boundaries. After import: run JQL counts by status and compare to the legacy counts (e.g., expect 1,100 Done). Check for blank resolved dates on Done issues and correct via bulk update or re-import if the source data supports it. Then handle links in a second pass: export a link table (source legacy ID, target legacy ID, link type) and use a scripted or app-based linking step that resolves legacy IDs through the custom field. Finally, reconcile totals and archive the import logs.
3. The team wants to also preserve comments and attachments. What should they consider before expanding scope?
Read the worked answer
Comments and attachments change the migration from a single CSV to a multi-step process. CSV import can include a comment column, but multiple comments per issue require either a delimited format with careful parsing or a separate import pass. Attachments cannot be carried in CSV; they require an app or API-based approach that uploads files and associates them with issues, usually matched by a key or legacy ID.
Considerations: (1) Volume and size: 8,500 issues with attachments could mean tens of thousands of files and significant storage; check instance limits and attachment size limits. (2) Authorship: imported comments may be attributed to the importing user unless the importer supports author mapping; this affects audit accuracy. (3) Timing: attachments and comments should be imported after issues exist and after legacy IDs are stored, so matching is reliable. (4) Idempotency: if the import is rerun, avoid duplicating comments and attachments; use a marker or import in a fresh project. (5) Permissions: the importing account needs create-attachment and comment permissions, and the target issues must be visible to it.
A sensible sequence is issues first, then links, then comments, then attachments, validating counts at each stage. Expanding scope should be a deliberate decision with a rollback point, not an afterthought once the first import has run.