Migrate from Kantree to Trello

Kantree workspaces map to Trello Workspaces (Free tier: 1 Workspace; Standard and above: multiple Workspaces). Each Kantree workspace becomes a Trello Workspace, and the customer chooses whether to create one master Trello Workspace or multiple Trello Workspaces matching the Kantree structure. Workspace color themes and display settings have no Trello equivalent and are documented as manual configuration steps post-migration.

Kantree projects map to Trello boards, preserving project name, description, card group (column) structure as board lists, and any project-level custom fields as card-level fields. The project creation date migrates as a card description annotation. If the Kantree project has multiple card types, we create separate boards per card type or use Trello labels as a card-type proxy, depending on scoping preference.

Kantree cards map directly to Trello cards with the title, description, due date, assignee, cover image, and checklist content preserved. Trello card descriptions accept Markdown, so rich text from Kantree migrates with formatting converted. The card creation timestamp and last-modified timestamp migrate as custom fields (Start Date or due date metadata) since Trello cards do not carry creation-date metadata by default.

Kantree card types (Bug, Feature, Invoice, Patient, etc.) do not have a direct Trello equivalent. We map card types to Trello labels using a naming convention (card_type:Bug, card_type:Feature). For workspaces with fewer than 10 card types, this covers all cases within Trello's label limit. For workspaces with more than 10 card types, we flag the limitation and recommend splitting by board or using a Power-Up like Custom Fields to carry the type as a structured attribute.

Kantree supports 27 custom field types. The migration strategy is tiered by field type: text, number, date, single-select, and multi-select map to Trello Standard/Power-Up Custom Fields. Rating fields map to a label with N stars. Formula fields are exported as static text with the last computed value. Card reference fields are exported as checklist items with card links. User reference fields map to Trello members. Fields that cannot map (such as Kanban swim lane assignments or KQL-conditional visibility flags) are documented as manual configuration steps post-migration.

Kantree subcards are independent cards with their own card types, fields, assignees, and subcards (recursive nesting). Trello checklists have no custom fields, no assignees, and no nested checklists. We flatten subcard hierarchies to checklist items, embedding the subcard title and, optionally, the last-known field values as text in the checklist item name. If the subcard depth exceeds two levels, we recommend breaking the chain into separate boards post-migration using a Trello Power-Up for board linking.

Kantree supports one-to-one, one-to-many, and many-to-many card relationships defined at workspace level. Trello has no native card-linking or many-to-many relationship fields. For each relationship type, we embed a structured reference in the child card's description using a markdown link format (Parent: [[Card Name]]), or we create a 'Related Cards' checklist with the linked card names as checklist items. The relationship type label (blocks, implements, relates_to) is preserved as a label prefix on the link reference.

Kantree card groups (columns) within a project map directly to Trello lists on the corresponding board. Card group color coding, card ordering within groups, and group-level WIP limits migrate as Trello list settings and color labels. Kantree's card limit indicators (highlighted in red with icon) have no Trello equivalent and are documented as a manual board configuration note.

Kantree comments with author, timestamp, and text body map to Trello card comments. The 2-hour editable window for authors does not exist in Trello (comments are permanently editable by any board member), so we migrate the comment text and author but do not preserve the edit-window constraint. Rich text in comments migrates with markdown conversion. Comments with @mentions carry the mention as plain text in Trello since Trello comment @mentions resolve differently.

Kantree file attachments (drag-and-drop or image toolbar upload) migrate to Trello card attachments. We export the file metadata (name, size, upload date, uploader) and download the file from Kantree's storage layer, then re-upload to Trello. Files are attached to the migrated card at the same position in the attachment list. If a file exceeds Trello's 10MB attachment limit (Free and Standard), we flag the file and the customer chooses whether to attach via a Trello Power-Up (such as Google Drive or Dropbox integration) instead.

Kantree organization members (billable) map to Trello board members. Project observers (free but read-only) map to Trello observers on a per-board basis; they can view the board without consuming a paid Trello seat if the Trello board uses a Workspace with Free-tier settings. We map by email match. Any Kantree member without a matching Trello account is held in a reconciliation queue for the customer's admin to provision before card import.

Kantree roles define workspace and project-level permissions (card edit, comment moderation, field visibility, view sharing). Trello uses Workspace-level admin, normal, and observer roles, and board-level admin, member, and observer roles. We map the highest applicable permission level per user across the Kantree workspace (if a user is admin at workspace level, they become Workspace Admin in Trello; if they are project-level observer only, they become board Observer). Fine-grained field-level visibility settings do not map and are documented as manual configuration steps.

Kantree's non-Kanban views (Table, Matrix, Timeline, Calendar, Gantt) have no direct Trello equivalent. We export the view definitions including filters, sort orders, displayed fields, and grouping configuration as a written view inventory. Trello Standard and above offer Calendar and Timeline views natively; Table view requires Premium. The customer chooses which Kantree views to recreate in Trello Power-Ups or as separate boards with filtered card-template lists.

Kantree automations consist of KQL-based triggers, conditional branches, and action chains (set field, move card, post comment, copy card, etc.). Trello Butler supports trigger-action rules with at most one conditional branch. Complex Kantree automations with multi-step chains, KQL filter conditions, or card-count triggers do not map to Butler. We export the complete automation rule inventory — trigger type, conditions, action chain — as a written document organized by project, and the customer's admin rebuilds in Butler or selects a Power-Up with equivalent logic.

Kantree public-facing forms that create cards on submission are configuration artifacts. We export form definitions (field structure, submitter info capture, validation rules) as a written inventory. Trello does not have a native form creation tool; the customer can use Trello Butler's card creation from form data or a third-party form tool (JotForm, Typeform, Google Forms) linked via Power-Up. Form submission history migrates as cards with a 'Form Submission' label and the submitted field values as card description.

Kantree Reports are workspace and project-level aggregated statistics (filters, groupings, displayed fields). We export report definitions as written configuration notes. Trello Standard and above provide Dashboard views for cross-board statistics; more detailed reporting requires a Power-Up such as Screenful, Corwise, or a custom analytics integration. Historical report snapshots do not migrate as datasets and are noted as requiring manual recreation in the destination reporting tool.