Migrate from Taiga to Asana

Taiga Projects map to Asana Teams (member scoping) with one Asana Project per Taiga project. We preserve project description, tags, and creation date as project-level custom fields. Taiga project settings (visibility, workflow template) map to Asana project privacy settings and team permissions. If multiple Taiga projects share the same team membership, we create one Asana Team and multiple Asana Projects under it.

Taiga Milestones map to Asana Sections within a Project. The Milestone name becomes the Section name, and Milestone start_date and finish_date migrate as custom date fields section_start__c and section_end__c on the Section. Taiga Milestone status (open, closed, undefined) becomes a custom dropdown field sprint_status__c. Asana has no native sprint velocity or burndown tracking; we flag this for teams relying on Taiga's sprint metrics and recommend Asana's built-in workload chart or a third-party analytics integration post-migration.

Taiga Epics have no native Asana equivalent. We map Epic color and Epic name to a multi-select custom field epic_theme__c on Tasks, and optionally create separate Asana Projects per Epic or use Asana Portfolios (Business tier) to group related projects. The customer chooses the grouping strategy during scoping. Epic description migrates as a long-text custom field epic_description__c. We preserve Epic status (open, in-progress, done) as a custom dropdown field epic_status__c.

Taiga User Stories map directly to Asana Tasks. The story subject becomes the Task name, description migrates as the task description, story points migrate to a number custom field story_points__c, and status maps to the Asana section or a custom workflow field. Assignee resolves by email match against the Asana destination Team members. Milestone reference becomes the section membership. Custom attributes on the story become typed custom fields in Asana (dropdown, number, date, person) with attribute options preserved.

Taiga Tasks that belong to a User Story map to Asana Subtasks under the parent Task. The task subject becomes the subtask name, status becomes the subtask completion status, and due date, assignee, and custom attributes migrate the same as top-level tasks. Subtask ordering is preserved by setting the subtask creation sequence to match Taiga's task order within the parent User Story.

Taiga Issues (standalone bugs and tracked work outside the sprint backlog) map to Asana Tasks with a custom dropdown field issue_type__c set to the original Taiga issue type (bug, question, enhancement, etc.). Issue severity and priority from Taiga map to custom dropdown fields issue_severity__c and issue_priority__c. Issue status maps to the task's completion state or a custom workflow field if the customer wants to preserve the full issue lifecycle separate from the standard task workflow.

Taiga per-project custom attributes on User Stories, Tasks, and Issues are extracted and mapped to Asana custom fields of equivalent type. Enumerated attribute options in Taiga map to Asana multi-select or single-select dropdown values. Text attributes map to Asana text fields, date attributes to Asana date fields, and number attributes to Asana number fields. Custom attribute names are preserved as custom field names; we flag any attribute names exceeding Asana's 255-character limit.

Taiga Wiki pages with Markdown content map to Asana Task descriptions in Markdown format. We parse the Taiga wiki JSON export, convert Markdown links to Asana-format links, and place the converted content in the task description. For wiki pages that are not directly linked to a specific artifact, we create a placeholder Task named after the wiki page and attach the converted content as a Note or as a rich-text description. Links between wiki pages require manual re-linking post-migration since Asana does not have a wiki cross-linking system.

Taiga free-form tags on User Stories, Tasks, and Issues map directly to Asana Tags. We extract the full tag string from Taiga's tag array and create matching Asana tags during migration. If the destination Asana workspace uses a controlled tag vocabulary, we flag tag consolidation options for the customer's admin. Tags with non-ASCII characters are preserved as-is.

Taiga project members and their role assignments (Admin, Member, Viewer) map to Asana Team members. We match by email and assign the closest Asana permission level (Admin maps to Team Admin, Member maps to Member, Viewer maps to Member with restricted project access). If a Taiga role has no direct Asana equivalent, we assign the nearest available permission level and document the gap in the handoff report.

Taiga attachments on User Stories, Tasks, and Issues are stored as file references with a media URL. We retrieve the files from Taiga's media storage (cloud or self-hosted URL) and re-upload to Asana as task attachments using the Asana Attachments API. File names and original upload timestamps are preserved. Attachments on wiki pages are handled as part of the wiki page migration. Files exceeding Asana's 100MB attachment limit are flagged for the customer's admin to store externally and link.

Taiga comments on User Stories, Tasks, and Issues migrate to Asana Task comments. We preserve the comment author (by email match to Asana user), comment body, and original creation timestamp. Edited comments retain the edited text. Deleted comments are not migrated. Asana's comment format supports rich text, and we convert Taiga's Markdown comment content to Asana's comment format.