Migrate from Trello to WeKan

Migrate from Trello to WeKan: what the move involves

Moving from Trello to WeKan is supported by a Trello import, but the effort lies in deciding what to export, rebuilding the behavior that Trello delivered through Power-Ups and membership, and running both systems side by side until the team trusts the new board. The import itself is the smallest part of the work. Teams that have been on Trello for years usually have boards with long comment threads, archived cards and attachments scattered across cards, and those are where the decisions sit. Trello's exports differ in what they carry, and the JSON export per board is capped at the 1,000 most recent actions. Before any import, the migration lead should pick the export route for each board, record what it leaves out, and decide whether that gap is acceptable for each team.

Internal platform or IT staff usually own the migration, since they hold the server, the identity provider and the decision about who can sign in. An implementation partner is commonly brought in for the hosting setup, login integration and a repeatable import procedure, with the scope agreed in writing before work starts. Power-Ups do not transfer as such, so the team has to list which integrations they relied on (calendar, voting, card automation or other connectors) and decide whether WeKan covers each need or whether that workflow moves to another tool. Member accounts also need mapping, because the people who appear on Trello cards must match real WeKan users before cards are reassigned. Ask the vendor or community which fields the Trello import maps and test it on a copy of a real board first.

The effort and risk are easiest to judge from a trial. Pick one busy board and one archived board, run the import into a test instance, and compare card counts, comments, attachments and members against the Trello source. Plan a parallel period in which both tools stay available and the team agrees on a cutover date, then freeze the Trello board and keep the export on file for audit and reference. Confirm your retention obligations for the Trello data before the Trello account is closed, and confirm backup and restore for the WeKan database (MongoDB, or FerretDB with SQLite or PostgreSQL) before anyone depends on it. WeKan is released under the MIT license, so the software cost is zero, but the cost of hosting, backup, staff time and any paid support from the vendor recurs or sits in the plan.

Which Trello features move cleanly to WeKan and which need rework

This table maps common Trello features to their WeKan counterparts and marks each as clean, needs rework or gap. Treat the status as a starting expectation, since results depend on board size, export type and how each board was built. Import a test board first and check every row before you migrate live boards.

Trello feature	WeKan equivalent	Status	Confirm after import
Boards and lists	Boards with swimlanes and list views	Clean	Board names, list order and list contents match Trello
Cards and labels	Cards with board labels	Clean	Card titles, descriptions and label names and colors
Members and assignments	WeKan users assigned to cards	Needs rework	Confirm how members are matched to WeKan accounts before import
Checklists	Checklists on cards	Clean	Item text, checked state and item order on sample cards
Comments	Card comments	Needs rework	JSON keeps only the 1,000 latest actions per board, so count comments on busy boards
Attachments	Card attachments	Needs rework	Check that files arrive, not only links. Premium Workspace export includes raw attachments
Due dates	Card due dates	Clean	Dates and time zones display correctly on sample cards
Archived items	Archived cards and lists	Needs rework	Confirm whether archived items import, and plan manual recreation if not
Power-Ups and Atlassian Guard	No direct equivalent	Gap	Power-Up data and Guard settings do not carry over as-is. Rebuild needs with WeKan login options such as SAML or LDAP

Which Trello exports to pull and what each one carries

Trello offers three export routes, and each one leaves something out. Pull more than one, compare them against the source boards, and decide what the WeKan import must carry before you start.

JSON export per board

Trello's JSON export runs per board and is available to every board member, so it is usually the first file to pull. It carries the board structure, lists, cards and labels, but the action history is capped at the 1,000 most recent actions per board. Comments and activity older than that window may not appear in the file. Count the actions on each busy board before the import and decide whether any missing history matters for audit or handover.

Premium Workspace export

Use the Premium Workspace export when you need every comment and the raw attachment files. It is a workspace-level export, so a workspace admin usually has to run it, and access depends on the plan the workspace holds. Confirm with Trello which options your plan includes and whether attachments come across as raw files. Keep the export as the source copy so comments and attachments can be checked against WeKan after the import.

CSV export limits

The CSV export runs per board and requires a Premium plan. It is useful for a quick list of cards, due dates and members, but it leaves out comments and archived cards. Do not treat it as a complete copy of a board. Use it to cross-check card counts after the WeKan import, and decide in advance how archived cards will be handled, since the CSV will not contain them.

WeKan's Trello import

WeKan's README lists Trello among its import formats, so the Trello import is the documented route into WeKan. Run the import into a test instance first, then compare lists, card counts, labels and members against each source board. Check how members are mapped, because the matching accounts must exist in WeKan for assignments to attach correctly. Pin the WeKan version you test, since its releases are frequent.

Power-Ups and integrations

Trello Power-Ups, automation rules and third-party connections are not carried into WeKan by any export, so they must be rebuilt or replaced, not migrated. Inventory every Power-Up, automation and integration on each board, including calendar, chat and webhook links. For each one, decide whether to rebuild it in WeKan, replace it with a self-hosted tool, or retire it. Record those decisions before cutover so no team discovers a broken workflow after go-live.

How to sequence the Trello to WeKan move

The sequence moves Trello boards into WeKan in controlled stages, so each board is inventoried, proven with a pilot, checked against Trello during a parallel run, and then cut over with a signed-off record before Trello access is removed.

Inventory boards, members and attachments
Start by listing every Trello board in scope, its owner, its members and guests, its Power-Ups, and whether it holds archived cards, comments or large attachments. Record which boards carry data your retention rules require you to keep. Decide which export route each board needs: the per-board JSON export is capped at the 1,000 most recent actions, so busy boards may need a Premium Workspace export to keep all comments and raw attachments. The output is a board inventory with one row per board, the export route chosen, and a named owner for each board. Confirm current export limits and plan entitlements with Trello before you start, since those settings can change.
Stand up the WeKan test instance
Install WeKan in your own environment and choose its database option. The default uses FerretDB v1 with SQLite, while MongoDB 6 to 9 or FerretDB with PostgreSQL are the other supported paths. Configure your login method, such as SAML, LDAP or OAuth2, and confirm that backups of the database and uploaded attachments run. Use a non-production hostname so test data cannot be mistaken for live boards. The output is a working test instance with a documented version, database, backup job and login configuration, which your security team has reviewed.
Pilot-import one representative board
Choose one board that covers the hard cases in your inventory, such as a long history, many comments, checklists, labels and attachments. Import its export into WeKan using the Trello import, then compare the result against the source board card by card. Check card titles, descriptions, list positions, labels, members, due dates, comments with their authors and timestamps, and attachments. Record every mismatch and decide whether it is a known import gap, a configuration issue or something to fix before the wider run. The output is a pilot reconciliation report and a list of accepted gaps signed off by the board owner.
Run both systems in parallel
Import the remaining boards in waves, and keep Trello as the system of record while members test WeKan on their own boards. Re-import or refresh boards when the source changes, and rerun the reconciliation for each wave. Track any card that is edited in both places, because WeKan does not sync back to Trello. Agree on a fixed window for this stage in writing with your team, and set a rule that Trello changes after the import point are re-keyed or re-imported. The output is a running log of reconciliation results per board and a list of open discrepancies with owners.
Cut over members and boards
Move each board to WeKan as the working copy. Provision WeKan accounts through your identity provider, add members and their board roles, and send a short guide covering where boards now live and how attachments are handled. Confirm that every board owner has reviewed their final import and that open discrepancies are closed or accepted. Freeze edits in Trello for each board at its cutover point, and note the time of that freeze. The output is a cutover checklist per board, signed by the board owner and the platform owner, with the freeze time recorded.
Decommission Trello access and keep the evidence
After cutover, remove member access to the Trello boards that have moved, and archive or export the Trello data that your retention policy requires you to keep, storing it in a location you control. Revoke Trello integrations and Power-Up tokens that still point to the old boards, and update any links in documents or runbooks. Keep the reconciliation reports, the signed checklists and the export files with a retention date. Ask Trello to confirm what it retains after you remove your account or boards, because that answer belongs in your records. The output is a decommission record listing each board, the removal date, the archived export location and the retention owner.

How WeKan's Trello import handles boards, comments and attachments

WeKan's README lists Trello among the import formats it accepts, alongside WeKan JSON or zip, CSV/TSV and Excel, so a Trello board can be brought in directly from its exported JSON file. Treat the import as a one-time copy of a snapshot, not a live sync. Before importing, record which export produced the file, when it was made and which boards it covers. Trello's JSON export carries only the 1,000 most recent actions per board, so older comment history may be absent from the file you import. Confirm this with your own export before planning the cutover, because the gap is invisible once the board is in WeKan. Review the WeKan repository for the import version you plan to run and test it on a copy of a board first.

After the import, reconcile WeKan against the source export before any user relies on the board. Start with card counts: compare the number of cards in each list and swimlane against the Trello board, and include archived cards only if your export contained them. Next, check comment history on a sample of long-running cards, since the cards with the most discussion are the ones most likely to lose older actions under the 1,000-action limit. Then check attachments. Confirm whether files were carried into WeKan or whether cards only hold links back to Trello. If you need every comment and the raw attachment files, the Premium Workspace export with optional raw attachments is the route to plan for, and you should verify its contents before you start the migration.

Member mapping deserves its own check. Each Trello member should map to one WeKan user with the right board role, and any unmatched member should be resolved before users start working, because assignments and comment authorship depend on that link. Record the results in a simple reconciliation sheet with the board, the counts, the sample cards checked, the attachment outcome and the member decisions. Ask the business owner of each board to sign off on that sheet before the board is opened for daily work. If your organization needs an independent record of this check for an assessment, keep the sheet with the export files so the evidence can be reviewed later.

How the move changes for small teams, multi-board workspaces and regulated environments

A single team with a handful of boards usually has the simplest move. Trello's JSON export for each board is often enough, provided every board stays well under the 1,000 most recent actions that the export carries. Count the activity on each board before you export, because a board that has been active for years can exceed that window and lose older comments.

For login, a small team can often start with local WeKan accounts on a private network, then add OAuth2 or SAML once the instance is live. LDAP is only worth configuring if your team already has a directory that supplies its users.

Export choice: Use per-board JSON exports for boards with modest activity. Keep a record of which boards you exported and when.
Login setup: Start with local accounts for a pilot, then move to your identity provider after the first import is validated.
Validation effort: Import one board first and compare card counts, labels, checklists, due dates and member assignments against Trello.
Attachments: Check that attachments you need are present in the imported cards, since the JSON route does not carry every raw file in the way a Premium Workspace export does.
Users: Map each Trello member to a WeKan user before inviting the rest of the team.

Before you cut over, confirm with the WeKan README which import path matches your Trello plan and board sizes, and run the same checks on a copy of the board.

What drives the cost and duration of a Trello to WeKan migration

This table lists the factors that move the effort of a Trello to WeKan move up or down, why each one matters and what to request in a written quote. Read it before scoping, because most of the variance comes from the content and identity decisions rather than from the software itself.

Driver	Why it changes cost or effort	What to ask for in a written quote
Number of boards and members	Each board is mapped to a WeKan board with its own lists, swimlanes and member roles, so board count drives mapping and verification work. Members who need access must be matched to WeKan users before import.	Board count by status (active, archived, template), member list with planned roles, and whether archived boards are in scope.
Comment and attachment volume	Trello's JSON export includes only the 1,000 most recent actions per board, so busy boards may lose older comment history. Keeping every comment and raw attachment usually means a Premium Workspace export, which adds an export and reconciliation step.	Confirm which export method covers the comments and files the business needs, and whether attachments are re-uploaded or linked.
Power-Up dependencies	Cards that depend on Power-Ups, such as calendar, custom fields or external integrations, need either a WeKan equivalent or a documented gap. Each dependency adds review and rework time.	A list of Power-Ups in use, the replacement or gap for each, and who decides on accepting the gap.
Identity integration	Login through SAML, LDAP or OAuth2 requires directory mapping, test accounts and user matching so imported cards keep the right owners. Accounts that cannot be matched need manual handling.	Identity provider type, directory attributes used, and the expected mapping of Trello member emails to WeKan users.
Hosting and MongoDB or FerretDB choice	WeKan supports MongoDB 6 to 9, and its default is FerretDB v1 with SQLite, which needs no database server. A MongoDB deployment adds database administration, while FerretDB with PostgreSQL adds a PostgreSQL role to operate.	Chosen database backend, the hosting target (cloud account, data center or air-gapped network), and who operates the database after handover.
Backup design and validation scope	A backup taken before import and a restore test after import are the main controls against lost data. Validation scope ranges from spot checks on a few boards to full card, comment and attachment reconciliation, which changes effort considerably.	Backup method and retention, restore test steps, the sample of boards checked, and the acceptance criteria signed off in writing.
Import rehearsal and cutover	Running a test import on a copy of the boards shows mapping problems before the live move. Skipping the rehearsal often moves rework into the cutover window when users are already working in WeKan.	Number of rehearsal runs included, the cutover plan, and the freeze period for Trello edits during the move.
Support after go-live	WeKan offers official private pre-paid support from wekan.fi and free community options. Users who need changes after go-live add ongoing cost whether support is bought from the vendor or from DeployOpen as a retainer.	Whether support is included in scope, the response expectations in writing, and whether any upgrade work between WeKan releases is covered.

What usually goes wrong when moving Trello boards to WeKan

Most failed Trello-to-WeKan moves are not technical failures in WeKan itself. They come from exports that were assumed to be complete, comments and files that were never requested, and board logic that nobody mapped before cutover. Each risk below has a check you can run before the import starts.

Incomplete exports from the action cap

Trello's JSON export per board includes only the 1,000 most recent actions. On a busy board, older comments, moves and membership changes fall outside the file, so the imported WeKan board looks shorter than the original. Before you import, compare the action count on the board with what the export contains and record the gap. If older history matters for audit or handover, plan a separate export route and store the original files with the migration record.

Comments and attachments skipped

A standard per-board JSON export does not give you every comment or the raw attachment files. Teams that skip the Premium Workspace export often discover the gap only after cutover, when someone asks for a file attached to a card from two years ago. Decide before export which boards need full comments and raw attachments, confirm your Trello plan can produce that export, and check a sample card in WeKan against the original.

Members who do not map to accounts

Trello members, card assignees and comment authors must match user accounts in WeKan. If an imported member has no matching WeKan login, assignments and authorship can end up attached to a placeholder or lost. Build a mapping table from Trello usernames to WeKan accounts, create the accounts first, and decide who owns cards from departed staff. Confirm the mapping in a test import before you migrate live boards.

Power-Up workflows left unreplaced

Trello Power-Ups, calendar views and automation rules do not move with the board data. A card that once triggered a notification, a due-date reminder or a sync to another tool may silently stop working in WeKan. List every Power-Up and automation on each board, note what it did, and assign a replacement or a documented manual step before users depend on it.

Fast release cadence without a patch process

WeKan publishes releases very frequently, so a self-hosted instance that is never updated falls behind quickly. Upgrading without a test environment can change board behavior your users rely on. Run a staging instance with a copy of the migrated boards, pin the version you validated, and set a recurring review of new releases with a rollback plan and a database backup taken before each upgrade.

Questions teams ask before moving Trello boards to WeKan

How much does it cost to move Trello boards to WeKan?

The software itself has no license fee, because WeKan is released under the MIT license. The cost is the work around it: hosting, a database, backups, staff time for the import and checks, and optional paid support. Your Trello plan is a separate cost that ends when you cancel it, so ask for a fixed-scope quote that lists each of these components. The main drivers are the number of boards, how many members and cards each board has, how many attachments need to be carried over, and whether you need single sign-on configured on day one. No WeKan price is quoted here, so confirm current support terms directly with the vendor at wekan.fi.

How long does a Trello to WeKan migration take?

No duration is published in the supplied material, so treat any estimate you receive as something to verify. Time depends on board count, card volume, how much history you need to keep, and how many boards must be checked by the people who use them. A practical approach is to import a few representative boards first, review swimlanes, lists, labels, members and attachments, and then schedule the rest in waves. Ask your implementation partner for a timeline tied to a written scope, with acceptance steps for each wave.

What does our internal team need to provide for the move?

Your team needs someone who can export the boards from Trello, decide which boards and history are in scope, and confirm the result with the people who use each board. You also need an owner for the WeKan server, including its hosting environment, administrator accounts, and access rules. An engineer should be available to run the install and check the database choice, since WeKan's default uses FerretDB v1 with SQLite, while MongoDB 6 to 9 is also supported. Plan for a short review window after each import so that cards, members and labels are confirmed before users depend on them.

Can we run the Trello to WeKan migration without outside help?

Yes, a capable internal team can run the import, provided it has someone comfortable with Docker or Linux administration and with the import process. WeKan supports importing from Trello, and the software is publicly documented, so the steps are not hidden. Outside help is most useful when you need a hardened production setup, SSO and LDAP integration, backup and restore testing, or a repeatable process for many boards. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope with the scope and deliverables agreed in writing before work starts.

What is one-time work and what recurs after the migration?

The import, configuration, identity integration and the first round of checks are one-time work. Recurring costs are the infrastructure that runs WeKan, the backups and their restore tests, patching and upgrades, and any paid support or retainer you choose. WeKan publishes very frequent releases, with v12.52 dated October 17, 2026, so a recurring upgrade routine is part of the ownership model. Ask any provider to split its quote into one-time and recurring lines, and to state who performs each upkeep task.

How are Trello comments and attachments handled during import?

Comments and attachments depend on what you export from Trello. The JSON export per board includes only the 1,000 most recent actions per board, so older comment history can be missing from that file. Raw attachments and all comments are available through the Premium Workspace export, which requires a Premium plan and can include attachments. Before you import, confirm which export you have, then check a sample card in WeKan to see whether comments and files arrived as expected. Keep the original Trello export archived, since it is your reference if anything is missing later.

Which WeKan details should we confirm before importing?

Confirm the WeKan version you will deploy, the database backend, the login method, and the import formats your build supports. WeKan's README lists Trello among its import sources, along with CSV, TSV, Excel and WeKan JSON, but you should test the Trello import on a copy of a real board in a staging instance before you rely on it. Also confirm how members are mapped from Trello accounts to WeKan users, how archived cards are treated, and how attachment storage is configured for your environment. Ask WeKan directly through its repository or its official support channel at wekan.fi if any of these points is unclear.

Who keeps the data and access controls after the move?

After cutover, your organization owns the WeKan server, its database, the attachments and the user accounts. Access depends on the login options you enable, which WeKan's README lists as SAML, LDAP, OAuth2 login providers and passwordless login. Decide who administers the server, how accounts are removed when people leave, and where backups are stored. Document these decisions in a runbook so the answers do not depend on one person. Confirm all security controls and the data location within your own environment, since no certification or attestation is implied by the software itself.

How DeployOpen scopes and runs a Trello to WeKan migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up and documents self-hosted platforms inside the client's own infrastructure. The cards below describe how a Trello to WeKan project is scoped in writing, what the work covers and what stays with the client after go-live.

Who DeployOpen is

DeployOpen is a Chainscore Labs company. It plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside the client's own cloud accounts, data centers or air-gapped networks. For a Trello to WeKan move, the boards, comments and attachments stay in infrastructure the client controls. Ask any implementation partner to name the platforms it has deployed in environments like yours and to confirm who holds administrator access at handover.

Fixed scope agreed in writing

Most engagements are fixed-scope, so the board count, member list, attachment handling, login method and target environment are agreed in writing before work starts. A written scope should state which Trello boards are in and out, how archived cards are treated and who checks the imported result. Ask for the scope document to list deliverables and acceptance steps before you sign.

Quotes follow from the scope

DeployOpen does not publish a price list. A quote follows from the written scope, so the cost depends on the number of boards, the migration method chosen for each export, the hosting target and the login integration. Ask for the quote to separate one-time migration work from any recurring hosting, backup or support items, so the total cost of ownership is visible.

Hardening and backups before cutover

Before boards are opened to users, the WeKan installation is hardened and backed up. That covers the database choice (the default is FerretDB v1 with SQLite, while MongoDB 6 to 9 is also supported), access controls, TLS and a tested restore path. Confirm with the implementer how backups are scheduled and that a restore has been rehearsed on a copy of the data.

Documentation and ongoing support

Handover includes documentation of the installation, upgrade steps and import decisions, so your team can explain how each board arrived in WeKan. WeKan publishes frequent releases, so the upgrade path matters. Ongoing support, upgrades and continuous testing are available as retainers, which you can scope separately from the migration. Ask what the retainer covers and who applies security updates.

Migrate from Trello to WeKan