Trello to Monday.com Migration Platform for 70+ Client Workspaces

Client context

Get Levrg runs client work for many accounts at once. Each client had its own Trello workspace, and the company decided to standardise on Monday.com. That meant moving more than seventy client workspaces, and the history inside them, without disrupting the client work running on those boards.

As AI Automation Lead at Get Levrg, I designed and built the migration platform and ran it.

The problem

Done by hand, every board, card, comment, and attachment would have to be recreated in Monday.com: weeks of error-prone work per batch of clients. There would be no audit trail of what had moved, and no reliable way to answer "did this card come across?" once the teams started working in the new boards.

There was a structural requirement too. The team works with two views of each client's work: a client-facing board and an internal board. After the migration those boards had to stay linked, with the right people assigned, rather than being two disconnected copies.

What I built

A Laravel web application on a service-layer architecture. Dependency-injected components keep each concern separate: a TrelloService reads from the Trello REST API, a MondayService writes through the Monday.com GraphQL API, a DataMapper translates between the two models, and an AuditLogService records every step.

Migrations run as jobs with real-time progress and a job history, so a batch of workspaces can be started, watched, and reviewed rather than babysat. The platform is deployed on AWS with GitHub Actions CI/CD, so fixes and mapping changes ship quickly.

• Configurable status mapping from Trello lists to Monday.com statuses
• Task-type synchronisation between the source and target boards
• Dual client and internal boards, created together and linked item to item
• Fuzzy name matching to assign each item to the right Monday.com member
• Rich imports: descriptions, comments, and attachments
• Board-level caching across REST and GraphQL API calls
• Real-time migration progress, job history, and full audit logging

Design decisions that mattered

Mappings as configuration, not code. Trello lists, labels, and task types differ from client to client. Keeping status and task-type mapping configurable meant a new variation was a settings change, not a code change.

Two boards, one job. Creating the client board and the internal board in the same job, and linking items as they were created, meant the relationship existed from the first minute instead of being reconstructed afterwards.

Matching people carefully. Trello and Monday.com accounts rarely share identical names. Fuzzy name matching assigns members automatically where the match is clear, because an item assigned to the wrong person is worse than one left unassigned.

An audit log as a product feature. Recording what each job moved turns post-migration questions into lookups, and gives the team confidence to retire the old boards.

Results

• 70+ client workspaces migrated successfully.
• Weeks of manual recreation replaced by monitored, auditable jobs.
• Client and internal boards stay linked after migration.

Stack