Migrate from awork to Jira

awork Projects map directly to Jira Projects. We preserve project name, description, start and end dates, assigned users, and budget fields. Jira Projects require a project key (e.g., ENG, MKT) which we derive from the awork project name's initials or a customer-specified prefix. Projects are created first in the migration sequence so that subsequent task and time-entry imports have a valid parent reference.

awork Tasks map to Jira Issues. The mapping to Jira Issue type (Story or Task) is determined during scoping based on the customer's workflow conventions. We preserve task name as Summary, description as Description, due date as Due Date, assignee as Assignee, and status by applying the collected awork workspace status schema to the Jira project's workflow scheme. awork's priority tagging (absent as native sortable tags) is mapped to Jira Priority values (Highest, High, Medium, Low) based on any existing priority indicators in awork.

awork Subtasks map to Jira Sub-Task Issue type. The parent-child relationship is preserved by setting the parent Issue key on each subtask during import. Jira's Sub-Task issue type is enabled per project in the Issue Type Scheme before migration. We flag subtask ordering if the destination project relies on rank-based ordering (such as Jira's backlog ranking algorithm) since awork does not expose a native sort order field.

awork workspace members map to Jira Users by email address. We extract all users referenced in awork task assignments, project assignments, and time entries. The Jira destination site's admin provisions the corresponding users before migration begins. Any awork user without a Jira match goes to a reconciliation queue for admin provisioning. Inactive Jira users are supported for historical assignment preservation.

awork Time Entries map to Jira Issue Worklogs. We preserve the user attribution (matched to Jira User), start timestamp as Started, duration as Time Spent, and billable flag as a custom worklog field billable__c. The parent Issue key is resolved from the awork task reference. Jira's worklog model requires a Started timestamp and time spent value; we derive these from awork's time entry start/end or duration fields. Non-billable entries are imported with the billable flag set to false.

awork workspace statuses require a per-project value map because each awork workspace defines its own status names, colors, and ordering. During scoping we collect every distinct status value across all source workspaces and map them to Jira Status values appropriate for the destination project's workflow scheme. For example, awork status 'In Review' may map to Jira 'In Review' or 'In Progress' depending on the target workflow. We apply the map during the task import phase to avoid misclassifying task states.

awork Custom Fields (workspace-level, activated per-project) require activation verification in Jira. We check each custom field's project-level activation status in awork during scoping. Fields not activated for a given project do not appear in that project's task export. In Jira, we create equivalent custom fields via the project Custom Fields configuration, match field types (text to Text Field, number to Number Field, date to Date Picker), and map values during task import. Custom field context mismatches are a known Jira import issue and we address them before loading.

awork Tags map to Jira Labels. Tags export as key-value labels applied to tasks and carry across in the task data export. Jira Labels are a flat string field with comma-separated values per issue. We preserve tag names exactly, flag any tag normalization needed if Jira enforces label format restrictions (lowercase, no spaces) per the destination site's configuration.

awork Project Templates define reusable project structures including default tasks, statuses, and custom field configurations. Jira does not have an equivalent template import mechanism, so we document the template structure as a written specification (default tasks, configured statuses, custom field defaults) for the customer's Jira admin to recreate using Jira's project template creation flow. The template's task and status definitions are preserved in the migration inventory document.

awork Clients do not have a direct Jira equivalent. Jira Projects are the primary container and can be categorized using Project Categories or Components for sub-grouping. We discuss the client's preferred structure during scoping: either one Jira Project per awork Client (using Project Category for grouping), or multiple awork Projects within a single Jira Project using Components or Labels to distinguish client attribution. The chosen strategy is applied before migration begins.