Migrate from TaskRay to Jira

TaskRay Project__c records map to Jira Projects. The Jira Project key (e.g. PROJ) is assigned during import, and the Project name maps from TaskRay Project Name. Project Start and End dates can be stored as Jira Project dates or as custom fields if the Jira instance has the Dates of Project macro enabled. Archived projects in TaskRay map to Archived status in Jira if supported by the Jira edition.

TaskRay Sub-Projects represent child project structures within a parent Project. In Jira, Sub-Projects are modeled as Epic issues within the target Jira Project, with the Epic summary matching the Sub-Project name. If the customer prefers separate Jira Projects per Sub-Project, we can provision one Jira Project per Sub-Project and nest them under the parent Jira Project using the Project hierarchy feature available on Jira Premium.

TaskRay Task Groups represent phases or themes within a project. Jira has no native phase grouping object, so Task Groups map to Jira Epic (if they contain multiple child issues) or to a Jira label prefixed with tg- for identification. The grouping logic is applied during scoping — if the customer relies heavily on Task Groups for reporting, we configure a Jira Epic per Task Group or a custom Jira label field.

TaskRay Task__c records map to Jira Issues of type Story or Task. The mapping uses Task Name as Issue Summary, Task Description as Issue Description, Task Status as Jira Status (mapped via a status translation table we build during scoping), and TaskRay Assignee email matched to Jira User by email. Checklist items are handled separately as Jira subtasks or linked issues.

TaskRay Milestones are single-day tasks visually rendered as diamonds in Plan View. Jira has no native milestone object, so we map Milestones to Jira Issues of type Task with a Milestone label and the milestone date stored in a custom date field. If Jira has the Advanced Roadmaps or Structure add-on, milestones can alternatively map to Roadmap milestones.

TaskRay Checklist Items are granular sub-todo states (checked/unchecked) under a Task. Jira has no native checklist object. We offer two migration paths: (1) Jira Subtasks — each Checklist Item becomes a Jira Subtask under the parent Issue; (2) Linked Issues — each Checklist Item becomes a linked Issue of type Task with a Blocks link back to the parent Jira Issue. The customer selects the strategy during scoping. Completion status migrates as Issue resolution (Done / Open).

TaskRay predecessor/successor links between Tasks map to Jira Issue Links. The TaskRay dependency type (Finish-to-Start, Start-to-Start, etc.) is stored in a custom Jira Issue Link type if required; otherwise, we default to Blocks / is blocked by links which Jira renders in the dependency view. We validate all links after import to ensure the target issue IDs exist in the destination Jira instance.

TaskRay Resources (individual users) map to Jira Users resolved by email address. Any TaskRay Resource without a matching Jira User is held in a reconciliation queue for the customer's Jira admin to provision before record import. TaskRay Roles (placeholder job-function owners) map to Jira Project Roles (e.g. Developers, Designers) if the Jira project uses role-based assignment; otherwise, they map to Jira Groups.

TaskRay custom fields exist as Salesforce custom fields on TaskRay__Project__c, TaskRay__TaskGroup__c, and TaskRay__Task__c objects. We detect all custom fields during export, map them to equivalent Jira custom field types (text, date, select, multi-select, user picker) based on Salesforce field type, and configure them in the destination Jira Project before import. Custom field IDs differ between Salesforce and Jira so the mapping pass is required before any data insert.

TaskRay Template Projects and the Template Migration feature (Premium-only) allow reusable project skeletons in Salesforce. Jira Project Templates serve a similar function. However, we do not migrate TaskRay Templates as Jira Templates because the data structures are incompatible. We deliver a written template inventory documenting every TaskRay template's structure (Task Groups, Tasks, Milestones, Dependencies, Checklist configurations) for the customer's admin to recreate as a Jira Project Template or using Jira's Quickstart functionality.

TaskRay stores files on the Salesforce ContentDocumentLink model, accessible via Salesforce file APIs. We export files attached to TaskRay records and re-attach them to the corresponding Jira Issues via the Jira REST API attachment endpoint (POST /rest/api/3/issue/{issueIdOrKey}/attachments). Null-filename attachments are flagged and excluded per Jira's attachment requirements. Large attachments (over 10 MB per Jira's single-file limit) are chunked and retried with exponential backoff.

TaskRay Project and Task records can contain Chatter threads for team discussion. Chatter posts map to Jira Issue Comments. The Chatter post author and timestamp are preserved in the Jira comment author and timestamp fields. Rich text in Chatter migrates as plain text or Jira-flavored Markdown depending on the content complexity.

TaskRay Resource Capacity and Utilization data (Premium tier) are stored as custom fields on Resources and are migratable. Jira has no native capacity planning in the base product — teams needing this capability typically add Jira Product Discovery or a Marketplace app (Tempo, Structure). We migrate the capacity numeric values as Jira custom number fields for reference, but capacity planning workflows require a separate tool selection and configuration post-migration.