Migrate from Dart to Trello

Dart Workspaces map to Trello Boards. Each Workspace becomes a Board with the Workspace name as the Board name. Workspace membership maps to Board membership: Dart Workspace members with Admin or Editor roles become Trello Board Admins or Normal members; Viewer roles become Trello Observers. If the customer has multiple Dart Workspaces, each becomes a separate Board. Workspace-level custom field definitions are captured at this step and pre-created on the destination Board before task data loads.

Dart Projects require a structural decision during scoping. If the customer prefers a flat board structure, each Project maps to a Trello List on the Board representing the parent Workspace. If the customer prefers a per-project Board (common when projects have distinct team membership), each Project maps to a separate Board with its own Lists. The choice depends on the number of Projects per Workspace and how much cross-project visibility the team needs. We document the recommended strategy during scoping and align with the customer's preference.

Dart Tasks map directly to Trello Cards. The Task title becomes the Card name; the Task description (rich text) migrates as the Card description. Due date maps to the Card due date field. Status in Dart (Active, Completed, Archived) maps to the Card position on the List: Completed tasks land on a dedicated 'Done' or 'Completed' List; Archived tasks land on a separate 'Archived' Board. Assignees migrate as Card members (see Assignees mapping). Task priority and tags map to Trello Labels (color-coded).

Dart Subtasks map to Trello Checklists on the parent Card. The Subtask title becomes a Checklist item; completion status (is_done) maps to the Checklist item checked state. Subtask hierarchy depth is preserved by nesting Checklists: a top-level Subtask becomes a Checklist; a nested Subtask under a Subtask becomes a nested Checklist item. Trello supports up to 200 Checklist items per Card and up to 10 levels of nesting. Most Dart Subtask trees are two levels or fewer and fit comfortably within these limits.

Dart Assignees are user references on Tasks. We extract the assignee email and name, then look up the corresponding Trello member by email on the destination Board. If the Trello account does not exist, we create a placeholder Card label (e.g., 'Unresolved Assignee: [email]') and flag it for the customer's admin to resolve post-migration. This is a known limitation of cross-platform migrations: user identity cannot be assumed to exist in the destination system without explicit provisioning.

Dart stores Attachments as linked resources separate from Task records, requiring a download-and-upload cycle. We retrieve the attachment URL from Dart via API, download the file to temporary storage, upload it to Trello's attachment endpoint, and link it to the destination Card. Trello Standard and Premium plans support native card attachments; Free plans require a Power-Up (such as the built-in Attachments Power-Up or a third-party like Google Drive). We flag the customer's current Trello plan during scoping and recommend upgrading if the Free plan is in use and the migration includes a significant attachment volume. For large attachment sets (more than 500 files), we batch the upload in groups of 50 to avoid rate-limit throttling.

Dart custom field definitions are stored at the Workspace level and assigned to Tasks. We extract every unique custom field definition (field name, field type, and any picklist values) before loading any task data. These definitions are created in Trello using the Custom Fields Power-Up API: text fields become Trello text custom fields; number fields become Trello number custom fields; date fields become Trello date custom fields; dropdown fields become Trello dropdown custom fields. This sequencing is mandatory because Trello Cards cannot receive custom field values for fields that do not yet exist on the Board.

Once the custom field definitions are created on the destination Board (see above), we load Dart Task custom field values as Trello Card custom field values. The mapping uses the custom field definition ID in Trello as the target key and the Dart field value as the source. Multi-select custom fields in Dart (checkbox groups) map to Trello multi-select dropdown custom fields. We validate field type compatibility during scoping: if Dart stores a numeric value in a text-typed custom field, we pass it as-is to a Trello text field rather than forcing a type conversion that could silently truncate.

Dart Time Entries are linked to Tasks with duration (in minutes or hours), user association, and a billable flag. Trello has no native time tracking. We migrate time entry data as Checklist items on the Card with a formatted duration string in the item title (e.g., '[2.5h] Design review - billable') and the billable flag stored in the Card description or as a Label. For teams that need billable hour reporting, we recommend installing a Trello Power-Up (such as Corun or TimeCamp) post-migration; we do not migrate historical time data into third-party Power-Up storage because it requires API credentials for those services.

Dart tags (stored as tag values on Tasks) map to Trello Labels on the Card. We preserve the tag name as the Label name and assign a color based on a deterministic color assignment (e.g., hash of the tag name modulo the available label colors). If Dart uses colored tags, we map the Dart color to the nearest Trello label color. Tags that do not fit within Trello's 10-color label palette receive the 'none' label color and retain the full tag name as the label text.

Dart task comments (authored by users with timestamps) migrate as Trello Card Comments. The comment body migrates as the comment text; the author email maps to the Trello member by email lookup (same logic as Assignees); the timestamp migrates as the comment date. If a Dart comment author does not have a matching Trello member, the comment is attributed to a 'Dart migration' system account that the customer provisions before cutover.

Dart Project settings (default visibility, notification preferences, task numbering, workflow stages) map partially to Trello Board settings. Visibility and notification preferences do not have direct Trello equivalents and are noted as requiring manual configuration post-migration. Workflow stages in Dart (if different from the default Active/Completed/Archived) map to specific Lists on the Board: each distinct Dart stage becomes a List with the stage name. The customer's Dart project settings are documented during scoping and delivered as a Board configuration checklist.