Migrate from SP Project Tracker to Jira

SP Project Tracker Projects map directly to Jira Projects. Each Jira project requires a Project Key (alphanumeric prefix for issue IDs) that we derive from the SP Project Tracker project name during scoping. If the project name contains characters that are invalid in Jira Keys (spaces, special symbols), we strip and uppercase them. Project-level custom fields from SP Project Tracker require Jira custom fields created in advance; we configure these during the schema pre-configuration phase before any issues are imported.

SP Project Tracker Tasks map to Jira Issues. We map task name to Jira Summary, task description to Description, deadline to Due Date, and completion percentage to Jira's native resolution fields. Priority mapping follows SP Project Tracker's priority levels (High, Medium, Low) to Jira Priority IDs (1=Highest through 5=Lowest). Each issue is created in the corresponding Jira Project determined by the source project mapping. Task-level custom properties migrate to Jira custom fields after schema pre-configuration.

SP Project Tracker subtasks are not a separate object in the source—they are rows in the Tasks export with a non-null parent_task_id column. We detect these rows by filtering for parent_task_id presence, then create Jira Sub-Task issues linked to their parent Jira Issue. The Jira Sub-Task issue type must be enabled in the destination project before migration begins. We reconstruct the hierarchy in the correct creation order to satisfy Jira's requirement that parent issues exist before subtasks can be linked.

SP Project Tracker Time Entries map to Jira Issue Worklogs. Each worklog records hours worked, the performing user (resolved by email to a Jira User), and the date. Jira's Log Work modal stores worklog start time, duration, and comment. Note that Jira Worklogs attach to an Issue rather than a Project, so every time entry must be resolved to a specific Jira Issue. We use the SP Project Tracker task-to-Jira issue mapping to route worklogs to the correct issue ID. Billable/non-billable flags from SP Project Tracker are preserved in a custom worklog field if the Jira project schema supports it, otherwise flagged for manual annotation.

SP Project Tracker team members are referenced by display name and email in tasks and time entries. We extract the Team Members export, match each assignee by email against the destination Jira site's user directory, and resolve OwnerId references during issue creation. SP Project Tracker team members with no Jira account are flagged in a reconciliation queue. The customer provisions any missing Jira users before record migration continues, because Jira requires a valid AssigneeId on issues.

SP Project Tracker task comments migrate as Jira Issue Comments. We preserve the author display name as Jira comment author (resolved to Jira User where possible), the comment body as comment text, and the original timestamp as Jira comment creation date. Threaded nesting from SP Project Tracker does not transfer as threaded replies in Jira; comments appear in chronological order on the Jira issue activity stream.

SP Project Tracker tags are flat labels on tasks. We map them to Jira Labels, which are free-text tags on issues. Jira Labels are applied per issue, and the label vocabulary is shared across the Jira site. We sanitize SP Project Tracker tag names (removing spaces, special characters, and length over 255 characters) to match Jira's label format. Jira Labels are created on first encounter during migration and accumulate across all imported issues.

SP Project Tracker attachments at the task or project level migrate to Jira Issue Attachments. We download each file from SP Project Tracker's authenticated file store during the attachment phase of the export, then upload to the corresponding Jira Issue using the Jira REST API. Attachment URLs that expire after the SP Project Tracker session must be captured during the export window before the session ends. We validate each URL resolves to a downloadable file before queueing for re-upload.

SP Project Tracker project-level custom fields are property bags stored per project. Each custom field key-value pair requires a corresponding Jira custom field created in the destination project before migration. We map field types: text properties to Jira Text Field (short text) or Text Area (long text), numeric properties to Number fields, date properties to Date fields, and dropdown values to Jira Select (radio button) or Multi-Select fields. Jira's field configuration is project-specific, so each destination Jira Project requires its own custom field creation if the project uses a different field configuration scheme.

SP Project Tracker task-level custom fields follow the same pre-configuration requirement as project-level fields. We audit every distinct custom field key across all tasks during discovery, deduplicate by type, and create Jira custom fields per destination project. Jira custom fields must be added to the appropriate Screen before they appear in the issue UI; we coordinate with the customer to identify which screen each field should appear on during the schema design phase. Fields with no Jira type equivalent are flagged as unmapped and documented for manual entry post-migration.