Migrate from Asana to Jira

Asana Projects map directly to Jira Projects. We export project name, description, color, archived status, default view, and the project membership list. Jira Projects serve as the container equivalent. If the Asana workspace has multiple projects that should be grouped (a team or portfolio), we map them to multiple Jira Projects and document the intended grouping for Advanced Roadmaps or manual project grouping in the migration manifest.

Asana Tasks map to Jira Issues with the issue type determined by a configurable rule. A common mapping uses Asana Tasks with an 'issue type' custom field set to Epic, Story, Task, or Bug. Tasks without a type marker default to Jira Story. We preserve the task name as Summary, notes as Description, start date as Due Date, and completion status as Status. Assignee resolution requires matching Asana assignee email to a Jira User account.

Asana Subtasks map to Jira Subtasks with the parent-child relationship preserved via the Jira subtask link. We recursively export subtask hierarchies and reconstruct them at the destination using Jira's Issue Link API. Deeply nested subtask chains (Asana supports unlimited nesting) are flattened to one level of Jira Subtask because Jira Subtasks cannot have their own Subtasks; we document any deep-nesting structure in the migration manifest for the admin to manually restructure as sibling issues or Epics.

Asana Sections are row-level groupings within a project (To Do, Doing, Done, etc.). Jira does not have a native Section equivalent; we map Sections to Jira Status column positions on the Board or optionally to Labels. If the destination uses a kanban board, we map the section order to the first status in the corresponding column. The customer chooses section strategy during scoping because Jira statuses are defined per project workflow and differ from Asana's per-project sections.

Asana custom fields of types Text, Number, Date, and Enum map to Jira custom fields of the equivalent type. Enum options with custom colors map to Jira option lists, but Jira does not support per-option color metadata, so color values are preserved in a custom description field or stripped with notice. Formula and Rollup fields from Asana have no Jira native equivalent; we map them to Jira Calculated Number fields or document them as read-only custom fields requiring manual value entry post-migration.

Asana task dependencies use GID references with a dependency_type field (blocks/blocked by, precedes/follows). We preserve the full dependency graph and reconstruct it at the destination using Jira Issue Links with link types blocks, is blocked by, or duplicate depending on the Asana relationship type. If Jira Advanced Roadmaps is enabled, dependencies also appear in the timeline view.

Attachments include files uploaded directly to Asana and links to external tools (Google Drive, Dropbox, Box). We resolve direct uploads by downloading from Asana's file storage reference and re-uploading to the Jira issue's attachment endpoint. External links are preserved as URL attachments in Jira. Attachments exceeding Jira's size limit (up to 77.5 MB per file) are flagged for manual download instructions.

Asana Comments are stored as Stories linked to tasks. We export comment text, author, and created_at timestamp. HTML formatting in comments is sanitized to plain text or Jira-style wiki markup depending on the destination's renderer settings. User mentions in Asana comments are mapped to Jira user mentions by email lookup and fall back to plain text display name if the Jira user does not exist.

Asana Tags are flat workspace-level labels applied to tasks. We export tag names and colors and map them to Jira Labels. Jira Labels are project-level by default; we apply the Asana tag vocabulary to each Jira Project that received migrated tasks. Tags applied to multiple tasks are handled as a bulk label assignment during import.

Asana Portfolios aggregate multiple projects for executive dashboards and are available on Starter and above. They do not store independent data; they hold project GID references and owner metadata. We export the portfolio membership list and owner so it can be recreated as a Jira Advanced Roadmaps plan (Enterprise tier) or as a manual project grouping document for the customer's admin. Portfolios on Business tier without Advanced Roadmaps access are documented as a post-migration manual-recreate item.

Asana Goals (OKRs) are available on the Advanced tier and link to Projects, Portfolios, or standalone objectives with timeframes and owners. Jira Goals are a Premium and Enterprise feature. We export goal titles, timeframes, owners, and progress metrics. If the destination Jira is Standard tier, Goals do not exist; we document the goal list and the original Asana goal linkages as a manual rebuild item for the admin.

Asana Automation rules (triggers and actions) execute within Asana's native rule engine and have no standalone export representation. Third-party automation tools built on Flowsana or similar are equally non-portable. We run a pre-migration automation audit, document every rule with its trigger, conditions, and actions, and deliver a written inventory with recommended Jira Automation for Jira equivalents. The customer's admin or an Atlassian partner rebuilds them post-migration.