Migrate from WP Project Manager to Jira

WP Project Manager projects (wp_cpm_projects) map directly to Jira Software projects. We extract project title, description, created date, status, and user role assignments (project_member table with role per user). In Jira, we provision the project with the matching project key, project lead (resolved from WordPress user to Jira user), and default project type (team-managed or company-managed). Visibility settings in WP PM (private vs public) translate to Jira project access levels configured per project.

WP PM tasks are type=task records in wp_cpm_messages with a project_id foreign key. We map task title, description, due date, priority (numeric to Jira PriorityId), status, and assignee (WordPress user ID resolved to Jira account). The original WP PM task ID is preserved in a custom field cpm_task_id__c for audit traceability. Task creation timestamps migrate as Jira Issue Created date.

Subtasks in WP PM are stored in wp_cpm_task_relations with a parent task_id reference. We reconstruct the subtask hierarchy by preserving parent-child links and landing them as Jira sub-task Issue types under their parent Issue. Subtask title, status, assignee, and due date map identically to the parent task mapping. Jira sub-tasks inherit the parent's project and Issue type context automatically.

WP PM milestones are type=milestone records in wp_cpm_messages. We map milestone title, due date, and linked task_ids. Milestones land in Jira as Versions (Releases) with the milestone due date as the Release target date. The associated task list is preserved as a Jira filter shared with the project team. A custom label milestone_name is added to each linked issue for quick filtering across milestones.

Comments are stored in wp_cpm_task_comments linked to task_id. We preserve comment body (rich text), author WordPress user ID (resolved to Jira account), timestamp, and attachment file path references. Comments land as Jira Issue Comments with the Jira account displayed as comment author. Threaded comment replies in WP PM map to Jira comment hierarchy where the Jira version supports it.

Attachments are stored as WordPress post attachments linked to tasks or comments via post_parent. Files live in wp-content/uploads. We map file paths and re-attach them to the corresponding Jira issues via the Jira REST API multipart upload endpoint. If file path references contain absolute URLs with the source WordPress domain, we strip and normalize them during transfer. This requires a parallel SFTP file sync step alongside the database export.

Custom Fields in WP PM are stored as PHP-serialized arrays in wp_postmeta with no stable field schema across projects. We deserialize the data per project, infer field types (text, number, date, select, multi-select), and create equivalent Jira system-level custom fields with contexts scoped to the relevant projects and issue types. We preserve the original field names as custom field descriptions for the customer's admin to verify mapping after migration. Any deserialization parse failures are flagged and reported in the migration summary.

Assignees, commenters, and project administrators in WP PM are stored as WordPress user IDs referencing wp_users. We export wp_users as a separate step, resolve each by email address against the destination Jira instance, and hold unmapped users in a reconciliation queue for the customer's admin to provision before record import resumes. Original WP user ID is preserved in a custom field wp_user_id__c on the Jira User record for audit.

Time tracking entries (premium module) are stored in a WP PM sub-table with user_id, task_id, start timestamp, end timestamp, duration in seconds, and notes. We extract these records and land them as Jira Issue Worklog entries with the original start time as worklog startedAt and duration as timeSpentSeconds. Billable rate configuration from WP PM's Invoice module does not migrate.

Gantt task dependencies in WP PM are stored in wp_cpm_task_relations with a relation_type field indicating dependency direction. We extract dependency links and reconstruct them in Jira as Issue Links with link types blocks, is blocked by, or relates to depending on the WP PM relation_type. The destination Jira project must have the relevant issue link types enabled in project settings.