Migrate from Swit to Asana

Swit task cards migrate directly to Asana tasks with all standard fields preserved: name, description (rich text), due date, start date (Premium only), assignee, priority, and status. Swit's task priority levels (Low, Medium, High or custom labels) map to an Asana custom field of enum type since Asana has no native priority field. Timeline data (start and end dates) migrates as start_date and due_on; if the destination Asana is on Starter tier, start dates require a custom date field workaround.

Swit projects map to Asana projects. Each project's name, description, and dashboard configuration are preserved as project metadata. As Asana does not migrate dashboard widgets, we flag dashboard structure in the handoff inventory. Swit's project-level workload charts and time-tracking summaries do not transfer; time-tracking data migrates as individual time-entry records or a custom duration field on each task.

Swit subtasks are nested under parent task cards and carry their own completion status and assignee. We reconstruct the parent-child hierarchy in Asana using Asana's subtask model. Subtask ordering is preserved as displayed in Swit by setting the sort_order field during migration. Each subtask inherits the parent's project assignment implicitly through the parent task.

Swit checklists embedded within task cards migrate as Asana checklist items on the corresponding task. Each checklist item is a discrete record with a checked/unchecked state that we preserve at migration time. The Swit checklist name (if named separately from the task) does not have a direct Asana equivalent; we append it as a prefixed line in the task description or omit it depending on scoping preference.

Swit tasks and subtasks can have multiple assignees. We resolve each assignee by email lookup against the Swit user roster extracted during discovery, then match to the corresponding Asana user by email. Any assignee without a matching Asana user is flagged in a reconciliation queue for the customer's admin to provision before record import resumes. Multi-assignee tasks on Swit map to multi-assignee tasks in Asana (available on Starter and above).

Swit task comments migrate to Asana task comments with full text, author, and timestamp preserved. Threading structure in Swit flattens to chronological comment ordering in Asana since Asana does not expose nested reply threads in the same way. Author mapping resolves by email to the Asana user. If the Swit account is on a tier below Hub, task-to-channel share links do not exist in source and are not created.

Swit attachment metadata (filename, size, type, URL) exports for each task. We migrate attachment references to Asana attachments on the corresponding task. If the file body is inaccessible via Swit's export (depends on storage configuration), we flag the attachment as requiring re-upload and list it in the handoff inventory. Asana's API enforces a 100 MB per-file maximum; any attachment exceeding this threshold is skipped and documented for manual re-upload.

Swit tags label tasks for filtering and categorization. We map tag names directly to Asana labels on the corresponding tasks. Color mapping is approximate since Swit and Asana use different color palettes; we apply Asana's default color or the closest match. Swit tag counts and tag usage frequency are preserved so the customer's admin can prioritize label cleanup post-migration.

Swit task-level time tracking records hours logged per task by user. If the destination Asana workspace is on Premium tier or above, we migrate time entries to Asana's native time-tracking feature using the tasks/{gid}/time_tracking_entries endpoint. On Starter tier, Asana's native time tracking is unavailable; we migrate logged hours to a custom number field (Hours_Logged__c) and document the limitation. Duration, user, and associated task reference all carry forward.

Swit applies custom fields per-project rather than globally. This is the highest-complexity dimension of the migration. For each Swit project, we enumerate the complete custom field schema (field name, type, and options), map each to an Asana global custom field of the equivalent type (text, number, date, enum), and apply it to the corresponding Asana project during migration. Type transformations are required: Swit multi-select fields map to Asana enum with multiple values; Swit date fields map to Asana date fields or custom date fields depending on tier.

Swit task cards carry priority values (Low, Medium, High or custom team-defined labels). Asana has no native priority field at any tier. We create a custom enum field (e.g., Priority__c) in Asana, populate it with the exact label values from the Swit account, and apply it to all migrated tasks. Teams that used only numeric priority scores in Swit map those to an Asana number custom field.

Swit task status values are team-configurable and vary by project. We extract the actual status values from each Swit project during discovery, then map them to Asana's status model. On Asana Starter tier, status is unavailable; we use Sections to replicate Swit's pipeline stages. On Asana Premium and above, we configure custom Status options to match the Swit pipeline stages exactly, preserving both the label and the stage order. Value transformations are required when Swit's status count exceeds Asana's section limit per project (up to 500 sections, typically not a constraint).