Trello to Monday.com Migration: The Checklist and the Scripted Approach

The pre-migration checklist

Before anything moves, list these for every board. A spreadsheet is fine. This is the document that turns "migrate our Trello" into a scoped job.

Decide the target structure first

The most valuable hour of a migration is spent deciding what the Monday.com side should look like, before writing a line of code or clicking import. Three decisions matter most.

Status mapping. Trello lists like "To Do", "Doing", "Client Review", and "Done" usually become a single status column. Write the mapping down as a table, list name to status label, per board if boards differ. Make it configurable rather than hard-coded, because some boards will always be exceptions.

Board topology. Agencies often need two views of the same work: a client-facing board the client can see and an internal board with internal notes, estimates, and task types. If that is you, decide now how items on the two boards link, which side is the source of truth for each field, and what happens on rename or delete.

Member mapping. Match every Trello member to a Monday.com user. Exact matches on email are ideal, but you rarely have Trello emails for everyone, so plan for name matching with a manual review list for anything ambiguous. An item assigned to the wrong person is worse than an unassigned one.

What to test in any importer before trusting it

For a handful of simple boards, a built-in or third-party importer may be all you need. Whatever tool you use, run it on two or three representative boards first and check these by hand on the result:

• Are card descriptions complete, including formatting and links?
• Are comments present, in order, with the original author and date visible somewhere?
• Do uploaded attachments open from Monday.com, and do linked files still point to the right place?
• How did checklists come across, and are completed checklist items still marked done?
• Did labels land in a column you can filter and report on?
• Are people assigned, and are they the right people?
• Are due dates correct in your time zone?
• Were archived cards included or skipped, and is that what you wanted?
• Can you tell, afterwards, exactly which cards moved and which did not?

If the answers are fine for your boards, use the importer and save the money. If several are "no" and the history matters to you, that is the point where a scripted migration earns its cost.

How a scripted migration works

A scripted migration reads from the Trello REST API and writes through the Monday.com GraphQL API, with your mapping decisions in between. The engineering that matters is less about the API calls and more about everything around them.

Rate limits and batching. Both platforms limit how fast you can call them (see the Trello and Monday.com docs). Read in pages, write in batches, back off when told to, and run large migrations as queued jobs rather than one long script that dies halfway.

Idempotency. Every migration gets interrupted at least once. Record which Trello card produced which Monday.com item, so a re-run continues where it stopped instead of creating duplicates.

Dry runs. Run each board into a test workspace first. The client or team lead reviews it there, and only then does it run for real.

Linked boards. If you keep client and internal boards, create items on both and link them as part of the same job, so the relationship exists from day one rather than being stitched together later.

Fuzzy member matching. Match Trello members to Monday.com users on normalised names, accept only confident matches automatically, and put the rest on a review list.

An audit log. Log every board, item, comment, and attachment the job handled, plus every failure with its reason. When someone asks "did card X come across?", the answer is a lookup, not a guess.

A cutover plan that does not lose work

1. Pilot. Migrate two or three representative boards, review them with the people who use them, and adjust the mappings.
2. Batch the rest. Move boards in groups (by client or by team) so each group gets reviewed while it is fresh.
3. Freeze per batch. Tell each team when their boards move, and stop edits in Trello for that batch on migration day.
4. Verify. Compare counts from the audit log against the source boards and spot-check items with attachments and long comment threads.
5. Keep Trello read-only. Leave the old boards accessible, read-only, for a few weeks. Someone will want to check something.

How I built it for 70+ client workspaces

At Get Levrg, the job was to move 70+ client workspaces from Trello to Monday.com. Doing it by hand meant recreating every board, card, comment, and attachment, with no audit trail and no way to keep client and internal boards linked. So I built a Laravel web application to do it.

It uses a service-layer architecture with dependency-injected components: a TrelloService and a MondayService for the two APIs, a DataMapper for the translation, and an AuditLogService that records what happened. On top of that sit configurable status mapping, task-type synchronisation, dual client and internal boards with item linking, fuzzy name matching for member assignment, and rich imports of descriptions, comments, and attachments. Migrations run as jobs with real-time progress, job history, and full audit logging, and the platform is deployed on AWS with GitHub Actions CI/CD.

The result: 70+ client workspaces migrated, weeks of manual recreation replaced by monitored, auditable jobs, and client and internal boards that stay linked after the move. The full write-up is in the Trello to Monday.com migration case study.

Frequently asked questions