Migrate from Work as Team to Jira

Work as Team Projects map to Jira Projects. The Project key (e.g., ENG, PROD) must be defined during scoping; Jira enforces uniqueness and a 2-10 character uppercase alphanumeric key. We extract the project name and description from Work as Team and use the Work as Team project URL as a reference field in Jira until cutover. If the Work as Team account has multiple projects that should be combined under one Jira project, we document the split or merge decision during scoping.

Work as Team Lists are the most significant schema decision in this migration. Jira has no native List equivalent. The standard mapping routes Work as Team Lists to Jira Epics (when Lists represent large work groupings) or to Labels on Stories (when Lists represent categories). We survey List count, average task count per List, and whether milestone-style tracking is used before recommending one approach or a mixed approach. The customer's Jira admin confirms the mapping before extraction begins.

Work as Team Tasks map to Jira Stories or Tasks. By default, we map Tasks to Jira Stories unless the Work as Team task is clearly an administrative action (e.g., a checklist item with no due date or assignee) in which case we map to Jira Tasks. Jira Issue Type field, Summary, Description (migrated as Jira Description in Atlassian Document Format), Assignee, Reporter, Due Date, Priority, and Status transfer directly. Task URLs are preserved in a custom field tw_original_url__c for audit.

Work as Team sub-tasks map to Jira sub-tasks. The parent Jira issue must exist before the sub-task is inserted, so we migrate parent records first and resolve the parent key at migration time. Jira enforces a two-level sub-task ceiling by default; deeper Work as Team nesting flattens to Jira sub-tasks with a note in the description.

Work as Team Milestones map to Jira Fix Version (release). Milestone name, description, and target date transfer. Fix Version is a shared field across all issues in a Jira project, so a Work as Team milestone with tasks spanning multiple Lists appears as a Fix Version with all mapped issues associated. If the customer uses milestone status tracking, we map milestone completion to Fix Version release status.

Work as Team time entries map to Jira worklog entries. Work as Team stores duration (in minutes or hours) with an optional date and description; Jira requires time spent (format: 1h 30m) and started date. We transform duration to Jira's time-spent format, set started to the original Work as Team date, and preserve the description as the worklog comment. Billable flag from Work as Team maps to a custom field tw_billable__c since Jira's native worklog does not have a billable field; ERP billing integrations read this custom field.

Work as Team file attachments (images, documents, PDFs) attached to tasks migrate to Jira Attachments linked to the corresponding Jira issue. File URL is stored in the Jira Attachment comment. Jira has a 10 MB per-file limit on cloud; files exceeding this threshold are flagged for the customer to host externally and link from the Jira description. We extract file names and sizes during scoping to identify any files requiring this handling.

Work as Team team members map to Jira users. We match by email address. Any Work as Team team member without a corresponding Jira user account is held in a user reconciliation queue; the customer's Jira admin provisions the missing accounts (active or inactive based on whether the person is still active in Work as Team) before record migration begins. Role and permission structure migrates as a written inventory document, not as Jira permission schemes, since Work as Team's permission model does not map 1:1 to Jira's scheme-based model.

Work as Team comments on tasks migrate to Jira comments on the corresponding Jira issue. Comment author maps to Jira comment author (by email match to Jira user); comment body migrates as Jira comment text. Comment timestamps are preserved for audit ordering.

Work as Team task dependencies (blocks, blocked by, depends on) map to Jira Issue Links (blocks, is blocked by, dependency). We resolve the target issue key at migration time since Jira issue keys are generated during import rather than pre-existing. Dependencies that form a circular reference are flagged and escalated to the customer for resolution before the dependency phase runs.

Work as Team tags (applied to tasks as category markers) map to Jira Labels. Labels are flat strings in Jira, so multi-value tags from Work as Team become space-separated labels on the Jira issue. If the customer uses Work as Team tags as a two-level taxonomy (e.g., department:design), we discuss converting to Jira Labels with a separator convention or a custom field for structured tagging.

Work as Team custom fields (text, number, date, dropdown, checkbox, user reference) map to Jira custom fields of the equivalent type. Jira custom fields must be created in the destination project before migration; we pre-create the full custom field schema during the sandbox migration phase. Custom fields that do not have a Jira equivalent (e.g., Work as Team billing rate fields) are mapped to Jira text fields or custom fields of the closest Jira type, with the mapping documented in the field inventory delivered with the migration.