PM Tools Reviewed

Guide

Import Data Into Asana Without Losing Fields 2026: The Mapping Order That Works

Asana CSV import turns your custom fields into project-local fields, drops comments, and will happily create duplicate tasks. Here is the import order and the pre-flight checks that survive contact with a real 4,000-row export.

· By Ace · Updated

Asana

An Asana CSV import fails in a specific and predictable way: the tasks arrive, the titles are right, and the fields you cared about are gone. Not renamed, not mangled — gone, replaced by project-local copies that do not appear on your other projects, so the moment someone adds the same task to a second project the values vanish from view.

That is not a bug and it is not random. It is the documented consequence of how Asana creates custom fields during import, and it is fixable if you change the order of your operations. This guide gives that order, plus the pre-flight checks that determine whether your export is even importable.

For the platform-level assessment, see the Asana review. For the sourcing context on whether Asana is the right destination at all, best project management software is the hub. This page is about the mechanics of getting data in without a rebuild.

TL;DR

  • Order matters more than any setting: create and promote your organisation-wide custom fields first, then create the project and add those fields to it, then import. Importing first and fixing fields later is what produces project-local fields.
  • CSV import does not carry comments. Community maintainers point to a third-party copy tool (Ditto) for comment fidelity — Asana’s own import writes field values, not the comment stream.
  • Subtasks need a parent column; sections need a matching existing section or they become one flat list. Both are mapping-time decisions inside the import wizard, not post-import repairs.
  • Duplicates usually mean the source CSV has duplicate rows, not that Asana double-imported. Check the source before you re-import, because a second import of a bad file doubles the mess.
  • Asana caps concurrent duplication, instantiation and export jobs at 5 per user — and that includes jobs started from the web app, such as a CSV import. A large import queued behind other jobs will appear to hang.
  • Do the field audit on one row before you import four thousand. The import is reversible only by deleting the project.

What is actually free here, and what it costs

This page has no new subscription cost: CSV import exists on Asana’s paid plans, and the price question is only whether you are already on one.

Plan Per user, per month (annual, USD) Notes relevant to import
Personal $0 2 users, unlimited tasks and projects — the free tier’s user cap, not a feature cap
Starter $10.99 $13.49 billed monthly. No user seat limits, unlimited free guests, custom fields, unlimited automations
Advanced $24.99 $30.49 billed monthly. Adds the cross-project views that make imported data useful
Enterprise Custom quote — Asana does not publish a per-seat price for this tier Sales-led

Verified against Asana’s official pricing page on 2026-11-03.

The practical read: custom fields — the thing this entire article is about — start at Starter, $10.99 per user per month billed annually ($13.49 monthly). If your team is on the free Personal plan with two seats, the import will still work, but the custom fields you map to are limited, and the cross-project reporting that justifies importing structured data is not there. Ten seats on Starter is $109.90/month; the same ten seats on Advanced is $249.90/month, a $1,680/year difference that you should not pay to fix a field-mapping problem — the mapping order below fixes it on Starter.

Pre-flight: four checks on the source file (30 minutes)

Do these before opening Asana. Every one of them corresponds to a failure mode documented by people who did not.

1. Confirm the CSV has no duplicate rows

Duplicate tasks after import are the most commonly reported surprise, and the community consensus is that they come from the file. In a thread on duplicate records created from a CSV import, an Asana community moderator states it “should only duplicate if the CSV has a duplicate in there.” Sort your file on the combination of task name + project + due date and look for repeated pairs. sort | uniq -d on a text dump is enough.

The same thread documents three other losses in a cross-workspace move that are worth knowing before you plan the migration: completed tasks came across as incomplete, and old comments did not copy. Both are stated in the original report and confirmed in replies. If your export represents two years of work, this is not a cosmetic gap — plan a separate path for history.

2. Decide where the truth for each field lives

Every column in your CSV must be sorted into one of four buckets:

  1. Native field — assignee, due date, start date, priority, status/section, notes. Maps directly.
  2. Organisation-wide custom field — anything you will want on more than one project: client, budget, phase, region.
  3. Project-local custom field — acceptable only if the value is genuinely meaningful to one project.
  4. Discard — columns that were spreadsheet hygiene and mean nothing in a task system: row numbers, colour notes, “last edited by”.

Bucket 2 is where the money is. Write the list of organisation-wide fields on paper, with their exact option names, before importing anything.

3. Normalise option values in the CSV

Asana matches dropdown options by exact string. In Progress, in progress and In progress create three options in one field, and the third one is invisible in a spreadsheet. Strip whitespace and unify case in the source file. This single step prevents a class of cleanup that takes longer than the import did.

4. Confirm your seat and job headroom

Asana’s rate-limit documentation states that duplication, instantiation and export endpoints are limited to 5 concurrent jobs per user, and explicitly includes jobs “initiated from the Asana web app (for example, duplicating a project, a CSV import, or template instantiation)”. If three colleagues are duplicating projects at the same moment, your import queues behind them and looks frozen. Import outside working hours, or at least when nobody is duplicating anything.

The import order that preserves fields

This is the whole article in one sequence. Follow it literally.

Step 1 — Create the organisation-wide custom fields first (10 minutes)

In Asana, custom fields live at two levels: workspace/organisation-wide, and project-local. A field created during an import is local. So create the organisation-wide fields manually, with exact option names, before any project exists.

This is not folklore. It is visible in the problem that prompted a community thread on creating a global custom field during CSV import: a user importing a project found that “when importing from a CSV all custom fields are local and as far as I understand created at the point of creation of a project,” with the result that adding a task to a second project made the first project’s fields not show up. The fix — pre-creating the organisation-wide field and pointing the importer at it — is the same fix here.

One governance note from the same thread, answered in the replies: members with your organisation’s domain can create organisation-wide custom fields on paid plans; guests cannot. But you cannot stop members from creating near-duplicate fields except by restricting who holds project-admin permission — which matters if you are importing dozens of projects on behalf of other teams. Nominate one person to own the org-wide field library.

Step 2 — Create the destination project and attach the fields (5 minutes)

Create the project in the destination workspace, then add the organisation-wide fields to the project’s field list before importing. An attached field is available to the importer as a target; an unattached one is not.

If you are importing into an existing project that already has local fields with names identical to your org-wide fields, rename or remove the local ones first. Two fields with the same name is the configuration that causes values to appear to “disappear” — the importer targets one, the view shows the other.

Step 3 — Import in one batch, smallest possible project first (15 minutes)

Import the smallest project in your migration first. Not the biggest, not the most important — the smallest, because it lets you test the whole mapping in three minutes instead of thirty.

In the wizard, map every column explicitly. Do not accept a suggested match for a dropdown field without opening the dropdown and checking the option list. Then, immediately after import:

  • Open one task. Confirm every org-wide field has a value and is not marked local.
  • Add that task to a second project. Confirm the field values are still visible. This is the test that catches local-field creation, and it takes ten seconds.

Step 4 — If the test fails, delete the project and start again

There is no “convert local field to global field” operation. If you imported into a project with local fields, you delete the project (or its items) and redo the import after step 1. This is why step 3 uses the smallest project. Re-importing 40 items costs minutes; re-importing 4,000 costs an afternoon and a round of duplicates.

Step 5 — Only then, bulk-import the rest (bulk time)

Import the remaining projects in the same order, one at a time, and stop after each to spot-check one task. Do not queue five imports back to back — you will hit the 5-concurrent-job ceiling with your own jobs and possibly a colleague’s, and you will not know which one stalled.

Where imported comments and history go

Nowhere, by default. Comments are not part of the CSV import. The community’s answer, repeated across threads by long-time contributors, is a third-party project-copy tool (Ditto) which reproduces comments as comments — and, per the same duplicate-records thread, is “used/recommended by Asana itself.” A community manager in that thread offered the fallback: copy comments into the task description instead. That is a real option and a real compromise — descriptions are editable by anyone with task access, comments are not.

Practical rule: if the history matters legally or for client-visible audit, do not treat CSV import as a migration. Treat it as a re-creation, and archive the old system read-only for the retention period your contracts require.

The failure modes that survived the build, from users

Three specific frictions, each with a link, because they are the parts you cannot infer from the help centre:

  • Private duplicates appearing only in My Tasks. A user reported that a CSV project import created duplicate tasks which appeared only in “My Tasks,” were private, and were not linked to the original task — described as happening “randomly,” not on every task, with no third-party integrations in use. The workaround that resolved the conversation was not a setting; it was confirming the source file first. This is the single most useful expectation to set with your team: after import, check My Tasks for orphans before you check the project.
  • Completed tasks arriving as incomplete, comments dropped. Documented in the cross-workspace import thread. If you are mid-project, re-close them by filter (Assignee = anyone, Completed = No, due date < today) and accept that the completion timestamps are new.
  • Field-library sprawl. The follow-up question in the global-field thread is the one to take seriously: how do you stop people flooding the org library with near-identical fields? The answer in that thread is that you cannot, beyond limiting project-admin permission. At scale, that is a naming-convention problem solved by policy, not by the importer.

One thing an import does that nobody warns you about: it gives your automations more objects to fire on. If you have AI-powered rules — Asana’s AI Studio runs on credits allocated per billing account — then importing four thousand tasks can trigger rules thousands of times in an afternoon.

Two documented data points make this concrete. A user asked for a credit-limit notification at 50% because the built-in warnings fire at 80% and 100% and are sent to admins rather than to the people running the rules — and, at 80% of a monthly allowance, a single large import can carry you the rest of the way. And in the 4-million-credit post-mortem, the root cause was a rule with no conditions that fired on every task assigned to one person. An import is that rule’s dream.

Pre-flight action: before a bulk import, disable AI-powered rules on the destination project, import, verify the data, then re-enable. It costs two minutes and prevents a four-figure surprise.

What this guide does and does not verify

The plan prices above are read from Asana’s published pricing page on 2026-11-03. The import behaviours — local field creation, comment loss, completed-task loss, duplicate rows — are drawn from Asana’s public community forum, where the answers come from community moderators and long-time contributors, and are linked inline. The rate-limit and concurrency numbers are quoted from Asana’s developer documentation.

What we have not done is run a scripted 4,000-row import and instrument the results. If your dataset is larger than a few thousand rows or contains multi-level dependencies, the sequence above is still the right shape, but expect to spend a session on the first small project rather than the fifteen minutes suggested.

Disclosure: PM Tools Reviewed does not claim to have independently tested Asana’s CSV importer hands-on. Pricing is verified against the vendor’s official pricing page on the date stated; behavioural claims are cited to the vendor’s community forum and developer documentation with links.

Team-size verdict

If you are 2 people on Asana Free: import into a single project, accept local fields, and do not attempt an org-wide field library — you do not have the governance surface to maintain one, and the Personal plan’s 2-user cap is the binding constraint anyway.

If you are 3–15 people on Starter ($10.99/user/month annual): this is the sweet spot for the sequence above. Create 6–10 org-wide fields, import project by project, and stop. The $10.99/seat price means a 10-person team is at $109.90/month — spending the first two hours of the migration on field governance is worth more than any plan upgrade.

If you are on Advanced ($24.99/seat): the reason to be here is cross-project reporting, which means your imports must land in org-wide fields or the reporting is empty. Follow steps 1–3 exactly, and use the smallest project as your canary. At 25 seats this is $624.75/month; a failed migration that leaves 4,000 tasks in local fields is a month of work to unwind.

If you are weighting whether to migrate at all: best PM software for consulting firms covers the client-work decision, and how to choose PM software is the framework. Migrating is usually the wrong answer when the existing tool still passes your three must-haves.

Sources

Related reading