Migrate from Swit to Jira

Swit Task cards map to Jira Issue (Story, Task, or Bug depending on the task type identifier in Swit). The task title maps to Jira Summary, which is a required field. We extract priority, status, timeline (due date), and all standard fields. Assignee resolution runs by email match against Jira user accounts. Multi-assignee tasks on Swit map to Jira's multi-user picker field if available in the destination plan or are split into separate Assignee fields on a single issue per the customer's preference.

Swit Projects map directly to Jira Projects as top-level containers. Each Jira Project receives a corresponding Issue Type Scheme, Workflow Scheme, and Field Configuration before task migration begins. Swit's project-level dashboards are not migrated as Jira dashboards; we document the chart types and metrics for the customer to rebuild in Jira.

Swit Subtasks under a parent task map to Jira Sub-Tasks linked via the Parent Issue key. We preserve subtask ordering as displayed in Swit by setting the Sort Order or sequence field in Jira if the destination supports it, or by documenting the intended order for the customer's admin to arrange post-migration. Each Sub-Task carries its own assignee, status, and completion state independently from the parent.

Swit checklists embedded within task cards map to Jira's native Checklist feature (available in Jira Premium and with certain Marketplace apps) or are split into separate Jira Sub-Tasks with a checkbox-style label prefix. We extract each checklist item with its checked/unchecked state at migration time. The customer selects the checklist mapping strategy during scoping based on their Jira plan.

Swit task comments migrate as Jira Issue Comments with the full comment text, author (resolved by email match to Jira user), and timestamp preserved. Threading structure from Swit is flattened into a chronological comment list in Jira unless the destination Jira instance has a commenting app that supports threading, in which case we attempt to preserve the reply chain.

We export attachment metadata (filename, size, MIME type, URL, uploader, upload date) from Swit task cards. Attachment file content retrieval depends on whether Swit's storage endpoint is accessible via export; we flag any attachments where the file body could not be retrieved as requiring re-upload in Jira. All retrieved attachments are linked to the corresponding Jira Issue via the Attachment API and the file is uploaded to Jira's attachment storage if the Jira project permits attachments.

Swit Tags on tasks migrate to Jira Labels. Label names transfer directly. Jira Labels are single-string tags without hierarchy, so any nested tag taxonomy in Swit is flattened to a hyphenated label convention documented during scoping.

Swit's task-level time tracking records (duration logged per user per task) map to Jira Worklog entries. Each worklog records the author (resolved by email match to Jira user), date, time spent, and a description. Jira Worklog billing attributes are set to the default values unless the customer specifies custom billing rates during scoping.

Swit priority values (Low, Medium, High, or custom labels) map to Jira Priority values. We preserve the label text from Swit and map it to the closest matching Jira Priority (Highest, High, Medium, Low, Lowest). Custom priority labels from Swit are stored in a custom field on the Jira issue for reference.

Swit custom fields are discovered per-project during discovery. Each project's field set is enumerated individually, and those field definitions are created as Jira instance-level Custom Fields with a context scoped to the relevant Jira projects. Text, number, date, and choice field types map to their Jira equivalents. Multi-select choice fields in Swit map to Jira multi-select or single-select picklists depending on the Swit field configuration.