Migration
Asana to monday.com migration service
Asana lets one task live in several projects at once, nests subtasks as deep as anyone cares to go, and keeps custom fields in a library shared across the whole workspace. monday.com does none of those things: an item belongs to one board, subitems stop after one level, and a column exists only on the board it was created on. Moving the rows is straightforward. Deciding what happens to the work those three differences were holding together is the project, and it is what an Asana to monday migration service is for: settling each of those decisions with you before a single row moves.
The mechanics
What happens to a task that lives in three projects at once?
It becomes one item on one board, and the other two appearances become links or nothing. Multi-homing is the single feature with no destination equivalent, and it is usually load-bearing: the marketing task that also appears on the launch plan and the leadership roll-up is one record with one status, and after the move it cannot be.
Asana's shape. An organisation contains teams, teams contain projects, and a project is a set of tasks arranged in sections and viewed as a list, board, timeline or calendar. A task carries one assignee, a due date, followers, comments, attachments and custom fields drawn from a workspace-level library — define a field once, reuse it in twenty projects, report across all of them. Tasks nest into subtasks several levels deep, block or are blocked by other tasks, and can be multi-homed into any number of projects while remaining one record. Rules automate within a project, forms create tasks in one, and portfolios and goals roll several up.
monday.com's shape. A workspace contains boards, a board contains groups, and a group contains items. Everything about an item is a typed column that exists on that board only, so the same field in five places is five columns you keep aligned by hand. Items have subitems, exactly one level deep, with their own board-wide columns. Boards relate to each other through connect boards columns and mirror columns that display a linked item's value. Automations are recipes built from a trigger and an action, and they draw on a monthly action allowance that varies by plan. Dashboards, not projects, are where anything cross-board gets reported.
The consequence. Asana's structure is one flexible record model with a shared field library; monday's is a set of purpose-built boards you design. So the design happens before the export, not after it. Deciding which boards exist, which columns they carry, and what links to what is the actual work — and everything else is a load in the right order.
| Asana object | How Asana models it | Where it lands in monday.com | The decision it forces |
|---|---|---|---|
| Team | Groups people and the projects they own | A workspace, or a folder inside one | Whether the team boundary is a permission edge (workspace) or just tidiness (folder) |
| Project | A container of tasks, viewable as list, board, timeline or calendar | A board with its own columns and views | Which projects deserve their own board and which become groups on one shared board |
| Section | A heading that orders tasks inside a project | A group on the board | Whether a section that really meant status becomes a group or a status column |
| Task | One assignee, due date, followers, comments and custom field values | An item, with every attribute as a board column | Which task attributes become columns, given the columns exist on that board alone |
| Subtask | Nests several levels deep and does not inherit project membership | A subitem, exactly one level deep | What happens below level one: promoted to items, flattened into a checklist, or retired |
| Multi-homed task | One record appearing in several projects with one shared status | One item on one board; other boards get a connect-boards link | Which board owns the item, and whether the others mirror it or hold a copy that will drift |
| Custom field | Defined once in a workspace library and reused across projects | A column per board, plus mirror columns wherever it must be seen elsewhere | Which fields must exist on every board, and how they stay consistent with no library behind them |
| Dependency | Blocked-by and blocking relationships between tasks | A dependency column, with optional date-shift automations | Whether dates move automatically when a predecessor slips, and in which direction |
| Milestone | A task flagged as a milestone | An item marked by a status or timeline column | How milestones surface in dashboards once the flag itself no longer exists |
| Rule | Trigger, conditions and actions, defined inside one project | An automation recipe on one board, spending a monthly action allowance | Which rules are worth an allowance, which merge, and which belong in an external workflow tool |
| Form | An intake form that creates tasks in a specific project | A monday form creating items on a specific board | Who repoints every link, embed and bookmark, and the date the old form stops accepting entries |
| Portfolio and Goal | Roll-ups of projects and progress across the workspace | Dashboards fed by widgets, and mirror columns for cross-board values | Which roll-ups are real reporting needs, since each one has to be rebuilt deliberately |
| Comments and activity | A per-task story feed of comments and every field change | Item updates; the system activity feed starts empty | Whether discussion is carried as a digest on open work, or left in the archive entirely |
| Attachments | Files on the task, some uploaded and some linked from cloud storage | Files on the item, re-uploaded or re-linked | Which files move as files and which stay as links to the storage that already holds them |
| Task ID and permalink | A stable URL pasted into documents, tickets and chat | New item IDs; the old links stop resolving once the workspace closes | Whether the original Asana ID is carried into a column so old references stay traceable |
Dates are the quiet failure. A CSV export writes dates in whatever format the exporting account was set to, and a date column that arrives as text looks correct on screen while every timeline view, dependency shift and overdue automation silently ignores it. Date fields are normalised to the ISO 8601 date format (opens in new window) before the load, and the sample import is checked by sorting on the date column rather than by looking at it.
Sequence
How does an Asana Rule become an automation recipe?
By hand, and with a budget. Each Rule is opened, its trigger and conditions written down, and the nearest recipe built on the destination board. Two things change: recipes spend a monthly action allowance that depends on your plan, and a Rule with several branches usually becomes more than one recipe — or moves out of the tool entirely.
Board design before any export
Projects, sections, custom fields, dependencies and Rules listed on one page, each with a named board, group or column. Multi-homed tasks are listed separately, because each one needs an owner.
Scaffold, then load in two passes
Boards, groups, columns, every status label and every user created first. Items load in pass one; connect-boards links and dependencies are written in pass two, once every item has an ID to point at.
Sample import and reconcile
One real project first, counted in and counted out, with dates sorted, assignees checked and subitems opened by hand. This is where a silently-text date column or a dropped nesting level shows up.
Multi-homing is the decision that cannot be deferred
Export a workspace where a third of the tasks are multi-homed and the rows arrive once per project membership, which is how teams end up with three copies of the same task on three boards, each with its own status and none of them right. Every multi-homed task is listed before the export and given an owning board — usually the team that actually does the work rather than the one that reports on it. The other appearances become connect-boards links from a roll-up board, so the leadership view reads the real item instead of a copy of it. Where a second appearance existed only to make something visible in a weekly meeting, a dashboard widget replaces it and no second record is created at all.
Subtasks stop after one level
Asana teams nest freely, and it is normal to find checklists three levels below a parent task. monday supports one level of subitems, so each nested branch needs a decision made in advance rather than discovered by a truncated import: promote it to a full item with a link back to its parent, flatten it into a checklist on the item, or accept that nobody has opened it since last year and retire it. The related detail that catches people out is that subitem columns are defined once for the whole board, not per parent — so a subitem field that meant different things under different parents has to be reconciled to one meaning before anything loads.
Fields lose their library, so reporting is rebuilt
The custom field library is the feature Asana teams miss most, because a field defined once and reused in twenty projects is also a field you can report on across twenty projects. In the destination that becomes a column recreated on each board and mirrored where it has to be seen elsewhere, and the cross-project report becomes a dashboard widget. It is worth being blunt about the cost: mirrored values behave differently from native ones in filters and summaries, so the roll-up you had for free is now a thing that was designed. That design work is the reason this crossing is scoped as a project and not an import.
Access, tokens and the export itself
The export is done with a token that has broad read access to the whole workspace, and the archive that comes out contains everything the business considers confidential. It is handled as sensitive material — issued to a named person, stored where the client can see it, and revoked at the end rather than left live, which is the baseline the NIST small business cybersecurity guidance (opens in new window) sets for access of this kind. The same applies to the integrations hanging off the old workspace: the Slack app, the calendar sync and the reporting connector all keep working until somebody disconnects them.
Where this sits next to the rest of the work
This page is about moving work management: projects, tasks, subtasks, dependencies and the rules around them. If what you are moving to monday is a sales pipeline — contacts, accounts, deals and their associations — that is a different crossing with a different mapping problem, and our HubSpot to monday CRM migration page is written for it. Plenty of teams do both, in which case the CRM boards and the delivery boards are designed together and linked rather than merged. If you are staying on Asana and the real problem is that the Rules and intake have outgrown themselves, our Asana automation consultant page covers that work, and the monday.com automation consultant page covers the same ground once you have landed — board architecture, recipes and where the action allowance goes. For any other pair, the CRM migration services overview sets out the crossings we cover and the method that does not change with the platforms.
Some of what your Rules were doing should not live in a work-management tool at all. Logic that needs real retries, that reconciles two systems both claiming to own a field, or that has to read unstructured text and decide something belongs in a platform you also own — the territory of workflow automation proper, called from a webhook. How engagements work explains how a scope gets agreed before any of it starts.
The honest part
What genuinely cannot come across from Asana?
The history and the shape. Tasks, assignees, dates, custom field values, one level of subtasks and the project structure all move. The activity feed, the permalinks, multi-homing and the field library do not, because the destination has nothing to hold them. Rules are never imported; every one worth keeping is rebuilt.
| What | Treatment | Why |
|---|---|---|
| Tasks, assignees, dates and custom field values | Moves | They load cleanly once the board, every column and every status label exists first |
| Projects and sections | Moves deliberately | A project becomes a board or a group depending on how the team reports, and that is a design choice |
| Subtasks, one level | Moves | Subitems hold exactly one level, with columns defined once for the whole board |
| Subtasks below level one | Decided per branch | There is no second level to import into, so each branch is promoted, flattened or retired |
| Multi-homed tasks | Rebuilt as links | One record cannot live on two boards, so one board owns it and the others connect to it |
| Dependencies | Moves in a second pass | They can only be written once every item exists and has an ID to point at |
| Rules | Rebuilt | They do not export, and recipes spend a monthly action allowance that the rebuild has to respect |
| Forms and intake links | Replaced | Anything still pointing at the Asana form keeps creating tasks in the workspace you are leaving |
| Portfolios and goals | Rebuilt as dashboards | Roll-ups are a reporting layer in the destination, assembled from widgets and mirror columns |
| Attachments | Moves deliberately | Uploaded files are re-uploaded; files that were links to cloud storage stay links |
| Comment and activity history | Stays behind | The story feed belongs to the system that recorded it; open work can carry a pasted digest |
| Task permalinks and IDs | Stays behind | New IDs are issued on load, so the old ID is carried into a column to keep references traceable |
| The custom field library | Rebuilt per board | There is no workspace-level field library, so consistency becomes a convention somebody owns |
You own the result outright: boards in your own account, an object map showing where every project, section and field went, a written decision per multi-homed task and per nested branch, recipes documented against the Rule they replaced, and a note of what was deliberately left behind. We are an independent consultancy working inside your account through each platform's own interface and API; we hold no partner or certification badge from either vendor and will not imply one. If your own team would rather run the load, we design the boards and build the scaffold and stay on as backup — and if the honest answer on the call is that your Asana workspace is fine and the real problem is the intake feeding it, that is what you will hear.
Questions
Common questions before leaving Asana
Can we just connect Asana to monday.com, or export it ourselves?
That depends on whether you are leaving. A sync connector keeps both tools live side by side and moves data only for the fields you map, which suits a team not yet leaving Asana. A CSV export you run yourself gets the tasks out but loses multi-homing, subtasks below one level and every Rule, which is fine for a simple project board. A migration designs the monday.com boards first, then loads in two passes — items, then the links and dependencies between them — so nothing lands in the wrong column. The board design and load sequence above sets out how.
Do Asana Rules import into monday.com automations?
No. Rules are defined per project in Asana and there is no export format any other tool reads, so each one is opened, its trigger and conditions written down, and the equivalent recipe built on the destination board. Two things change in the rebuild: recipes consume a monthly action allowance that depends on your plan, and anything too complex for a recipe moves to an external workflow tool instead.
What happens to a task that is multi-homed into several projects?
It has to become one item on one board, because nothing in monday.com shows the same record on two boards with one shared status. Every multi-homed task is listed before the move and given an owning board, and the other appearances become connect-boards links or are dropped. Duplicating the item instead is the tempting option and the one that guarantees two copies drifting apart.
Do subtasks survive the move?
One level does. An Asana subtask becomes a monday subitem, and subitem columns are defined once for the whole board rather than per parent. Anything deeper than one level has nowhere to go, so each nested branch is decided in advance: promoted to a full item with a link to its parent, flattened into a checklist on the item, or retired because nobody has touched it in a year.
Do comments and task history come across?
Not as a feed. Comments can be carried as a pasted digest into the item update thread, but the activity stream itself — who changed which field when, and every automated entry behind it — belongs to the system that recorded it. The usual decision is to carry the discussion on open work only and leave closed projects in a read-only archive with the export retained.
Will our old Asana task links still work after the move?
No, and that is worth planning for. Item IDs are issued by the destination, so every Asana permalink pasted into a document, a ticket or a chat message stops resolving once the workspace is closed. We carry the original Asana task ID into a column on every item, so a search on the old ID still finds the work it refers to.
Free consultation
Tell us what is costing you the most time
Describe the process. You get a straight read on whether it is worth automating, roughly what it would take, and what we would tackle first — on a call that costs nothing.
- Under an hour, free, and no obligation
- Fixed price per stage, agreed before any work starts
- You own everything we build, documented and in your accounts
- If you do not need us, we will say so on that call
The form is the fastest way to reach us — we reply from a real person, usually within one business day.
Not sure which migration is right? See the CRM migration services overview.