Asana to ClickUp Migration: Six Things the Importer Skips

Forty minutes after you click Start import, ClickUp emails to say it is done. The Spaces are there. The task counts look about right. Then somebody opens the client onboarding checklist that used to carry three levels of subtasks and finds the third level gone — not flattened, not renamed, simply not where it was.

That one is on the list. ClickUp publishes a list. It sits at the very top of the import article, above the instructions, under the heading What data does not import?, and it gets skipped because the part of the page that looks useful is the numbered steps underneath it.

Six rows. Treat each one as a piece of manual work you have already agreed to do, because that is what it is.

Six rows, and where the work actually has to happen

Now read the second column again and count how many of those instructions begin with the words In Asana. Four of them do.

That is the whole trap. Four of the six fixes are not things you do when you notice something missing in ClickUp. They are things you had to do in the old system, before you authorised the connection, while you still had a search box that could find recurring tasks and a permissions model that could see private ones. Once the Asana subscription lapses into read-only, "add a note to recurring tasks" stops being a job anybody can perform.

And @mentions is the only row that arrives with no remedy at all. What the page commits to is narrow: the mention does not import. Whether the comment around it lands with the person's name as plain text, or with a hole where the name was, is not stated either way — which makes it something to check on five real tasks rather than something to assume.

Nested subtasks are a hierarchy problem, not a missing-rows problem

Asana lets you put subtasks under subtasks. Teams that have lived in one workspace for three or four years always have a few structures deeper than anyone intended, usually a checklist that grew a second checklist inside one of its items.

ClickUp's suggested fix — move the nested subtasks into their parent tasks, by hand, in ClickUp — implies the records survive and the relationships do not. But "the child task is gone" and "the child task is present and orphaned" look identical from the parent task's screen, and they are completely different amounts of work. One is a rebuild. The other is re-parenting.

So map the deep structures before you start rather than after. With API access, walking GET /tasks/{task_gid}/subtasks and recursing on each result gives you a depth map of a project in a few minutes. Without it, the practical version is asking the two or three people who build the most elaborate checklists to name theirs.

Then run the test import that gets thrown away — the middle step in the 30-day switch runbook exists precisely so questions like this get settled by observation instead of by reading a help page twice.

One task in two projects is a decision you make on the Asana side

Asana's multi-homing — the same task appearing in the design project and the launch project, one record with two memberships — has no clean equivalent on the other side unless you have turned on ClickUp's Tasks in Multiple Lists ClickApp. Hence ClickUp's instruction to annotate those tasks in Asana first and re-add them to multiple Lists afterwards.

Finding them is the part the help page skips. A task's projects and memberships fields in the Asana API tell you which records live in more than one place. A project-by-project export only tells you if the export carries a stable task identifier you can match across files, which is worth confirming before you build a spreadsheet on top of that assumption.

What ClickUp's page does not say is which project wins when a multi-homed task is imported without the preparation. Fine — that just means it belongs in the throwaway import, with two deliberately multi-homed test tasks, rather than in a plan.

The mapping screen decides more than it appears to

After you authorise, ClickUp shows an Import options page. Five choices, and they are not equally reversible.

Projects. A new Space per project, a new Folder per project inside a Space you pick, or a customised mapping project by project. The Folder route is what keeps a twelve-project workspace from becoming twelve Spaces.

People. Invite people who do not already match a ClickUp user by email address, customise the mapping person by person, or do not import new people at all. ClickUp prints the consequence in the same table: "Inviting people can incur charges." A billing decision, sitting inside an import wizard, beside four choices that are not billing decisions.

Sections. This is the structural one. Asana sections can become Label Custom Fields — ClickUp describes that option as "keeping both the section and completion state" — or a separate List each, or task statuses. ClickUp's own steer is that sections used as a workflow, the to-do / in-progress / done kind, should map to statuses. Sections used as categories should not. If your workspace runs both patterns in different projects, the per-project customise option is the only honest answer, and it is worth the extra ten minutes at the screen.

Completed tasks and Attachments are yes/no toggles. Turn completed tasks on, or no count you take before the import will ever reconcile with a count you take after it.

The sections question is answerable before you ever reach that screen, and answering it in writing beats answering it in the moment. Asana's project object carries a default_view field, documented as "the default view (list, board, calendar, or timeline) of a project" and limited to those four values (Asana developer reference, checked 18 August 2026). Pull it across every project and you have a first cut of the split: board projects are where sections tend to be workflow columns, list projects are where they tend to be headings. Tend to be, not are — so the query gives you a shortlist to walk through by eye, not the mapping decision itself.

Attachments have a size nobody will tell you in advance

ClickUp is unusually blunt here: "Asana does not provide a way to calculate the amount of data in your attachments, so you'll only know after the import has been completed." If you are on the Free Forever plan and the import pushes you past the storage limit, the documented remedy is deleting attachments afterwards until you are back under it.

A second attachment problem hides behind the storage warning, and it survives on every plan. An Asana attachment is not necessarily a file. The API's attachment record carries a resource_subtype describing "the service hosting the attachment", with valid values of asana, dropbox, gdrive, onedrive, box, vimeo and external. Only the first is a file Asana holds. The rest are pointers into somebody else's permission system — frequently the Drive folder belonging to the person whose departure started this whole project.

Asana's own upload endpoint confirms the direction of travel: the docs state that "it is not possible to attach files from third party services such as Dropbox, Box, Vimeo & Google Drive via the API." No migration tool, ClickUp's or anyone else's, can turn a gdrive attachment back into a stored file. It can only carry the link. Count your attachments by subtype before you start and decide which of those links you need to convert into real files by downloading and re-uploading them yourself.

One more thing the API docs mention and the app does not: GET /attachments for a task returns inline images from the task description as well, even though those never appear in the app's thumbnail index. If your team pastes screenshots into descriptions, your real attachment count is higher than the number you are looking at.

Comments arrive, but an archive is a separate job

Comments are not in ClickUp's exclusion table. Neither are dependencies, nor custom fields. Silence in a vendor document is not a commitment, though. It is just silence, and the fix for silence is a count rather than an interpretation.

Keeping your own copy is a different project from the import, and it is the one people postpone. A copy living inside ClickUp is a copy inside a product you will also leave one day. Asana's help article on project importing and exporting gives you the mechanics — project header drop-down, Export/Print, JSON or CSV — and does not enumerate what those two files leave out. For anything conversational, plan on the API.

The API has tiers, and they matter more than the endpoints do. Asana's export documentation states that graph exports are "only available to accounts of an Enterprise/Enterprise+ organization", and that resource exports are "only available to Service Accounts from an Enterprise+ organization or an organization with the Compliance Management Add-on". A ten-person company on Starter or Advanced has neither, which means walking the per-object API at 150 requests per minute on a free domain, 1,500 on a paid one.

Three details that wreck scripts written by people who have not hit them yet:

• Attachment download_url values expire fast. Asana's reference says the URL "may only be valid for two minutes from the time of retrieval" and advises refreshing on demand rather than storing it. A script that collects every URL in one pass and downloads in a second pass builds a directory of dead links. Fetch and write in the same loop.
• If you do have the resource export, its output is JSON Lines inside a gzip container, stories (Asana's word for comments and change events) are included by default, attachment objects in the file "do not include download_url or view_url", and access to the export file "expires 30 days after its completion". One export per workspace at a time; a second request returns 403.
• Dependencies cap out low. "A task can have at most 30 dependents and dependencies combined," which is the rare piece of good news here — a graph that small is genuinely rebuildable by hand if it does not survive the crossing.

Custom fields deserve their own pass. Asana's field types are date, enum, multi_enum, number, people, reference and text, and the two that land wrong most often are people, because it depends on the same email matching you configured on the mapping screen, and multi_enum, because a multi-select has more ways to arrive half-populated than a single-select does. The discipline is the same as with any export you are trusting with history: open the file and check five records by hand, the way the Slack export breakdown does for message archives.

It also helps to know how much of Asana is not a task, since a table about tasks can only ever be silent about the rest. The developer reference indexes separate resources for Goals, Portfolios, Project briefs, Project statuses, Status updates, Rules, Project templates and Task templates, among the forty-odd it lists (Asana API index, checked 18 August 2026). None of those appears in ClickUp's six rows, and the absence carries exactly the weight the absence of comments did: unstated, not promised. Project briefs repay a manual check, because a brief is often the only surviving explanation of why a project was scoped the way it was.

Five counts before, the same five counts after

Write them down. A count you took but did not record is a memory, and memories reconcile beautifully.

1. Tasks per project, completed ones included.
2. Attachments by resource_subtype, split into asana and everything else.
3. The deepest nested subtask you own, by name, so you can search for it on the other side.
4. One task living in two projects — which List did it land in?
5. One recurring task — is the recurrence rule there, or only the next instance?

The hour before you authorise is the cheapest hour in the switch

Four of the six exclusions have to be handled inside a system you are about to stop paying for. That is the shape of this particular migration, and it is why the Asana-side inventory is not preparation for the real work. It is most of the real work. The import itself is a progress bar.

The quiet part comes afterwards. Nothing on ClickUp's list mentions the automations still pointing at the Asana workspace, which will keep authenticating perfectly against a system nobody updates any more — that failure mode is why a zap keeps running and stops mattering.

One more thing outlives the cancellation and sits on neither vendor's list. Asana's guidance on personal access tokens states that they are "persistent by default" and that a user "can create many, but not unlimited" of them, the standing advice being to review the list periodically and deauthorise whatever is no longer needed (Asana developer docs, checked 18 August 2026). A token issued two years ago by someone who has since left is a live key into a workspace nobody is watching any more. Open that page while an admin still has access rather than afterwards.

---

Verified against ClickUp and Asana documentation on 18 August 2026. The exclusion table, the mapping options, the attachment-size warning and the import duration all come from ClickUp's Import from Asana article. The export route — the drop-down beside the project title, then Export/Print, then JSON or CSV — comes from Asana's project importing and exporting page. The rate limits, export tiers, download_url expiry, attachment subtypes and dependency cap come from Asana's developer reference, whose full index is published at developers.asana.com/llms.txt.

Six is the count on the day I read the page. Neither company announces an edit to a help article, and an exclusion table is exactly the kind of thing that grows a seventh row between one visit and the next — so open both pages yourself before you authorise, not afterwards when you are trying to work out what happened. Spot a quotation here that has drifted from its source and the contact page will get to me; I would rather re-date this page than leave a stale sentence standing on it.