Migrate from Dart to Jira

Dart Workspaces are the top-level organizational unit and map to Jira Projects. If the customer has multiple Dart workspaces, each becomes a separate Jira Project. We resolve the workspace-to-project mapping during scoping and create Jira projects in the target Jira site before any record migration begins. Workspace-level member roles map to Jira project-level roles (Administrators to Project Admin, Members to Member, Viewers to Viewer).

Dart Projects nest inside Workspaces and map to Jira Projects if the workspace maps to a Jira Project, or to a Jira Epic or Label within the target Jira Project if the workspace maps to a parent Jira Project. The customer's Jira project structure determines which mapping applies, decided during scoping.

Dart Tasks map to Jira Issues. The standard fields map 1:1: task title to Issue summary, description to Issue description, due date to Due date, assignee to Assignee. Status in Dart maps to a Jira Status value that we configure as the target workflow's initial state. Custom field values on Dart tasks map to Jira custom fields that we create and assign to the relevant project screens before migration.

Dart Subtasks nested under Tasks map to Jira Sub-task Issues. We preserve the parent_id reference from Dart and set the Jira Sub-task's Parent link to the migrated parent Issue key. Jira Sub-tasks require the Sub-tasks subfeature enabled on the target project, which we configure before migration.

Dart custom fields are defined at the Workspace level and then assigned to tasks within a Project. We extract the full field definition list during discovery, map Dart field types (text, number, date, select, multi-select) to Jira custom field types (Text Field, Number Field, Date Picker, Single Select, Multi Select), and create them in Jira before any task data loads. Field definitions and field values migrate in separate phases.

After custom field definitions are created in Jira and assigned to the relevant project screens, we migrate Dart task custom field values by matching the Dart task_id to the newly created Jira Issue key and writing the custom field values in a second phase. Without this two-phase approach, custom field data is silently dropped because Jira rejects values for fields not yet present in the schema.

Dart stores attachments as linked resources rather than embedded file fields. We iterate each attachment, retrieve its URL and metadata via Dart's API, download the file to temporary storage, upload it to Jira's attachment endpoint (POST /rest/api/3/issue/{issueIdOrKey}/attachments), and link it to the migrated issue. For migrations with thousands of attachments, this adds a meaningful second pass to the transfer timeline.

Dart time entries linked to tasks and users migrate to Jira Worklog records. We resolve the Dart user email to the Jira user accountId before creating the worklog entry. The time entry description and billable flag map to Jira worklog fields. Jira's time tracking subfeature must be enabled on the target project before worklogs can be created.

Dart assignee references link to user IDs. We extract all assignee email addresses, match them against Jira user accounts by email, and create Jira Issue Assignee fields using the resolved accountId. Any Dart user without a matching Jira account is flagged in a reconciliation report for the customer's admin to provision before record migration resumes.

Dart workspace members map to Jira site users. We perform email-based matching during discovery. Jira Cloud sites can have users added manually or via directory sync (Google Workspace, Okta, Azure AD). We flag users that exist in Dart but not in Jira as a provisioning list for the customer's admin before migration begins.

Dart workspace settings including default task templates, notification preferences, and workspace-level integrations map to Jira project settings, notification schemes, and permission schemes. Integration connections do not migrate; we document which integrations need reconfiguration in Jira (Jira + GitHub, Jira + Slack, Jira + CI/CD tools) as part of the post-migration handoff.