Migrate from Asana: What Transfers and What Doesn't

Most Asana migrations stall on a false assumption: that the new tool will read your Asana account the way Asana does. It will not. You move a file, and a file only carries what Asana wrote into it.

To migrate from Asana, export each project to CSV from the project menu, tidy the columns, and import the file into Onplana as a spreadsheet. Asana's own export article lists eleven fields (checked 2026-10-02): task ID, creation, completion and last-modified dates, name, assignee, due date, tags, notes, project name and parent task.

The direct answer: An Asana migration moves tasks, not behaviour. Names, assignees, dates, tags, notes and subtask structure travel in the CSV, and Onplana's import wizard (Excel or CSV, up to 50 MB) turns them into a project. Comment history, attachments and rules do not travel, so decide before cutover which of those you still need, and keep Asana read-only until you are sure.

What does an Asana export carry, and what does Onplana do with it?

Sorting every field into "carries", "needs a decision" or "stays behind" is the whole planning job. The table follows Asana's export-to-CSV article for the left column and Onplana's spreadsheet import for the right.

Asana item	In the CSV?	What happens on import	Your action
Task name	Yes	Becomes the task title	None
Parent task (subtasks)	Yes	A parent column rebuilds the hierarchy	Check the tree in the preview
Assignee	Yes	Arrives as a column	Check how names match your workspace members
Due date	Yes	Maps to a date column	Add a start date if you want a real schedule
Tags, notes	Yes	Arrive as columns	Check where each one lands in the preview
Completion state	Yes	Completion date column	Spot-check done tasks
Blocking links	Check your file	Predecessors are read by row number	Redraw in the Gantt if absent
Comments, attachments	Not in the field list	Not imported	Keep Asana for reference
Rules, forms	No, behaviour	Not imported	Rebuild only what still matters

The two items that do not transfer at all are comment history and attachments. Everything else is a decision, not a loss.

How do you migrate from Asana step by step?

The process is five steps, and the diagram below shows where the checks sit.

Export one project first. Open the project menu in Asana and choose the CSV export. Pick a project with subtasks, so the test exercises the hierarchy.
Tidy the columns. Keep the parent task column. Do not trim leading spaces from names; they can be the only indentation signal left. Add a start date column if you want a schedule rather than a list of due dates.
Import as a spreadsheet. The wizard accepts .xlsx and .csv up to 50 MB and reports each repair as a warning against the source row.
Check the result against the export. Compare the task count, the tree, the dates and the owners with the original file, line by line for the first project.
Run both for a short period. Make Asana read-only for that project, then retire it once the team has worked in Onplana for a cycle. The switching guide covers the parallel-run timing.

What does not transfer, and how should you handle it?

Comment threads, attachments and rules stay in Asana. A comment thread is the project's memory, so for any project with decisions buried in comments, export or screenshot the threads that matter before you archive. Rules are the trickier one: nobody remembers every rule they set up. List them, mark each as "still needed" or "habit", and rebuild only the first group.

Dependencies deserve their own check. Asana supports blocking and blocked-by links only, which are finish-to-start. If your export does not carry them, redraw them in Onplana, where the Gantt, the critical path and all four dependency types with lag are on every plan including Free (read from src/lib/plans.ts on 2026-10-02). That is also the moment to fix the links Asana could never express.

Is Onplana the right destination?

That depends on the work. Asana suits cross-functional teams that value simplicity; Onplana suits projects that need scheduling depth. The Onplana vs Asana comparison sets the two side by side, and the migration hub covers moving schedule files from other tools.

Start with the smallest real project you have. The Free plan allows 5 members and 2 projects, which is enough to import one export and judge the result before you move anyone else.

Frequently asked questions

How do I migrate from Asana to another project management tool?

Export each Asana project to CSV, then import that file into the new tool as a spreadsheet. In Onplana the import wizard reads Excel and CSV files up to 50 MB, rebuilds hierarchy from a parent column when one is present, and reports every repair it makes.

Does Onplana have a one-click Asana importer?

No. The route is Asana's CSV export through Onplana's spreadsheet import, which is the same pipeline used for .mpp and XML files. That makes the move a file you can open and check before importing, not a live connection to your Asana account.

What does an Asana CSV export include?

Asana's export article lists Task ID, creation, completion and last-modified dates, name, assignee, due date, tags, notes, project name and parent task for subtasks. Comment threads and attachments are not in that list, so plan to keep Asana readable for reference.

Will my Asana rules and automations transfer?

No. A rule is behaviour, not a row, so it cannot be exported as a spreadsheet column. Write down what each rule did, then decide which ones still earn a place in the new tool and rebuild only those.

Can I trial the move before committing a whole workspace?

Yes. Import one project and check it. Onplana's Free plan allows 5 members and 2 projects, which is enough to test a real export, and importing does not touch the original Asana project.

Do Asana dependencies survive the move?

Check them after import, because they may not arrive. Asana models blocking and blocked-by as finish-to-start only, so after the import you can draw the links again in the Gantt and add start-to-start, finish-to-finish or lag where the work really needs it.