The Definitive Guide to Migrating to Trello

Trello is a kanban-style list-making application originally built by Fog Creek Software in 2011, spun out as an independent New York City company in 2014, and acquired by Atlassian in January 2017 ¹. It now sits alongside Jira, Confluence and Bitbucket inside the Atlassian Cloud portfolio and shares its identity, billing and data-residency plumbing with the rest of that stack.

The typical Trello customer is a 5 to 200-person team — marketing, ops, product, agency, education — that wants visible boards and minimum process overhead, not the work-graph density of Jira or the database-of-tasks model of monday.com or ClickUp. Compared with Jira, Trello positions on speed of setup and a lower cognitive floor; compared with Asana or ClickUp, it positions on visual simplicity rather than hierarchy depth.

The shapes of migration that actually land on Trello tend to fall into four patterns. First, downscaling projects: teams leaving Jira, Asana or ClickUp because the heavier tool was overkill for how they actually work day to day. Second, consolidation from spreadsheets, Notion task databases and email threads into a single shared board.

Third, Atlassian alignment, where an organisation already on Jira or Confluence wants the lighter-weight teams (marketing, HR, legal) on the same identity and billing fabric without forcing them into Jira's complexity. Fourth, departmental rollout, where one team's success with Trello pulls in adjacent teams that import their existing checklists, briefs and task lists. Each shape has a different difficulty profile — a Jira-to-Trello downscale loses dependencies and custom workflows, while a spreadsheet consolidation is mostly CSV mapping and Power-Up wiring.

What makes migrating *to* Trello easier than the category average is the simplicity of the destination schema — five card field types, one universal kanban metaphor, and a predictable JSON board format. There is no Apex, no formula language, no per-object permission matrix to translate against.

What makes it harder than the average is the flat hierarchy — there is no native Project or Task-Subtask construct, so source structures with three or four levels of nesting have to be flattened into Workspaces, Boards and Cards before they fit. Native dependencies, time tracking and recurring tasks do not exist out of the box and must be bought back via Power-Ups, several of which are tier-gated ¹¹.

Custom fields, Butler automation quotas, and Power-Up counts all scale with paid tier — free boards cap at one Power-Up and no custom fields, which traps teams who scope a free-tier migration only to hit Power-Up paywalls on cutover day ¹¹. Teams that price the destination tier honestly up front finish on time; teams that assume free will do the job do not.

Teams that price the destination tier honestly up front finish on time; teams that assume free will do the job do not.

Trello's data model is small enough to fit on a napkin, which is both its biggest strength and the source of every migration pain. Everything hangs off a five-level hierarchy: Workspace → Board → List → Card → Checklist item / Comment / Attachment. There is no native Project, Task-Subtask, cross-board link, or dependency — those concepts are replicated structurally or layered in via Power-Ups.

Before you can map a field on the source side, you need to know which destination object owns the row and what identifier survives across re-imports. The table below summarises the objects you will touch in a Trello migration.

The thing Trello does not have, and the single most-important fact for a migration practitioner, is a user-controlled unique key on cards. Cards have a Trello-generated id (24-char hex) and a short idShort (#123) that is unique within a board only — there is no External ID field type in core Trello, and the Custom Fields Power-Up does not enforce uniqueness on any field type.

The mitigation, used by every serious Trello migration, is to create a Single-Line Text custom field called *Legacy ID* or *External ID* on each target Board and stamp the source primary key into it on every card. Reconciliation then joins on that field rather than on Card name (which is not unique and is mutable). The Custom Fields Power-Up surfaces the field on the card so re-imports stay deterministic ¹³.

Custom fields themselves are tier-shaped and shape every mapping decision. The catalogue below covers what you can model and the limits you need to plan around.

Relationships in Trello are mostly implicit. Lists are ordered children of a Board, Cards are ordered children of a List, and Checklists/Comments/Attachments are ordered children of a Card. There is no native many-to-many: cross-board linking is done with a card URL pasted into another card's description, which renders as an *Attachment* link rather than a structured relationship.

Parent/child between cards (epics, sub-tasks) does not exist in core Trello — it is added by Power-Ups such as Hello Epics or Placker, each with its own data model that lives partly in Trello attachments and partly in the Power-Up's pluginData blob. Cascade-delete is not configurable: deleting a Card removes its Checklists, Comments and Attachments, but deleting a List leaves orphaned Cards archived rather than removed.

The single best predictor of a clean Trello migration is how much structural work you do on the source side before you decide which Workspace and which Boards a row lands on. Because Trello's hierarchy is flat, projects, sub-projects and tagged work that lived under nested folders in Jira, Asana or ClickUp have to be re-shaped to fit Workspace → Board → List on the way in.

The single best predictor of a clean migration is how much structural work you do before deciding which Workspace and Board a row lands on.

Treat the source export as raw material that needs to be flattened. A Jira project with epics, stories and sub-tasks does not map one-to-one — it needs an explicit decision on whether epics become Boards, sub-tasks become Checklist items, or a Power-Up such as Hello Epics is bought to preserve the hierarchy.

Source-side prep

• Decide the hierarchy collapse rule first. For each source level (Portfolio, Project, Sub-project, Task, Sub-task), declare which Trello object it becomes (Workspace, Board, List, Card, Checklist item). Do this on paper before you write a single CSV.
• Stamp a stable Legacy ID on every source record — Jira key, Asana GID, monday.com pulse ID — and reserve a *Legacy ID* text custom field on every target Board to hold it ¹³.
• Normalise dates to ISO-8601 with timezone. Trello stores dates in UTC; relative date strings from source platforms (tomorrow, +3d) must be resolved before import.
• Resolve members to Atlassian accounts in advance. Trello uses Atlassian's unified identity — owner assignment fails silently if a referenced member is not yet on the Workspace.
• Decide what to do with attachments at scale. The 10 MB Free / 250 MB paid per-file cap is enforced on inline uploads but not on links from Google Drive, Dropbox, Box or OneDrive ⁵¹⁹. For large estates, prefer external links.

Destination-side prep

• Provision a Workspace at the right tier — Free, Standard, Premium or Enterprise — sized for the worst case. Free caps at one Power-Up per board and 10 collaborator boards per Workspace ¹¹.
• Pre-create every target Board with its Lists in the right order. Importer tools that auto-create Lists from CSV columns tend to leave them in the wrong sequence, and re-ordering 30 Lists by hand on cutover day is its own small migration.
• Enable the Custom Fields Power-Up on each target Board and define every field definition before importing Cards. Definitions are Board-scoped; the same name on two Boards creates two unrelated definitions.
• Build the Workspace member list by inviting Atlassian accounts before card import so member-mention assignment resolves on the first pass.

People prep

Cutover only works if humans cooperate. Lock down a source-system freeze window — 24 to 48 hours for kanban migrations, longer when historical activity is in scope — and communicate it to every team. Train members on Trello card conventions, label use, and Butler automation before go-live. A typical small-team migration runs one to three business days; a multi-Workspace rollout with custom fields, Power-Ups and Butler rules runs one to three weeks of elapsed time.

Trello exposes three load paths and the right one depends on dataset size, attachment volume, and whether you need the load to be repeatable. Native Trello has no first-party CSV import wizard the way HubSpot or Salesforce do — bulk CSV is handled by Power-Ups and third parties.

Paste-to-create

The lightest path: copy a column of text from Excel, Google Sheets or another app, click into an empty List, and paste. Trello creates one Card per line. This is fine for under-100-card seed loads where the only fields are card titles, but it does not handle descriptions, members, labels, due dates or custom fields and has no idempotency model — re-pasting creates duplicates.

CSV / Excel via Power-Up

Power-Ups such as Blue Cat Reports' *Import to Trello*, Import2, and Skyvia accept CSV or Excel and map columns to Card fields including title, description, list, due date, labels and Custom Fields. Blue Cat Reports advertises no row limit per import and supports checklists via repeated checklist-item columns. The right call for one-shot loads of a few thousand Cards on standard fields.

Limits are Power-Up-specific rather than platform-set; verify file-size caps and field coverage against the specific Power-Up before sizing the project. Most charge per-board or per-Workspace and bill separately from the Trello tier.

JSON board export / import

Every Trello Board can be exported to JSON via Board menu → … More → Print and Export → Export as JSON, producing a full snapshot of Lists, Cards, Comments, Attachments (as URLs), Checklists, Labels and Custom Field values ⁴. JSON is also the canonical interchange format between Trello and third-party migration tools, and it is what Atlassian's own Jira-importer reads when moving boards from Trello into Jira ¹⁷.

JSON is read-only on stock Trello — there is no native import-from-JSON button — so the file is typically consumed by a third-party migration tool that walks the structure and recreates it on a target Workspace. Use JSON when the source is Trello (Board-to-Workspace migration, account-to-account consolidation) or when a tool offers JSON as its lingua franca.

Third-party staging tools

Altosio, Import2, Skyvia and Unito add staging, transformation, dedup and incremental-sync layers. Hevo and Airbyte connect Trello as a source (for analytics) rather than a destination, but several teams use them in reverse for repeatable loads.

Mapping is where every Trello migration earns its scars. The shape decisions you make in the mapping spreadsheet determine whether the team can find their work on day two, whether Butler automation fires correctly on day five, and whether stakeholders trust the boards on day thirty.

Work top-down, from container to atom: Workspaces first, then Boards, then Lists, then Cards with their Custom Fields, then Checklists, then Comments, then Attachments.

Project hierarchy — collapsing source nesting into Workspace → Board → List → Card

Trello's hierarchy is shallower than every major PM source. A Jira project with epics, stories and sub-tasks has four levels; Asana with portfolios, projects, sections, tasks and sub-tasks has five; ClickUp adds Spaces, Folders, Lists, tasks and sub-tasks. Trello has three meaningful levels (Workspace, Board, Card) plus Lists as columns and Checklist items as sub-records.

Custom workflow statuses are not a separate field in Trello — they are *Lists*. A source with 12 statuses becomes a Board with 12 Lists. If your source uses a single status field with 20+ values across multiple workflows, split the destination across multiple Boards (one per workflow) rather than producing a 20-column unreadable Board.

Task dependencies — Trello has none natively

Native Trello has no task dependency, blocker, or predecessor — a fact every Jira or monday.com migrator discovers around mapping day three. The three honest paths forward: (1) add a Power-Up such as Plus for Trello, Hello Epics or Placker to overlay dependencies, accepting that the data lives in the Power-Up's pluginData and is not portable; (2) capture predecessor IDs in a *Blocked By* Text field; (3) drop dependency tracking if the source shows it was rarely used.

Choose deliberately on day one — adding dependencies later requires re-editing every Card. Most teams that migrate from Jira to Trello discover that 80 percent of their Jira dependencies were never actually maintained, and option (3) is cheaper than option (1).

Time tracking — no native field

Trello has no native time tracking — no estimate field, no logged-time field, no timesheet. Teams that migrate logged hours typically take one of two paths: install a time-tracking Power-Up such as Harvest, Toggl or Clockify, then push historical entries via that vendor's tooling to the corresponding cards; or land estimated hours and logged hours into two Number custom fields (*Estimate* and *Actual*) and accept that future logging will use a non-integrated tool.

Harvest's Trello integration in particular reads card IDs and attaches time entries on its side; the entries are not stored inside Trello. Plan the destination tool decision before you import any historical hours, or you will land the values twice.

Comments, mentions and threaded activity

Card Comments imported through migration tooling are created as new actions visible in the card's Activity feed ². Member mentions (@username) work only if the username resolves to a Workspace member at import time — otherwise the @ literal survives but no notification fires.

Comment timestamps are stamped to import time by default — Trello does not accept a backdated value on comment creation. Teams that need original timestamps preserved prepend each comment body with the source timestamp (e.g. [2025-03-12T14:33Z, Jane Doe]:) and keep the original author/time visible inside the text. There is no comment-edit-history preserved on import.

Recurring tasks — via Butler automation

Trello has no native recurring-card field — repetition is built via Butler automation rules with scheduled commands such as every Monday at 9 am, create a card titled "Weekly status" in list "To do" on board "Ops". Butler commands are board-scoped, configured in the Automation menu, and run from Atlassian's servers.

Butler run quotas scale with tier — Free Workspaces get a tighter daily command-run cap than Standard or Premium ¹¹. Plan the recurrence schema by extracting all source recurring tasks (Jira sub-tasks with cron rules, Asana recurring tasks, monday.com automation recipes), translating each to a Butler scheduled command, and importing them as Butler rules rather than as Cards — otherwise the first run creates duplicates.

Custom fields — definitions, dropdown caps, and the 50-per-Board ceiling

Custom Fields require the Custom Fields Power-Up to be enabled on every Board that uses them, and the Power-Up itself counts as one of the Free-tier 1-Power-Up budget ¹³¹¹. Field definitions are Board-scoped: a *Priority* field defined on Board A and a *Priority* field defined on Board B are two unrelated definitions with separate option lists ¹³.

The hard ceilings are 50 custom field definitions per Board and 50 options per Dropdown field ⁴¹². Multi-select does not exist natively — model multi-value source fields either as multiple Checkbox fields, as Labels (multi-applicable per Card), or as concatenated strings in a Text field.

Formula and calculation fields do not import and have no native equivalent — they are either rebuilt as static values, computed by Butler when a card changes, or layered in via the Amazing Fields Power-Up which adds formulas, progress bars and card references. Picklist-style dropdown values that exceed 50 must be collapsed during transform or split across multiple fields.

Attachments and files

Native inline file upload is capped at 10 MB per file on Free and 250 MB per file on paid tiers; there is no overall account storage cap on either ⁵¹⁹. Attachments via link from Google Drive, Dropbox, Box and OneDrive are not subject to the 10 MB cap and are the recommended path for large estates ⁵¹⁹.

Verify any inline-upload integration with a small test batch before scaling. For estates over a few hundred GB, keep the originals in cloud storage and attach by URL.

Audit trail, ownership and original timestamps

Trello's per-card Activity feed records every change (move, edit, comment, label) with a timestamp and a member — but that timestamp is the *action* time, not a user-supplied value. There is no way to override the action time on card creation or comment creation ²¹, which means historical timeline depth is lost on import unless you preserve it elsewhere.

The pattern most teams use is to create two text custom fields per Board — *Legacy Created Date* and *Legacy Created By* — and populate them from the source export so reporting on creation cohorts still works. The Trello card id itself encodes a timestamp in its first 8 hex characters (it is a MongoDB ObjectId) which can be reversed ²⁸ — but that reflects when the card was created in Trello, not in the source.

Ownership during import requires that each member's email or Atlassian account ID can be resolved; rows that don't resolve are imported with no member assigned. Pre-invite all members to the target Workspace before card creation, or expect a second pass to reconcile assignment.

Note that moving a card between boards in Trello does not carry its full activity history with it — Atlassian's support documentation confirms that card activity is relative to the board it sits on at any given time ¹⁸. This is a quirk worth modelling: if your migration involves consolidating boards, expect activity-depth loss on cards that move post-import.

Validation is the bridge between the import finishing and the team being allowed in. The most reliable signal is having the people who will live on the boards every day verify their own Cards — they know what right looks like better than any reconciliation script. Build a three-stage validation: a test load of 10 percent of cards with stakeholder spot-checks, the full load with real-time monitoring of Card and Checklist counts, and a 30-day post-migration cleanup pass.

Build a reconciliation queries spreadsheet that compares source and destination on each count below. Anything outside a 0.5 percent variance gets investigated before users get access.

• Total Cards per Board — and per List per Board — vs source. The most common variance signals a stage-mapping miss or an attachment-failure-truncated record.
• Total Checklist items across the Workspace vs source, with a per-card-count distribution sanity check — a long tail of 0-item cards usually means the importer dropped Checklist payloads on a known-bad row.
• Total Comments imported vs source — and a date-bucketed sample to confirm comment ordering preserved authorship.
• Custom field value coverage per definition — count populated vs blank and compare against the source column-fill-rate.
• Attachment counts split into inline-uploaded vs link-attached, with a spot-check that every link resolves (broken Drive/Dropbox links from access-permission drift are common).
• Member assignment distribution — group by assignee and confirm no Card landed unowned that should not have. Rows with unresolved members at import time silently lose assignment.
• Label coverage per Board — confirm label palette and per-Card label counts match the source's tag distribution.

On top of reconciliation, run a manual spot-check protocol: pick 30 random Cards across Boards and verify each field against the source UI. Pick five high-volume Boards and trace the full activity graph — Card, Checklists, Comments, Attachments, custom fields. If a non-trivial discrepancy appears in three or more of the 30, halt the load, fix the root cause, and re-import the affected rows by Legacy ID.

Trello has no native bulk-undo. The only platform-side recovery primitive is per-card description revision history for manual inspection ³. There is no bulk rollback, no point-in-time restore, no transaction model. The real rollback strategy: export every target Board to JSON pre-import, stamp every Card with an *Import Batch ID* text field, and on failure delete by batch ID and re-import.

Cutover sequencing: (1) source goes read-only and the team is notified; (2) final delta export captures everything that changed since the dry-run; (3) delta is imported; (4) reconciliation runs; (5) members get Workspace access and a 48-hour hyper-care window with the migration lead on call; (6) source decommission is scheduled 30 to 90 days out, never the same day. Archive source boards rather than delete them ¹⁷.

Because Trello is part of the Atlassian portfolio, its partner ecosystem overlaps heavily with Jira's. Atlassian Solution Partners — Gold, Silver and Platinum tiers — cover Trello migrations as part of broader Atlassian rollouts and are typically the right call when the migration is bundled with Jira, Confluence or SSO work.

On the migration-tool side, Altosio offers a SaaS migration with explicit Asana-to-Trello and Trello-to-Asana playbooks including attachments, comments and sub-tasks¹⁴. Import2 runs an Import Wizard for spreadsheet-to-Trello and tool-to-Trello migrations. Unito specialises in two-way sync rather than one-shot migration, useful when source and destination need to coexist during a phased rollout. Skyvia offers CSV / Excel Insert, Update, Upsert and Delete operations against Trello.

On the ETL and reporting side, Airbyte, Fivetran, Stitch and Hevo all list Trello as a source connector — these tools are used in two ways for migrations: extracting source-platform data into a warehouse for transformation before pushing to Trello, and ongoing extract from Trello into the warehouse for reporting post-cutover.

Managed-migration cost ranges vary widely. A clean spreadsheet-to-Trello move of under 5,000 Cards with no custom fields and no historical activity often lands in the £1,000–£4,000 / $1,500–$5,000 range with a setup fee plus per-board pricing. A Jira-to-Trello, Asana-to-Trello or ClickUp-to-Trello project with custom fields, attachments, comments and Butler-equivalent automation rebuild typically runs $8,000–$50,000, with the upper end driven by Card count, custom-field complexity, attachment volume and how many integrations need rebuilding rather than re-pointed.

For teams that want to outsource the migration end-to-end, FlitStack specialises in Trello migrations and handles the hierarchy collapse, Custom Fields setup, attachment handling, comment preservation, Butler automation rebuild, and validation work described in Sections 5 and 7 of this guide. Pricing is fixed-fee, based on Card count and source platform, with separate line items for Power-Up rebuilds and historical activity depth so the scope is transparent before signature.

This is one of several legitimate paths — the right choice for any given team depends on whether they want an Atlassian Solution Partner, a self-service migration Power-Up, an iPaaS-first approach, or a specialist migration vendor. Explore FlitStack →