Board structure
- Board name and description
- Lists, in order, with their cards
- Labels with their colours matched
- Custom fields and their options
Create a Kanera workspace, then upload one board’s JSON export. Kanera hands the decisions back to you — which lists, labels, and fields to create or reuse, and who each Trello member is here.

A board you can only skim is no basis for a decision. The importer carries the structure and the context, so the pilot board is the real project rather than a sketch of it.
One board per JSON export, up to 50 MB.The technical import guide
Kanera analyses the export and then waits. Every step below is a decision you make, and you can leave without having changed anything in either system.
Kanera reads the export and reports what is in it: lists and whether each is archived, labels and their colours, custom fields and their types, members, and counts for cards, checklists, comments, and attachments.
Create, reuse, or skip each Trello list. A name that matches an existing Kanera list is suggested for you. Archived lists are skipped unless you say otherwise.
Create or reuse each label. Kanera suggests the closest Kanera colour, and normalises Trello’s light and dark variants down to it.
Create a new field or reuse a compatible one. Types have to line up before the import can finish, so nothing is silently coerced.
Match each Trello member to someone with access here, or leave them unassigned. That single choice decides assignees and comment attribution.
Board name, icon, comments, field values, archived cards, attachments — plus a count of what imports and what gets skipped. Confirming is the first thing that writes data.
Every list, label, and custom field gets one of those three, and the choice is yours on each row. Reuse is what stops an import from cluttering a workspace you have already tuned; skip is what keeps a board’s dead weight out of it.
| Trello | Kanera |
|---|---|
| Text | Text |
| Number | Number |
| Checkbox | Checkbox |
| Date | Date |
| List | Select |
A field mapped onto one you already have must use a compatible type before the import will run. Select options are matched by label, and the missing ones are created.

The destination decides whether the imported workflow joins a shared structure or stays self-contained. Both run the same mapping review.
Kanera creates a new board and maps the Trello lists, labels, custom fields, and members onto the setup the workspace already shares.
Best when related projects should run one operating model.Kanera adds the Trello cards to a board you already have. Its own settings, existing cards, and permissions are left exactly as they are.
Best when the board should answer to nothing else.Some of it will not. Connect Trello during review and uploaded files are copied across; without that, links back to Trello are preserved. Everything else that cannot be resolved is handed to you as a choice rather than absorbed silently.
Create a compatible Kanera field, map it onto an existing one, or skip its values. An incompatible type has to be resolved before the import will run.
Leave them unassigned. Their card and checklist assignments are skipped, and their comments are created by you with the original Trello name kept in the comment body.
Kanera keeps the link back to Trello and tells you why the file was skipped — file type, size limit, storage quota, or a Trello authorisation error.
Archived lists are skipped by default and archived cards are opt-in. Turn them on only when that history belongs in the first move.
Timing, running both systems in parallel, and moving a whole team are answered on the migration overview.
Export the board from Trello itself. The menu location varies by workspace plan and interface, but the export produces a single JSON file for one board.
Kanera accepts that JSON file up to 50 MB. An export with no lists in it cannot be imported.
Yes. Importing into a standalone board adds the Trello cards to that board and maps the structure onto settings that belong only to it. Its existing cards and permissions are unchanged.
Importing into a workspace instead creates a new board and maps Trello lists, labels, custom fields, and members onto the workspace’s shared setup.
Text becomes Text, Number becomes Number, Checkbox becomes Checkbox, Date becomes Date, and a Trello List field becomes a Kanera Select field.
A field mapped onto an existing Kanera field has to use a compatible type before the import can finish — Kanera will not guess. For Select fields it reuses options that match by label and creates the ones that are missing.
Leave them unassigned. Kanera suggests matches first by comparing Trello member details against Kanera names and email addresses, including the local part of an address, because Trello exports often carry only usernames.
Card and checklist assignments for an unmapped member are skipped. A comment by an unmapped author is created by the importing user, with the original Trello member name added to the comment body so attribution is not lost.
Archived Trello lists are skipped by default, and you can still choose to map or create them.
Archived cards are off by default and turned on with Include archived cards, which also brings in cards from archived lists. Imported archived cards then follow Kanera’s normal archived-card retention.
Common reasons are an unsupported file type, a file over your organisation’s size limit, a copy that would exceed the storage quota, Trello not being connected during review, or a Trello authorisation or download error.
The import summary groups the skipped files by reason and shows sample warnings. Attachment links back to Trello are preserved on the cards either way.
The workspace admin who ran the import gets inherited access to the new board. Add other workspace members as Editors or Observers from Workspace settings, under Boards, then Manage access.
A standalone board import changes nothing about who can already see that board.
Start with the complete product for 30 days. No card required.
No card required, 30-day Pro trial, free plan available after it