How to migrate an architecture firm from Asana to monday.com without losing a task.

Most migrations go wrong before the first task moves, because nobody counted what was in the old tool. The next most common failure is a script that creates duplicates when restarted after a network error. This method closes both gaps. It's written for an architecture studio moving from Asana to monday.com. Every number comes from one real run: a seven-person Los Angeles studio, migrated on August 24, 2026.

Step 1 Read everything first and save a full export

Before designing anything, export every project and task through Asana's API, read-only, with a task count per project. Save it to disk: that file is the baseline for the rest of the migration, and every later count reconciles against it.

For Studio Yona the export held 88 active projects and 2,487 tasks, against notes that said 82 and 1,532. The first full read came back short too, because of a pagination trap worth knowing about. Asana's next_page object carries a path that omits the /api/1.0 prefix, and following it returns the web app's HTML instead of JSON. Every project over 100 tasks then silently comes back as exactly 100, and it all reads like a rate limit. Use next_page.uri instead: that one bug was hiding 626 tasks across four projects.

The export also shows what structure exists, which decides Step 3. Here, every one of the 88 projects had a single section named "Untitled section". Of 2,487 tasks, 2,256 (91 percent) were already complete, 95 percent carried a due date and 253 had notes. The whole workspace held one email address and four phone numbers, and two project numbers were each used twice. Each of those facts changed the plan.

One note on access: a browser login to Asana is enough to call its API read-only from inside the Asana web app. That skips the personal access token, which matters because an Asana token cannot be limited to read-only. It would carry the owner's full permissions until someone remembers to revoke it.

Step 2 Decide what moves and what stays

Studio Yona's rules: every task on an active project moves, completed ones included and marked complete, so no project arrives looking thinner than it was. Archived projects stay in Asana; 60 of them, holding 1,668 tasks, stayed on the principal's instruction. The studio's own template projects stay behind too, because they had already been used to confirm the new project template's group structure. A test project stays behind as well, and so do two lists of tasks reassigned from people who had left.

Some Asana entries are workstreams, not projects. Four mapped onto office workstreams already on a Studio Ops board: Business Presence (47 tasks), ARE exams (39), Attendance (12) and Marketing (5). A fifth, a 162-task 3D rendering workstream of per-client billable work, had no home in the new structure, so it got its own board. Filing it under "Admin / Other" would have stripped the client link off every task. Write down what moves and what stays, and have the principal sign it before anything runs.

Step 3 Map the structure honestly

If the source has no sections, keep it flat, even though sorting 2,109 tasks into the template's 14 phase groups by keyword is tempting. A task under the wrong phase is worse than a task under none. Each migrated board is duplicated structure-only from the project template, so it arrives with the Gantt and calendar views, which come from the interface rather than the API. Its 14 empty groups are then replaced by one "Project Tasks" group holding the tasks as they were. The template's phase groups are for the projects the studio starts from now on.

Completed Asana tasks become Done and the rest Not Started; a due date becomes a one-day timeline, so the Gantt fills with real dates. Assignees with a monday.com seat map to the Owner column; anyone else's tasks arrive unassigned, with the name kept in Notes. At Studio Yona that was 268 tasks across three people, and seats are the principal's call, not the migration's. Drop a project-name prefix from a task name only when it matches that project; stripping blindly mangles auto-generated names like Follow up on "...". Then tell the principal the prefixes were dropped, or it reads as data gone missing.

Step 4 Clean up the new account first

Two things happen in the new account before a single real task lands. First, delete the demo data: at Studio Yona, 33 fictional rows and two demo boards. That was a correctness requirement, not tidiness, because the export proved one demo project carried the wrong number.

Second, repoint any automation on the project template. Duplicating a board copies its automations, so a wrong rule on the template lands on every board, and each copy needs fixing later. The template's two automations notified the consultant who built it. Repointing them to the task's owner before the run meant 77 boards notifying the right person, not 154 automations notifying the wrong one.

Step 5 Pilot 5 to 10 projects and get the principal's approval

Migrate a handful, reconcile them and show the principal before touching the rest. Studio Yona's pilot was 9 boards and 229 tasks, and all 9 boards reconciled exactly. The two projects sharing the number 2634 moved as they were, on purpose, so the duplicate showed on screen instead of being quietly fixed. In the pilot the principal sees what a migrated board looks like: one flat group, statuses and a Gantt with real dates. They approve the mapping or change it while changing it is cheap.

Step 6 Run the full migration, tracking each project by its Asana ID

The script tracks every project by its Asana id (the gid) and records it in a state file only when the project fully succeeds. Success means the board is created, its tasks written, its overview row linked and the board filed in its folder. The next run skips anything already recorded, so it's safe to stop and restart without importing anything twice. When a run fails mid-project, you know exactly what's left: five boards failed here on temporary monday.com server errors, each leaving an orphan empty board. Those orphans had to be deleted before the retry, or the retry would have made duplicates.

The script has a dry-run mode that reports what it would do and writes nothing. Another option runs a single project by number, and a limit sets how many projects one run takes. Boards, named with the project number and address, land in per-year folders and link back to a Projects Overview row that carries the number. The studio's numbering service, which issues project numbers, adopts the number already in each name instead of issuing a new one. That keeps a 2022 job from being renumbered into 2026 on migration day.

Step 7 Reconcile counts in both directions

For every source project, count the tasks in Asana and the items (rows) on the new board; they must match. Then go the other way: check that every item on a migrated board traces back to a source task, which proves nothing was created twice. Studio Yona: 77 of 77 boards, 2,109 of 2,109 tasks, zero mismatches.

A one-way total misses things: a task imported twice on one board and a task missing from another cancel out in a grand total. They show up only when you reconcile per project in both directions. The Step 5 pilot is reconciled the same way, which is how the method gets tested before it's trusted.

Step 8 Verify against the live account

Reconciling counts proves the migration, but not that the system still works afterward. The verifier is a script that reads the live account and checks everything the system depends on. Every board the studio's custom apps use must exist, along with every column id and status label they write. Every project board must sit in a folder, the Leads group must be empty and the numbering service must see no unreported duplicates. For Studio Yona it runs 42 checks and ends with an error if any of them fails.

After the migration it caught all 77 overview rows sitting in the Leads group, where the numbering service ignores them by design. They were moved into groups by stage, and the check now confirms the group stays empty. It runs again after every later change, because a migration is checked once but the system it leaves behind keeps changing.

Step 9 Never delete anything the client created in the old tool

Asana stays: the archived and migrated projects stay in it, and the studio keeps its login. The migration only reads the source, so if a mapping proves wrong a month later, you redo it from Asana. Deletions happen only in the new account: the demo data and any boards left over from failed runs. After the principal's sign-off, boards whose every task was already complete can go too. At Studio Yona that meant 23 boards holding 389 tasks, deleted with their overview rows kept so the numbering service never reissues those numbers.

The Studio Yona numbers

Trello, Monograph and spreadsheets

The nine steps hold; the mapping in Step 3 changes.

Trello to monday.com. A Trello board becomes a monday.com board: lists become groups, cards become items (rows) and each card's checklists become subitems. Labels become a status or tags column, and due dates become timelines. Trello exports one JSON file per board, and the script tracks each card by its id. Comments and attachments stay behind, as the next section explains.

Monograph to monday.com. Projects become overview rows and per-project boards, and phases become both the project board's groups and the fee phases on the private Contracts board. That split between design phases and fee phases is the main reason a studio leaves Monograph for a system it can shape. Time entries stay off the project boards, in a read-only Monograph account or a CSV archive, and monday.com's time-tracking column takes over from the cutover date. Invoices already in QuickBooks stay there, linked from monday.com rather than recreated, and the monday.com vs Monograph comparison covers when the move makes sense.

Spreadsheets to monday.com. One row per project becomes the Projects Overview, identified by project number, and a tab per project becomes its board. The work is cleaning, not scripting: dates in three formats, a client spelled two ways, a phase column that was free text for five years. Reconciliation is row by row against the original sheet, which is kept.

What does not migrate, and what to do about it

Attachments and comments stay where they are, because copying them across produces a worse record than leaving them. The migrated item links to the project's Dropbox folder, and the old tool stays readable for history. Time entries, where the source has them, go to a CSV archive. Change history (who moved what, and when) stays behind, and nobody has asked for it after a migration yet.

Custom fields are a per-field decision: each maps to a column or is dropped on purpose, and Studio Yona's Asana had none to map. Client and fee data usually comes from outside the source, as it did here: the principal's contract sheet, loaded in a separate pass. It was matched on address rather than folder number, because the two numbering systems disagreed.

What the migration costs

The move is priced into the fixed quote we send after a free review, and Full System, from $7,000, includes it. The number of projects sets the size of the move: 30 projects make a small one and 200 a large one. Structure worth keeping adds work, because sections that map onto phases take longer than a flat list. So does mapping people, clients and a second workstream as well as tasks. Studio Yona's run, 88 projects with no structure, two passes and a separate load of client data, was a large one.

Elapsed time is one week, mostly reconciliation and the pilot review. Extra work, such as writing code to read an unusual export, goes into the same fixed quote.

If your studio is moving to monday.com from Asana, Trello, Monograph or spreadsheets, book the free 30-minute review. Bring the export if you have one; if not, making one is the first step.

Read the full Studio Yona case study