Migrate from Copper Project to Jira

Copper Project maps directly to Jira Project. Each Copper Project becomes a Jira Project with its name, description, status, start and end dates preserved. We create Jira Projects in the destination first since Tasks are children of Projects. If the customer uses Jira company-managed projects, we map Copper project-level custom fields to Jira project-level properties. Team-managed Jira projects have a flatter custom field model; we flag this distinction during scoping.

Copper Tasks map to Jira Issues. We classify each task by examining its status and hierarchy: tasks with no sub-tasks and a simple completion workflow map to Jira Story or Task; tasks with sub-tasks map to Jira Epic or Story with Sub-task children; bug-type tasks from Copper map to Jira Bug. The task title becomes Issue Summary, description becomes Description, assignee maps to Jira Assignee, due date maps to Due Date, and status maps to Issue Status via a configured Jira workflow. Parent-child task relationships in Copper become Jira Sub-task hierarchies or Epic-Story links depending on depth.

Copper Task Timers map to Jira Worklog entries. Each timer record carries duration, task association, and user. We link the worklog to the corresponding Jira Issue (from the Task mapping), set the started date to the timer start timestamp, and set time spent to the timer duration. Jira's worklog model is per-issue, so if a Copper timer spans multiple tasks, we split it into separate worklog entries per task with the duration pro-rated.

Copper files attached at the Project or Task level map to Jira Attachments on the corresponding Issue. Copper uses an S3 signed-URL upload flow; we fetch files via the Copper API, stage them locally, then upload to Jira as binary attachments via the Jira REST API. File name, MIME type, size, and upload date are preserved. File comments and version history in Copper do not have a Jira equivalent and are noted in the divergence inventory.

Copper Timesheet entries represent user-level logged hours independent of specific tasks. Jira's native worklog is issue-linked, not user-level. We map timesheet entries to Jira Worklog entries on the closest related Issue (resolved by task association in Copper), and create a custom Jira field timesheet_source__c set to true for records that originated as Copper timesheets. If the customer uses Tempo Timesheets for Jira, we create Tempo Worklog entries that preserve the user-level timesheet structure more faithfully.

Copper Invoices (line items, amounts, status) have no native Jira equivalent. Jira does not include invoicing as a standard feature. We create a Jira Issue per Invoice with custom fields for line item data (invoice_number__c, amount__c, status__c), or we export Invoices to a structured CSV and recommend the customer store them alongside Jira as an external document. The mapping approach is confirmed with the customer during scoping based on their billing workflow.

Copper Project-level custom fields map to Jira project-level custom fields. We discover all active custom field definitions via the Copper API before migration, enumerate their data types (text, number, date, dropdown), and create matching Jira custom fields with the same API-safe names. Field Layouts controlling UI visibility in Copper are not migrated as they are workspace-level display preferences with no data content.

Copper Task-level custom fields map to Jira Issue-level custom fields. The same field discovery and type-mapping process applies as for project-level custom fields. We note that Jira company-managed projects enforce a different custom field schema than team-managed projects; if the destination uses both, we map accordingly per Jira project configuration.

Copper Users (name, email, role, avatar) map to Jira Users by email match. We extract every distinct user referenced on Projects, Tasks, Timers, and Files and match by email against the Jira destination. Inactive users in Copper are exported but marked as such for customer review. Jira Cloud requires that users accept an invite to access the site; we flag any user records that require manual invite acceptance before they can be assigned in Jira.

Copper's Related Items feature creates relational links between entities (e.g., Task A is related to Task B). Jira supports issue linking with named link types (blocks, is blocked by, relates to, duplicates, is cloned by). We export Copper Related Items as explicit associations and map them to Jira Issue Links using the closest matching link type. If no suitable link type exists in the destination Jira project, we create a custom link type during project configuration.