The Definitive Guide to Migrating to Asana

Asana, Inc. was founded in 2008 by Dustin Moskovitz and Justin Rosenstein, launched commercially in April 2012, and is headquartered in San Francisco ¹. The flagship Asana service is a web and mobile work-management platform that helps teams organise, track and manage their work across projects, portfolios and goals.

The typical Asana customer is a cross-functional team — 25 to 5,000 users — that wants a single tool for project plans, intake forms, recurring operational work and OKR-style goal tracking, without standing up a dedicated Jira admin. Compared with Monday, Asana positions on a more opinionated data model (Workspace/Team/Project/Section/Task/Subtask) and stronger Portfolio rollup; compared with Jira, on a faster ramp for non-engineering teams.

Migrations to Asana fall into four shapes. First, consolidation: replacing Trello + spreadsheets + an intake tool with Asana's Projects + Forms + Rules combination. Second, Monday or ClickUp exits, driven by teams that want a more structured workflow story and tighter portfolio rollup ¹²⁷.

Third, legacy replacements — Wrike, Smartsheet, Teamwork, MS Project — where the source schema is loose and the project is a re-architecture. Fourth, M&A consolidation, where an acquired business runs a different PM tool. A Trello-to-Asana move has clean object parity but loses card automations; a Monday-to-Asana move flattens board structure into Projects + Sections + custom fields.

What makes migrating *to* Asana easier than the category average is the CSV Importer itself — it accepts CSV exported from Excel, Smartsheet, Wrike, Monday, Airtable, Trello, ClickUp and Google Sheets, and preserves task name, description, assignee, due dates, start dates, dependencies, followers and custom fields in a single pass ²⁴.

What makes it harder than the average is that comments and historical activity do not import via CSV, attachments must be re-uploaded or relinked individually, completion state on imported rows is silently stripped to *incomplete*, and created_at cannot be overridden — every imported task is stamped with the import date ^5499161.

Rules, Bundles, Forms and inbox notifications do not move across either — they are rebuilt from documentation. Teams that scope for that work up front finish on time; teams that assume CSV parity do not.

CSV gets you tasks, names, owners and dates. Everything else — comments, history, completion state, attachments — is a second project.

Asana's object model is small but layered. A top-level Workspace or Organization contains Teams, which contain Projects, which contain Sections and Tasks, which contain Subtasks ⁶³. Tasks are the basic unit of action — they have an assignee, a name, notes (description), followers, likes and comments, and they inherit custom fields from their parent project ⁶³.

Before you can map a field on the source side, you need to know exactly which destination object the row belongs on, what properties it requires, and which value will serve as your match key. The table below summarises the objects you will touch in a typical Asana migration.

Asana does not expose a true external-ID / upsert key on tasks. The platform identifier is the gid (a global ID surfaced in the URL as /0/<project_gid>/<task_gid>). The CSV Importer always creates new tasks — there is no native upsert; re-running a CSV against an existing project produces duplicates ⁵⁴¹⁵⁷.

Teams that need re-runnability typically introduce a custom ID-type field (unique readable IDs per task) plus a separate text *External ID* field for the source system's primary key, and handle upsert logic externally. The ID custom field is the closest Asana feature to a stable, queryable record key ³⁸.

Custom property types determine validation and storage; the catalogue below covers what you can model and the limits you need to plan around.

Relationships in Asana are modelled differently from a relational CRM. A task can be multi-homed — present in multiple projects simultaneously — which is how the platform expresses many-to-many ³⁸. Subtasks belong to exactly one parent task and inherit nothing from it by default (they do not auto-populate custom fields or section). Dependencies are *blocking* / *blocked-by* relationships between tasks, configurable on Advanced+ plans.

There is no cascade-delete, no master-detail relationship, and no foreign-key constraints — deleting a parent task orphans its subtasks, and removing a project from a multi-homed task leaves it alive elsewhere. Reproduce stricter cascade semantics via Rules or import scripts if the source relied on them.

The single best predictor of a clean Asana migration is how much work you do on the source side before the first CSV is uploaded. The CSV Importer is forgiving on file format but unforgiving on structure: wrong-parent subtasks, wrong-locale dates and mismatched assignee emails all silently land but produce broken tasks that take longer to repair than to re-import.

Always finish an Asana migration in one sitting if you can — context loss between sessions is the single biggest source of mistakes.

Treat the source export as raw material to be shaped to Asana's expected formats — dates in mm/dd/yyyy, assignees resolved to verified emails already in the destination workspace, drop-down values matched case-exactly to the destination custom field, and subtask parents resolved either by row position or via an explicit *Parent Task* column.

Source-side prep

• Audit and de-duplicate tasks in the source — Asana's CSV importer does not detect duplicates on re-import and will happily create a second copy of every row ⁵⁴, so any cleanup has to happen on the source side or in the staging spreadsheet.
• Resolve assignees to verified email addresses that already exist in the destination Asana org. The assignee column is matched by exact email; mismatches result in unassigned tasks with no error, which then break ownership-based filters and notifications.
• Normalise dates to mm/dd/yyyy in the CSV — Asana parses U.S. format reliably and frequently misreads dd/mm/yyyy files, producing off-by-month errors that look correct until someone notices a January task due in April ¹²⁴.
• Convert drop-down values to the exact case used in the destination project's custom field. Case-only differences create new options silently — "option" and "Option" become two values rather than collapsing ¹⁵⁷.
• Decide subtask strategy upfront — either put subtasks immediately below their parent row and let Asana infer hierarchy, or carry an explicit *Parent Task* column with the parent's exact name ²¹. Mixing strategies in one file produces orphan subtasks.

Destination-side prep

• Request a sandbox from Settings → Admin Console → Sandboxes — available only on Enterprise+ ⁵³. A sandbox is a separate, empty space where you can dry-run imports, train users and validate rules before touching production. Each Enterprise+ org gets one or more sandbox slots.
• Provision users first via Okta, Entra ID or Google Workspace single sign-on (Enterprise+) or via the CSV user import at the admin console on Advanced+ ⁹⁶. The assignee column on a task import only resolves if the user already exists.
• Create destination projects, sections and custom fields before importing tasks. The CSV Importer can build a new project from a file, but if you want tasks to land in an existing project with a specific structure, the project, sections and field library entries have to exist first.
• Add the field library entries you will need — drop-down options, ID fields, formula fields. Adding fields mid-import creates per-project copies that don't roll up into Portfolios.
• Define dependencies as a column that references parent task names if you need blocking/blocked-by relationships preserved during import ¹²⁴. The advanced CSV options support a *Dependents* column that resolves by exact name match.

People prep

Cutover only works if humans cooperate. Lock down a source freeze window — 24 to 48 hours — and communicate it to every team that touches the source tool. Train project leads on Asana's Projects + Sections + Custom Fields model before go-live, especially if the source was board-first. A simple Trello move under 1,000 tasks runs one to two days; a complex multi-team migration with subtasks, dependencies, Forms and Rules rebuilds runs two to four weeks of elapsed time.

Asana exposes two main load paths and the right one depends on dataset size and source format. The CSV Importer covers most one-shot migrations under ~20,000 tasks. Smart Import (AI-assisted) handles unstructured files like PDFs and presentations. Third-party migration tools cover the shapes CSV cannot reach, including Workspace-to-Workspace splits with comments and attachments preserved.

CSV Importer

The native importer lives behind the + button in the top bar (Create new project → Import → CSV) or via any existing project's three-dot menu → Import → CSV ⁴¹⁶. It accepts a single CSV file mapped to a new or existing project, parses the first row as headers, and lets you confirm column mapping before commit. Supported columns: Task Name, Description, Assignee (email), Due Date, Start Date, Section/Column, Dependents, Followers, and any number of Custom Field columns ⁴.

Limits are practical rather than published: there is no documented hard row cap, but performance degrades above ~10,000 rows per file, and imports above ~20,000 rows often time out ³⁷. Subtask depth caps at 5 levels ³⁷, drop-down fields cap at 500 options ³⁸, and attachments are not supported in CSV at all. The right call: CSV for one-shot loads under 20,000 tasks on a single project, especially when the source already exports clean CSV (Trello, Monday, Wrike, ClickUp).

Smart Import (AI)

Smart Import accepts CSV, PDF, DOCX, XLSX, PPTX, TXT, JPEG and PNG, and uses Asana AI to generate a project structure (sections, tasks, custom fields) from the content ¹⁸. It is the right tool when the source is *not* already structured CSV — a plan in a Word doc, a Gantt screenshot, a meeting agenda. It is the wrong tool when you have clean columnar data: AI inference adds variability that direct CSV mapping avoids.

Third-party migration tools

Tools sit between the source and Asana for the shapes CSV cannot reach. Asana's own migration service copies data between Asana domains for free but does not migrate paid plan, admin roles, or deleted objects ¹⁰⁸¹¹⁵. Altosio ($14.99+ per project) covers Trello, Monday, Wrike, Planner, ClickUp and Asana-to-Asana with comments and attachments preserved ¹²⁷. Relokia runs a managed CSV-bridged migration. Airbyte, Fivetran, Stitch and Matillion are reverse-ETL tools for ongoing sync.

Mapping is where every PM migration earns its scars. The decisions in your mapping spreadsheet determine whether Portfolio rollups work on day two, whether Rules fire correctly on day five, and whether project leads trust the data on day thirty. Work object by object: Workspace/Organization first, then Teams, then Projects with sections and custom fields pre-built, then Tasks with subtasks, then dependencies, then comments and attachments as separate jobs.

Project hierarchy: Workspace → Team → Project → Section → Task → Subtask

Asana's hierarchy is rigid in a way that catches teams from board-style tools. Subtasks max out at 5 levels ³⁷; a WBS from MS Project nesting six or more levels has to be collapsed before import. Sections are *not* workflow status — they are visual groupings within a project. If your source used a Status column, the cleanest mapping is either (a) Sections (good for Kanban) or (b) a single-select custom field called *Status* (good for cross-project rollup via Portfolios).

Decide upfront — mixing patterns across projects makes Portfolio rollups inconsistent. The custom-field approach is generally the better default for multi-project organisations because *Status* values then roll up into Portfolio columns and Goals.

Task dependencies (blocking / blocked-by)

Dependencies in Asana are *blocking* / *blocked-by* relationships between tasks within the same project and require Advanced+ for full functionality ¹²². The CSV Importer supports a *Dependents* column that resolves by exact task name — duplicate names break the resolution silently and produce no error ¹²⁴. A common pattern: keep dependencies inside a single project for the import, then split into multiple projects via multi-home afterwards. Cross-project dependency-shifting is only available in Timeline view ¹²².

If the source is MS Project or Smartsheet with finish-to-start, start-to-start and finish-to-finish dependencies, expect to collapse to Asana's simpler blocking/blocked-by model.

Time tracking history

Asana ships a built-in Time tracking custom field for Estimated and Actual Time per task ³⁸. Historical entries from Harvest, Toggl or Clockify do not import via CSV — the field accepts a current value, not a back-dated entry stream. Asana has a dedicated path from Everhour that copies the most recent estimated and actual values onto matching tasks ¹²⁶. For other sources, summarise time per task, populate *Actual Time* with the rolled-up total, and archive per-entry detail.

If forensic per-entry detail matters for billable reporting or audit, keep the source archive accessible — Asana holds only summaries.

Comments, @-mentions and reactions

Comments are the single biggest gap in the CSV path: CSV export does not include comments, and CSV import cannot create them ⁵⁴. Anything preserved has to be recreated through a third-party migration tool that supports comment carryover, or accepted as a known loss.

Rich-text formatting in source comments survives only when written using Asana's markdown subset — the notes field supports bold, *italic*, lists, links, blockquotes¹⁴⁹. Confluence-style macros, embedded tables and team mentions degrade to plain text. Plan a transform step that strips HTML to Asana markdown before any comment-replay tool runs, or accept the degrade.

Custom workflow status migration

Asana does not have a first-class *Status* concept on tasks — there is completed: true|false, and that's it ⁹⁴. Source platforms with rich status models (Jira's workflow states, Monday's Status column, Trello's lists) need to land on either a Section or a single-select custom field, as outlined above.

Critically: the CSV Importer cannot create completed tasks — every imported task lands as incomplete regardless of source state ⁹⁴¹⁶¹. The documented workaround: add a *Status* single-select with a *Complete* option, create a Rule that *when status = Complete, mark task complete and clear status*, then run the rule across imported tasks. This is the only reliable round-trip for completion state via CSV.

Recurring tasks

Recurring task schedules — daily, weekly, monthly, yearly, on completion — are an Asana-managed property and **the CSV Importer does not support a *Recurrence* column**. Recurring tasks imported via CSV land as one-shot tasks. The mitigation: import as regular tasks, then configure recurrence manually post-import. For hundreds of recurring templates, a third-party migration tool that supports recurrence is the only practical option.

Attachments: Asana-hosted vs linked from Drive / Box / Dropbox

Attachments do not import via CSV at all. Asana hosts files up to 100 MB per file uploaded from a computer; larger files must be attached as Dropbox, Google Drive, OneDrive/SharePoint or Box links ³⁶¹³⁰. There is no documented hard storage cap on the number of files per workspace ³⁶, but performance degrades on tasks with very many attachments and forum threads recommend not exceeding a couple of dozen files per task.

For large estates (hundreds of GB), the pattern most teams adopt: keep originals in Drive, S3 or Box, store a deep link in a URL-type custom field, and inline-upload only the small subset that needs to live on the Asana timeline. Third-party migration tools handle the bulk file upload where inline hosting matters.

Audit trail, ownership and original timestamps

Standard created_at, modified_at, completed_at and created_by are Asana-managed system fields — they cannot be overwritten on import via CSV ⁹⁹. Every imported task is stamped with the import date and the importing user as creator. Teams discover this on day two when filtered reports of *tasks created last month* return nothing or everything from import day.

The pattern: create two custom fields per project, *Legacy Created Date* (date) and *Legacy Created By* (text or people), populated from the source export. All historical-period reporting runs against the legacy fields. Asana's audit log is available only on Enterprise+ or Enterprise + Compliance Management add-on, with events retained 90 days ⁹³. Lower tiers have no granular per-property change history.

Rules, Bundles, Forms, Approvals — the rebuild list

Asana's no-code automation runs on Rules (per-project), Bundles (reusable rule + field packages), Forms (intake), and Approvals. None of these import — they are rebuilt from documentation post-cutover, ideally in a sandbox first. A typical mid-market migration carries 20 to 80 source automations that map to a similar count of Rules; the rebuild runs days, not hours.

Lead-scoring-style logic from CRM-adjacent PM use cases similarly does not import. Recreate as Formula custom fields (number-output) on the destination project.

Validation is the bridge between the import finishing and users being allowed in. The three-stage rhythm that works on Asana: a test load of 10 percent of records with stakeholder spot-checks, the full load with real-time monitoring of task counts and assignee distribution, and a 30-day post-migration data-quality audit. The most reliable signal is having project leads verify their own projects — they know what right looks like better than any reconciliation script.

Build a reconciliation spreadsheet that compares source and destination on each of these counts. Anything outside a 1 percent variance gets investigated before users get login access.

• Total tasks imported vs source — minus deliberately excluded rows (archived projects, deleted tasks, role-based or system-generated entries).
• Total subtasks per parent task vs source — and a depth check (MAX(depth) <= 5) to confirm the cap did not silently truncate.
• Tasks per section per project vs source — a non-trivial count variance usually signals a Status mapping error or a hierarchy issue.
• Assignee distribution — GROUP BY assignee_email and confirm no tasks landed unassigned that should not have. Unassigned tasks are typically email-mismatch casualties.
• Custom field coverage — for each project, count tasks with a value in each custom field and compare to expected. Drop-down case-fork errors show up here as inflated option counts.
• Dependency integrity — for projects with dependencies, count blocking and blocked-by edges and compare to source. Missing edges usually indicate a duplicate-name resolution failure.
• Completed-task count — the high-frequency failure mode. Run before AND after the *Complete* Rule fires, to confirm the Rule actually closed the imported tasks.
• Legacy date field coverage — confirm every task has a populated *Legacy Created Date*; gaps reveal rows where the source field was empty or the column mapping dropped.

On top of reconciliation, run a manual spot-check: pick 30 random tasks across projects and verify each field against the source UI. Pick five high-stakes projects and trace the full tree — sections, tasks, subtasks, dependencies, custom fields, attachments. If a non-trivial discrepancy shows up in three or more of the 30, halt, fix the root cause, and re-import the affected rows.

Asana has no native bulk-rollback button ¹¹³. Once tasks are imported, undoing them is per-task delete (lands in the trash for 30 days on Enterprise ¹³⁷) or per-project archive. For larger reversals, the only practical mechanism is to delete the affected project entirely and re-import. This is why every import should be staged: load to a freshly-created project first, validate, then either keep it or delete-and-redo, rather than importing into a production project.

The real rollback strategy: export every source object to S3 before import, stamp every imported task with an *Import Batch ID* custom field, and if catastrophe strikes, filter on that batch ID, archive the project, and re-import from the cleaned source.

Cutover sequencing: (1) source goes read-only and the team is notified; (2) final delta export captures changes during the test-import window; (3) delta imports into staging projects; (4) reconciliation runs; (5) staging projects move to production teams; (6) users get login and a 48-hour hyper-care window with the migration lead on call; (7) source decommission is scheduled 30 to 90 days out. Asana's in-house service warns that paid plan, admin roles, and deleted objects do not carry over ¹¹⁵.

Asana's Solutions Partner Program lists certified consulting partners worldwide ¹⁰³. Partners with explicit migration practices — particularly Trello-to-Asana, Monday-to-Asana, Wrike-to-Asana and ClickUp-to-Asana — tend to ship cleaner than generalist implementation shops. Examples from the partner directory include i.DO (France/global), Priceless Consulting, PMexperts (Poland), and Taco Technologies (Australia). Each offers fixed-scope migration packages alongside ongoing managed services.

Asana also runs an in-house migration team that copies data between Asana domains for free ¹⁰⁸¹¹⁵. It has documented caveats: it does not migrate paid plan, admin roles, or deleted objects. Plan to re-provision those after the data copy completes.

On the specialist side, Altosio ($14.99+ per project) covers Trello, Monday, Wrike, Planner, ClickUp and Asana-to-Asana with subtasks, comments and attachments preserved ¹²⁷. Relokia runs a Demo + Full Migration model with custom-field mapping and agent-resolution that handles email-mismatch cases. Workino, Omtera and ditto.kothar.net cover related niches, particularly for Asana-to-Asana Workspace splits.

On the ETL and iPaaS side, Airbyte, Fivetran, Stitch and Matillion all have Asana connectors. Their role in a one-time migration is rarely the migration itself — it is the staging layer that lands source data into a warehouse, the transformation layer that converts drop-down values and resolves assignee emails, and the ongoing-sync layer that takes over once the one-time migration is complete. Workato is a common pick where the migration is bundled with a Rules rebuild.

Managed-migration cost ranges vary widely. A clean Trello-to-Asana move under 5,000 tasks with no historical comments often lands in the £1,500–£5,000 / $2,000–$7,000 range. A multi-team migration from Monday or Wrike with attachments, comments, dependencies and Rules rebuilds typically runs $15,000–$80,000, driven by task count, custom-field complexity, attachment volume and the number of source automations that need rebuilding rather than re-pointing.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Asana migrations and handles the project hierarchy planning, custom-field mapping, comment preservation, attachment migration, and validation work described in Sections 5 and 7 of this guide. Pricing is fixed-fee, based on task count and source platform, with separate line items for comment depth, attachment volume and Rules rebuilds so the scope is transparent before signature.

This is one of several legitimate paths — the right choice depends on whether you want an Asana Solutions Partner, Asana's free in-house service, a specialist tool, an iPaaS-first approach, or an end-to-end managed migration vendor. Explore FlitStack →