Migrate from ProofHub to Jira

ProofHub Projects map 1:1 to Jira Projects. Project name, description, start date, and end date migrate to Jira Project metadata. If the Jira destination has existing projects with the same name, we append a project suffix and flag the collision for the customer's admin to resolve before final import. ProofHub sub-projects map to Jira Projects under the same Jira site or remain as separate Jira projects depending on scoping.

ProofHub Tasklists map to Jira issue types (Story, Task, Bug) configured per project. Each Tasklist name becomes an issue type or maps to an existing issue type based on the customer's naming convention. Tasklist ordering is preserved as the default Jira rank order. If the destination Jira project has an existing Issue Type Scheme, we append the new issue types to it rather than replacing it.

ProofHub Tasks map 1:1 to Jira Issues. Task title becomes Summary, description becomes Description, start date maps to Jira's custom Start Date field (if installed) or remains as a custom field, due date maps to Due Date, priority maps to Priority (with ProofHub's low/medium/high normalized to Jira's Low/Medium/High/Highest/Lowest), and labels migrate as Jira Labels. Assignee resolution requires matching by email to Jira User records.

ProofHub Subtasks map to Jira Sub-Task issues linked to their parent Issue via the Parent Link field. Subtask title, assignees, due dates, and description migrate directly. The Jira project must have Sub-Tasks enabled in its Issue Type Scheme, which we configure before migration begins.

ProofHub Milestones map to Jira Versions with the same name and due date. The version description carries the milestone notes. We create Version entities before issue import and link each relevant Issue to its corresponding Fix Version/s. ProofHub's milestone-to-multiple-tasks relationship maps to Jira's multiple Issues referencing the same Version as their Fix Version/s.

ProofHub time entries map to Jira Issue Worklog records. Each worklog carries the logged hours, date, author (resolved by email match to Jira User), and the associated Issue (resolved by the ProofHub task-to-Jira issue mapping). Billable/non-billable flags from ProofHub migrate to a custom worklog field billable__c on the Jira side. Jira's time tracking must be enabled in the destination project before worklogs can be imported.

ProofHub standalone Notes attached to Projects migrate as Jira Project-level Description if the project description is empty, or as a Jira Issue with type Comment if the note content is task-specific and a matching issue exists. Notes content migrates as plain text or wiki markup. Formatted notes may lose styling during migration.

ProofHub Discussion threads attached to Projects or Tasks migrate to Jira Issue Comments. We preserve the thread structure by ordering comments by timestamp. Author, timestamp, and body content transfer directly. Nested replies become individual comments with the parent-child relationship noted in the comment body for manual reconstruction if needed.

ProofHub custom fields (text, textarea, dropdown, multi-select, number, percentage, currency, date, priority) map to Jira custom fields of equivalent type. We pre-create the Jira custom field schema before migration, including the field context (project and issue type association). Dropdown and multi-select values migrate as Jira custom field options. Field-level security on Jira custom fields requires admin configuration post-migration.

ProofHub task labels migrate as Jira Labels on the corresponding Issue. Labels are a flat string array in both platforms, making this a direct 1:1 transfer. We deduplicate label values during transformation and flag any labels exceeding Jira's character limit for manual truncation.

ProofHub files attached to tasks or projects migrate as Jira Issue Attachments. We download files from ProofHub, re-upload to the mapped Jira Issue via the Jira REST API, and preserve the original filename and uploader metadata. File version history is lost; only the latest version of each file migrates. The Jira project must have attachments enabled.

ProofHub workflow stage names and basic transition rules are documented in a written workflow inventory that we deliver to the customer. Complex branching rules, automation triggers, and conditional logic require manual reconfiguration in Jira because Jira workflows use a different rule engine. We map ProofHub stage names to Jira statuses and include the transition sequence in the handoff document.