Migrate from Taiga to Jira

Taiga Projects map directly to Jira Projects. We preserve the project name, description, and member list. Each Taiga project requires a Jira project key (e.g., PROJ) that we define during scoping; the key becomes the prefix for all Jira issue IDs migrated from that project. Taiga project settings including wiki, module configuration (Kanban vs Scrum), and custom attributes export with the project and require field-level mapping decisions before Jira import.

Taiga Milestones map to Jira Sprints. We preserve the sprint name, start date, end date, and sprint order within the project. Closed Sprints migrate with their Completed status intact. Open Sprints that have not yet closed are created as future sprints in Jira with the original start/end dates. If a Taiga project uses multiple active sprints simultaneously (Kanban with swimlanes treated as sprint-equivalents), we map these to Jira sprints within a shared board.

Taiga Epics map to Jira Epics (available in Jira Software from the free plan onward). Epic status, color tag, and description preserve. In Taiga, Epics are top-level backlog items that group User Stories; in Jira, Epics function identically with an Epic Link custom field on Stories. We set the Epic Name field on Jira Epic issues and map the Epic Link field on child Stories during migration. Where a Taiga Epic has no child Stories, we create a standalone Jira Epic and flag it for review.

Taiga User Stories map to Jira Story issues. The story subject becomes the Jira Summary (required). Story description, status, points (story points to a numeric custom field), assignee, milestone reference, tags, and custom attributes migrate. Taiga's us epic link field maps to Jira's Epic Link field. We resolve the target Epic ID during migration so the Epic Link is populated at import time rather than requiring post-migration manual linking.

Taiga Tasks nested under a User Story map to Jira Subtasks. Subtasks inherit the parent Story's project, Epic Link (if set), and sprint assignment. Taiga Tasks that are not children of a User Story (top-level tasks) map to Jira Story issues — we treat them as Stories in Jira because Jira does not have standalone top-level Tasks without a parent. During scoping, the customer chooses whether all Tasks become Subtasks or whether free-standing Tasks become Stories.

Taiga Issues are standalone work items outside the sprint backlog, with type, severity, priority, and status. We map Taiga issue type to Jira Issue Type (Bug, Task, Story) based on the customer's naming convention. Taiga severity and priority map to Jira Priority (Highest, High, Medium, Low) and to a custom Jira severity field if the customer's workflow requires both. Closed issues from Taiga migrate with their final status and resolution preserved in Jira's Resolution field.

Taiga allows custom attributes on User Stories, Tasks, and Issues per project. We extract the attribute definition (name, type, and options) and create matching Jira custom fields before migration. Text attributes map to Jira Text Field (single line), long text to Text Area (multi-line), number to Number field, date to Date field, and dropdown or multi-select options to Jira Select (single) or Multi-select fields. Enum values are preserved as picklist options in Jira.

Taiga project wikis contain Markdown-formatted pages organized in a tree. We export the page tree and convert Markdown to Confluence Storage Format (XHTML) if the customer has Confluence. If Confluence is not in scope, page content migrates as Jira issue description with Markdown preserved. Links between wiki pages require manual re-linking post-migration because Taiga's internal wiki links do not have Jira equivalents. The page tree structure is documented as a navigation map for the admin to reproduce.

Taiga's free-form tags on User Stories, Tasks, and Issues extract as label strings and apply as Jira Labels. Taiga supports multiple tags per artifact; Jira Labels is a multi-value text field that accepts the equivalent. Where Taiga uses structured tags as a pseudo-category system (e.g., frontend, backend, ux), we recommend the customer review the label vocabulary post-migration to consolidate duplicates and enforce a controlled vocabulary in Jira.

Taiga stores attachments as file reference URLs pointing to the Taiga media storage. We retrieve attachments from Taiga's media URL if the instance is cloud-hosted and accessible, then upload them to Jira via the Jira REST API attachment endpoint (10MB per-file limit on Jira Cloud). Taiga's attachment metadata (filename, uploader, upload date, comment) becomes the Jira attachment comment. Self-hosted Taiga instances with local file storage require the customer to provide media file access during migration.