Migrate from Priority Matrix to Jira

Priority Matrix Projects map to Jira Projects. We extract the project name, description, and creation date from the CSV export and create Jira Projects via the Jira REST API. We flag whether a Priority Matrix project was private or shared; Jira project visibility is set during project creation based on the source privacy flag. If the customer uses Jira Service Management for support queues alongside Software projects, we separate the projects accordingly during scoping.

Priority Matrix Items map to Jira Issues. The Item title becomes the Issue Summary field. The Item body or description becomes the Issue Description in Jira's wiki-rendered text format. Creation date, modification date, and completion status migrate as Created, Updated, and Status fields respectively. Issue type is set to Task by default; Items with a tag containing epic, milestone, or deliverable keywords are promoted to Epic or Story type during scoping configuration.

The four Priority Matrix quadrants (Do First, Schedule, Delegate, Eliminate) are encoded as a Jira custom single-select field named Eisenhower_Quadrant__c. During migration, we map the quadrant label from each Item to the corresponding custom field value. After migration, we document how to create Jira filters (JQL) for each quadrant equivalent: Do First maps to priority in (Highest, High) AND due <= tomorrow; Schedule maps to priority in (Medium, Low) AND due > tomorrow; Delegate maps to labels = delegation; Eliminate maps to labels = archive. We do not configure these filters inside the migration scope; the documentation is delivered as a setup guide for the customer's Jira admin.

Priority Matrix Item due dates migrate as Jira Issue Due Date fields. We preserve the original timezone where available in the CSV export. Items without due dates are flagged as undated and assigned a placeholder of novalue-set during extraction so they do not receive null or default dates in Jira. We deduplicate calendar-sync entries from native due dates by Item ID, keeping the native date and flagging the calendar link as inactive post-migration.

Priority Matrix assignees are resolved by email address against the Jira destination User directory. We extract every distinct assignee email from the Item CSV and match to Jira User accounts. Any assignee without a matching Jira User is placed in a reconciliation queue for the customer's admin to provision before the record import phase runs. Unassigned Items in Priority Matrix are set with no Assignee in Jira. We do not auto-create Jira users from source email addresses without admin confirmation.

Priority Matrix tags migrate as Jira Labels on each Issue. Tags are normalized (lowercased, whitespace trimmed) during extraction to comply with Jira's label format. If the customer uses tags for multi-dimensional categorization (for example, tagging by department, product line, and priority simultaneously), we preserve all tags and document the taxonomy for the customer's admin to replicate through Jira label management. Tags with more than 10 unique values are reviewed during scoping to confirm the label strategy fits Jira's label limits (1,000 labels per issue, 255 characters per label).

Priority Matrix custom fields on Items and Projects are extracted and mapped to Jira custom fields of equivalent type (text fields to Jira Text Field, date fields to Jira Date Field, number fields to Jira Number Field, checkbox fields to Jira Checkbox). We create the destination custom fields in Jira before migration using the Jira REST API for custom field creation. Jira's custom field context (which issue types can use each field) is configured to match the source field's scope; Jira defaults custom fields to all issue types unless scoped explicitly.

Priority Matrix file attachments on Items are exported and re-uploaded to the corresponding Jira Issue as Attachment files. We preserve the original filename and note the original uploader in the file metadata. Large attachment volumes (over 500 files per project) are flagged during scoping because CSV export does not include attachment binary data; we coordinate a separate attachment extraction pass from Priority Matrix's file storage before migration. We do not migrate attachment versions or edit history.

Priority Matrix Item comments migrate as Jira Issue Comments. Each comment's author, timestamp, and text body are preserved. Comment ordering is maintained by the timestamp. Jira does not support threaded comments natively, so flat comment ordering is used even if the source had reply chains. Rich text in Priority Matrix comments is converted to Jira's wiki markup format during extraction.

Priority Matrix Templates define pre-populated Item structures within a Project. We migrate the template schema as a set of draft Jira Issues with Summary and Description fields populated but Status set to Open and no due dates or assignees. Jira project templates (stored as shared configurations) are not created from this data; we deliver a written template inventory listing each Priority Matrix template with its field structure for the customer's admin to configure as Jira project templates post-migration.