Migrate from Artemis 7 to Jira

Artemis 7 Projects map directly to Jira Projects. The project name, description, status (active/archived), and start/end dates migrate as-is. We create Jira Projects in the destination instance before any issue migration begins. Jira project keys are derived from the Artemis 7 project name acronym or a customer-specified prefix during scoping.

Artemis 7 Tasks map to Jira Issues. The task name becomes Summary, status maps to Jira status (To Do, In Progress, Done), assignee resolves via email match to Jira User, and dates map to Due Date. Subtasks (child records with a parent reference) map to Jira Subtask issues with the parent issue linked via the Parent link field. We reconstruct the full parent-child hierarchy during migration by resolving parent references and setting Issue Type to Subtask for nested items.

Artemis 7 Milestones (date-driven markers with a name and due date associated with a Project) map to Jira Versions. The milestone name becomes Version name, due date becomes Release Date, and a description field carries any additional milestone context. Jira Versions can be marked Released or Unreleased to reflect milestone completion state. Jira's Fix Version field on Issues then links issues to the migrated milestone.

Artemis 7 Resource records (user name, role, availability) map to Jira User accounts with project Role assignments. The user's availability percentage does not have a direct Jira equivalent (Jira assigns users to issues individually). We map Artemis resource roles to Jira project roles (Administrators, Members, Viewers) or custom project roles if the customer defines them. Capacity and allocation tracking requires Jira Time Tracking to be enabled post-migration.

Artemis 7 time entries (hours logged against a task and user) map to Jira Worklog records on the corresponding Issue. We map hours logged to Time Spent in Jira's time tracking format (e.g., 4h 30m), and the Artemis entry date becomes the Worklog started date. Jira requires Time Tracking to be enabled on the destination project. Billing rates from Artemis 7 are preserved as a custom field on the worklog since Jira does not natively store billing rates per entry.

Artemis 7 Gantt dependencies (Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish) are stored as relationship metadata. Jira supports Blocks, Blocked By, Depends On, and duplicate link types. We map Finish-to-Start to Blocks, Start-to-Start to a custom link type or Blocks with note, Finish-to-Finish to a custom link type, and Start-to-Finish to a custom link type. Unsupported dependency types are flagged in the migration report for the customer's admin to resolve manually post-migration.

Artemis 7 custom fields exist per-project and are not centrally managed. We export all custom fields as key-value pairs per project during scoping, then consolidate unique field names across all active projects. Fields with the same name but different data types across projects require manual customer confirmation before mapping. We create Jira global custom fields of the appropriate type (text, number, date, select, multi-select) before migration and associate them with relevant projects. Duplicate field names with conflicting data types are the most common source of import errors and are flagged explicitly.

Artemis 7 stores file attachments as URLs referencing its own internal file service. These URLs expire or break when the user account is deprovisioned and are not portable across systems. We do not include attachment URLs in the migrated dataset. We produce a separate attachment flag list (list of Artemis 7 attachment URLs, associated task name, and project name) so the customer's admin can manually re-upload files to the Jira issue post-migration. This list is delivered as a CSV alongside the migration output.

Artemis 7 project status (active, on-hold, completed, archived) maps to Jira project status. Jira project states include Well-managed, Unmanaged, and Archived. Active and On-hold map to Well-managed; Completed maps to Archived. The customer confirms the mapping during scoping since Artemis status naming conventions vary.

Artemis 7 task priority levels (typically 1-5 or Low/Medium/High/Critical) map to Jira Priority values. We confirm the source priority scale during scoping and map to Jira's standard priorities (Highest, High, Medium, Low, Lowest) or to a custom Priority scheme if one exists in the destination Jira instance.