Migrate your Asana data

Projects are the primary container object in Asana. We export all projects including their settings, default view, color, and archived status. Projects map directly to Projects in most destination platforms and are imported with all child Tasks intact.

Tasks are the atomic work unit in Asana. We preserve all standard fields: name, notes/description, start date, due date, assignee, liked (hearts), and completion status. Completed tasks retain their completed_at timestamp at the destination.

Subtasks exist as a separate resource linked to their parent task. We recursively export the subtask hierarchy and reconstruct the parent-child relationship at the destination. Deeply nested subtask chains are handled with recursive depth tracking to avoid API pagination overflow.

Asana supports custom fields of types: Text, Number, Date, Enum (dropdown), Formula, and Rollup. We map each to the destination's equivalent field type. Enum options with custom colors are preserved as option labels. If the destination lacks the equivalent type, we fall back to Text and flag the mapping for review.

Sections are row-level groupings within a project (distinct from rows or columns). We export section names and task ordering within each section. When the destination uses a kanban-style board, sections map to Swimlanes or status columns.

Portfolios aggregate multiple projects for executive dashboards. Only available on Starter and above. We export portfolio metadata and the list of contained project GIDs. Since Portfolios are an organizational view rather than a data object, we map them to the destination's equivalent project grouping feature or flag them as requiring manual recreation.

Goals (OKRs) are available on the Advanced tier and link to Projects, Portfolios, or standalone. We export goal titles, timeframes, owners, and progress metrics. Goals do not have a universal equivalent in most PM tools, so we map them to the destination's native goal feature or to linked Tasks with a Goals label.

Task dependencies in Asana use GID references and a dependency_type field (predecessor/successor). We preserve the dependency graph and reconstruct it at the destination using the target platform's native dependency mechanism. Circular dependency detection is run before import to prevent infinite loops.

Attachments include both files uploaded directly to Asana and links to external tools (Google Drive, Dropbox, Box). We resolve direct uploads by downloading and re-uploading to the destination's file storage. External links are preserved as URL fields. Files attached via third-party integrations that require OAuth re-authorization are flagged for manual re-linkage.

Comments are stored as a Stories resource linked to tasks. We export comment text, author, and created_at timestamp. HTML formatting in comments is sanitized to plain text or markdown depending on destination support.

Tags are flat labels applied to tasks across a workspace. We export tag names and colors and map them to Labels or Tags at the destination. Tags applied to multiple tasks are handled as a bulk assignment operation.

Asana offers List, Board, Calendar, Timeline (Gantt), and Workload views. We export the view configuration for each project including column order, grouping fields, and sort order. Views are reconstructed using the destination's equivalent view builder; Gantt-specific configurations map to Timeline or dependency views.

Teams are organizational units within an Asana workspace that group members and projects. We export team membership and the list of projects per team. Members are mapped to the destination's equivalent team or group structure.

User profiles include name, email, profile photo URL, and role. We export all active and inactive users. At the destination, users are matched by email for re-invite or mapped to a generic 'Asana User' placeholder if the destination does not support the same user identity model.

Automation rules (Triggers and Actions) execute within Asana's native rule engine and have no standalone export representation. Custom rules built in third-party tools like Flowsana are also non-portable. We document which automations exist so customers can manually recreate them post-migration.