Migrate from Swit to Trello

Each Swit Project maps to a Trello Board. We extract the project name, description, and any project-level configuration (workload chart settings, time-tracking configuration) and apply the project name as the Board title. The Trello Board is created in the destination workspace before any List or Card import so that the board reference is available for all child records. Swit's Advanced-tier cross-workspace features do not have a Trello analog; we consolidate cross-workspace content into a single destination workspace and flag cross-workspace dependencies for the customer to resolve.

Swit Tasks map to Trello Cards. Each Card receives the Task title as its name, the task description as the Card description, the assignee as a Card member, the priority level as a Label color, and the due date as the Card due date. Task status in Swit (team-configurable per project) maps to Trello List placement: we enumerate the actual status values from the source project, create a Trello List for each status, and place the Card in the List corresponding to its migrated status value.

Swit Subtasks have two migration paths depending on nesting depth. First-level Subtasks (children of a Task) become Checklist items inside the Trello Card using the native Checklist feature. Second-level Subtasks (children of a Subtask) become Cards on a dedicated Subtasks List within the same Board; we use the parent Subtask title as the Card name and preserve the second-level assignee and completion status. The customer chooses the depth strategy during scoping based on how they want to balance checklist readability versus task detail.

Swit Checklists embedded in Task cards map directly to Trello Card-level Checklists. Each Swit Checklist item becomes a Trello Checklist item with its checked or unchecked state preserved at migration time. We extract the checklist ordering as displayed in Swit and apply the same sequence in Trello. If a Swit Task has multiple named Checklists, each becomes a separate Trello Checklist on the same Card, preserving the checklist names.

Swit Task comments migrate as Trello Card comments. We preserve the comment text, author name, and timestamp. Threading structure in Swit is flattened in Trello because Trello does not support threaded comments natively; comments appear in chronological order on the Card. If the migrating team relies heavily on threaded discussions, we flag this as a limitation and recommend a complementary tool like Loom or Confluence for discussion-heavy workflows.

Swit Tags map to Trello Labels on Cards. We extract each unique tag name from the source account and create a corresponding Label in the destination Board with an auto-assigned color. Tag-to-card relationships migrate as Label assignments, preserving the many-to-many relationship so that Cards can carry multiple Labels matching the source tag set. If the customer uses tags for both categorization and priority, we recommend separating them into two Label groups during scoping.

This is the highest-risk mapping phase. Swit applies custom fields per-project rather than globally. During discovery, we enumerate the custom field schema for every project individually: a customer with fifteen projects may have fifteen different sets of text, number, date, and choice fields. We map each project-level schema to the Trello Custom Fields Power-Up at the board level, converting Swit field types to their Trello equivalents (text to Text, numbers to Number, dates to Date, multi-choice to Dropdown). Trello supports five Custom Field types: checkbox, date, dropdown, number, and text. Fields that do not map (e.g., Swit user-picker fields) are flagged and either converted to text or noted as requiring manual post-migration entry.

Swit Priority values (Low, Medium, High, or custom labels) map to Trello Label colors on Cards. We extract the actual priority values from the source account (Swit does not enforce a universal priority set) and assign a corresponding Label color per unique priority value. If the customer uses named priority levels, we create Labels with the priority name in the label description for clarity. Priority is visible as a Label on the Card front when the label display setting is enabled.

Swit attachment metadata (filename, size, type, URL reference) migrates to Trello Card attachments. File content retrieval depends on whether Swit's storage export provides direct file access; we export all accessible attachment metadata and flag any items where the file body could not be retrieved. Those flagged items are presented to the customer as requiring manual re-upload in Trello. Trello supports direct upload, Google Drive links, Dropbox links, and OneDrive links as attachment types. We prioritize converting accessible URLs to Trello-compatible links where the destination platform supports them.

Swit task-level time tracking records (hours logged per user per task) have no native Trello equivalent. We export the time entry data (duration, user, associated task, and timestamp) as a structured data package and present three options: appending a time log to the Card description in a structured format, integrating with a time-tracking Power-Up post-migration (Toggl, Clockify, or TimeCamp), or excluding from migration and rebuilding manually. The customer chooses the strategy during scoping.

Swit's task-to-chat share links (the ability to share a task card directly into a team chat channel) are gated behind the Hub plan and do not exist in accounts on lower tiers. We check the customer's Swit plan during discovery and flag the presence or absence of task-chat links. If they exist, we document them in a supplementary handoff file; they cannot be migrated as functional links to Trello because Trello does not have an equivalent chat-integration feature. The customer rebuilds this pattern using Trello Power-Ups or external integrations post-migration.

Swit Tasks and Subtasks support multiple assignees. Each assignee maps to a Trello Board Member. We resolve assignees by email address against the destination Trello workspace members, creating a Member mapping for each distinct email in the source account. Any assignee without a matching Trello member goes to a reconciliation queue for the customer to provision before record import resumes. Trello Cards can have multiple members, preserving the many-to-many assignment relationship from Swit.