How to Migrate From Asana

What is the fastest way to migrate from Asana?

The fastest safe route is to archive dead projects, export each live project as both CSV and JSON, rebuild the structure in the destination tool, and run the two systems in parallel for one to two weeks. Plan for two to three weeks end to end for a team with five to fifteen active projects.

Do not try to move everything. Every archived project you skip saves cleanup time later.

What does migrating from Asana actually involve?

Migrating from Asana involves four separate jobs that are easy to mistake for one: extracting data, mapping it to a different data model, rebuilding configuration that lives outside tasks, and moving people’s habits. Only the first is a file operation.

The second job is where most projects lose time. Asana’s structure is projects, sections, tasks, subtasks, and custom fields. Your destination tool may use projects, statuses, boards, and labels. A section called “In review” has to become a status, a column, or a label, and that decision affects every report built afterward.

The third job is invisible until cutover. Rules and automations, project templates, forms, goals, and portfolio views are configuration, not task data. No export carries them. They get rebuilt by hand, or deliberately dropped.

The fourth decides whether the migration is judged a success. People do not experience the migration as a data change. They experience it as “where did my thing go?”

What can you export from Asana?

Asana offers several export routes, and choosing the wrong one is the most common reason teams end up with incomplete files. The menu path has changed over the years: current builds show Export or sync in the project dropdown, while older help pages still call it Export/Print.

Two details matter more than the rest.

Exports are per project. A workspace with 40 projects means 40 downloads unless you use a search export or the API.

The JSON export is a one-way file. Asana’s CSV importer is the only path back in, and it only adds tasks. If you export JSON expecting a restorable backup, you will find out the hard way.

What survives the move and what has to be rebuilt?

Task-level data mostly survives. Collaboration data mostly does not. Planning for that split is the difference between a migration and a surprise.

Three practical consequences follow.

First, subtask relationships in CSV depend on parent task names. If two tasks share a name, the link is ambiguous. Sort by the parent column to rebuild the hierarchy deliberately.

Second, comments are the most-missed data and the least replaceable. If decisions live in task comments, export the ones that matter before you leave, using the API endpoint `GET /tasks/{task_gid}/stories`.

Third, the CSV column set is wider than you want. Every custom field becomes a column, including retired fields that still hold values on old tasks. Hiding a column is fine; deleting it before you have checked the mapping is not.

> Important note: Open the export in a spreadsheet tool that respects UTF-8. Excel’s default handling of commas and encoding has produced more “corrupted export” panics than any actual data loss.

Should you use CSV, JSON, or the API?

Use CSV when you are importing into a tool that accepts spreadsheets or when a human needs to read the data. Use JSON when the destination needs descriptions and nested subtasks. Use the API when you need comments, cross-project extraction, or a repeatable process you can run again after cutover.

For most teams: take both bulk formats for every live project, then write a short API script only for the gap you cannot live without, usually comments on active tasks.

What the API adds

Asana’s API is a REST interface with pagination, and it is well documented. The endpoints you need are few:

• `GET /projects/{project_gid}/tasks` for the task list in a project
• `GET /tasks/{task_gid}?opt_fields=name,notes,due_on,assignee` for detail
• `GET /tasks/{task_gid}/stories` for comments and activity
• `GET /workspaces/{workspace_gid}/tasks/search` for filtered, cross-project extraction

Authentication is a personal access token for a one-off script, or OAuth for anything you keep.

Rate limits are the part people underestimate. Asana documents 150 requests per minute on free domains and 1,500 on paid domains, with the search endpoint capped separately at 60 per minute. Export, duplication, and instantiation endpoints allow only 5 concurrent jobs per user, and that count includes jobs started from the web interface, such as a CSV import. Exceed a limit and you get a 429 with a `Retry-After` header; honour that value rather than assuming a full minute.

Pagination returns up to 100 records per call. With 1,920 live tasks, a list-and-detail loop is roughly 20 list calls plus one detail call per task. At one request per second that is about 32 minutes, which is fine. Firing them all at once is how teams discover the concurrency limiter.

How do you run the migration? A seven-step checklist

Run the migration as a small project with named owners, written exit criteria, and a rollback decision. The sequence below fits a team of 10 to 50 people over three weeks.

1. Inventory and freeze (days 1–2). List every project, its owner, and its last activity date. Mark each as migrate, archive, or delete. Announce a freeze on structural changes: no new custom fields, sections, or automations.
2. Decide the mapping (days 2–4). Write one table: Asana section → destination status, custom field → destination field, tag → label. Every unmapped item gets a decision, even if the decision is “drop it.”
3. Export a pilot (day 4). Choose one medium-sized project with real subtasks and custom fields. Export as CSV and JSON, import into the new tool, and compare counts and values line by line. This is where you learn what will break.
4. Export everything live (days 5–6). Work project by project and store files by project name and date. Keep the JSON alongside the CSV, and version the files rather than overwriting them.
5. Rebuild configuration (days 6–9). Recreate statuses, templates, automations, and dashboards. Budget more time than the data import took. This is the part nobody estimates.
6. Cut over with a decision point (day 10). Name the person who decides go or no-go, the criteria (task counts reconciled, owners mapped, one full workflow tested), and the time by which a rollback must be called.
7. Hypercare (weeks 2–3). Keep the old workspace read-only rather than deleted. Run a daily 15-minute triage of “where is X” questions and set a date to archive the old tool.

The freeze in step 1 is not bureaucracy. If people keep creating sections and custom fields during the export, your mapping table is out of date before you finish building it.

Worked example: a 14-project migration

A 22-person agency has 14 Asana projects. Nine have not been touched in eight months. Five are live, with 1,920 tasks and 340 subtasks across 18 custom fields.

The work breaks down like this:

Spread across a project lead, an operations analyst, and two team champions, that is under two working days of combined effort, plus three weeks of calendar time. The calendar time is not waste; it is the period in which people stop asking where their tasks went.

For comparison: if five people each lose three hours of productivity to confusion on a badly handled cutover, at a loaded cost of $60 per hour that is $900 of avoidable cost. The verification work in step 3 costs less.

What are the most common migration mistakes?

Assuming one export covers the workspace. Project exports are per project. Teams that discover this on Friday afternoon either delay cutover or ship half the data.

Exporting everything, including the graveyard. Archived projects inflate the cleanup, import, and confusion. Migrate what is alive; archive the rest as files.

Treating comments as optional until someone needs one. Decision history is the hardest thing to reconstruct. Pull comments on active tasks before the old tool goes read-only.

Rebuilding the old tool exactly. Copying every field preserves habits that may be the reason you are leaving. Use the migration to remove two or three fields nobody used.

Deleting the source too early. Keep Asana read-only for at least a month. A month of licence cost is cheaper than reconstructing a decision nobody exported.

Skipping the pilot. A pilot export costs an afternoon and reveals the field-mapping failures that would otherwise surface in week two, in front of everyone.

No named owner for the cutover decision. A go/no-go with three possible deciders is a no-go by default, usually at 6 p.m. on a Friday.

> Practical tip: Keep a running “decisions and losses” note during migration. Every time you drop a field, a rule, or a report, write one line explaining why. Six weeks later, that note answers the question “why don’t we have that anymore?” without a meeting.

Is a clean start better than a full migration?

Often, yes. A clean start means importing only active work, recreating structure deliberately, and letting history live in an archive. It is faster, tidier, and forces the team to agree on how work should be organised. The trade-off is real. A clean start loses searchable history, breaks saved links, and can feel like the team’s past work was discarded. Regulated industries, client-facing teams with contractual record-keeping, and anyone who relies on old comments for audit reasons should migrate more, not less.

A middle path works well in practice: migrate all open tasks plus everything closed in the last 90 days, and export the rest to a read-only archive folder with a clear naming convention.

How do you handle the habit transition?

You handle it by naming champions, shrinking the first week’s scope, and making the new tool the only place work is assigned. Habits change when the old path stops working, not when the new path is explained.

Recruit two champions, not one. One per team or discipline. They answer questions in the team channel and collect friction reports.

Run a two-week parallel period with a single source of truth. Both systems exist, but only one is authoritative for new work. Announce which one in writing on day one.

Fix the top three complaints in week one. If the board columns are wrong, change them. Goodwill expires quickly.

How does Doitify fit into an Asana migration?

Doitify is a reasonable destination if you want project management, team workload, and goal tracking in one workspace rather than three tools. It supports Kanban boards, multi-level tasks and sub-tasks, checklists, owners and due dates, WBS dependencies, sprints and backlogs, Gantt and calendar views, workload and performance reports, project documents, meeting notes, risks, milestones, and import/export. Automations and team chat are included, and Copilot can help structure a plan from a stated goal.

Two honest limits. First, Doitify’s CSV import will not reconstruct years of Asana comment threads; archive those separately. Second, complex portfolio reporting across dozens of projects is better served by dedicated PPM software.

Transparency: Doitify is our product. We think it fits teams that want execution and goals in one place, and we would rather you compare it against your requirements than take that on faith.

Conclusion

Migrating from Asana is mostly a data-mapping exercise wrapped in a change-management exercise. The export is the easy part, and it is smaller than people expect: no comments, no attachments, no automations, one project at a time.

What determines success is what you do before the export and after the import. Archive aggressively, map deliberately, pilot on one real project, and keep the old workspace readable until the new one has earned trust. Do that, and migration becomes a fortnight of mild inconvenience instead of a quarter of lost history.

If this post on migrate from asana was helpful, you might also enjoy Project Management Software for Creative Agencies: 2026 Guide and Project Management KPIs: Metrics Every Manager Should Track.