Migrate your WP Project Manager data

Projects are the top-level container stored in the wp_cpm_projects table. We extract project metadata (title, description, visibility, dates) and user role assignments. Migration lands as top-level workspaces or projects in the destination.

Tasks live in wp_cpm_messages with a type=task flag. We map task fields including title, description, due date, priority, and status. The task's project_id foreign key is preserved so task-to-project hierarchy is maintained during migration.

Subtasks are stored in wp_cpm_task_relations, linked to a parent task_id. We reconstruct the subtask hierarchy by preserving the parent-child relationship and landing them as nested children in the destination task model.

Milestones are stored as type=milestone records in wp_cpm_messages. We extract milestone title, due date, and linked task_ids. Task-to-milestone associations are migrated as labels or groups in the destination.

Comments are stored in wp_cpm_task_comments linked to task_id. We preserve comment body, author (WordPress user ID), timestamp, and attachment references. Author mapping is handled via the WordPress user table.

Attachments are stored as WordPress post attachments linked to tasks or comments via post_parent. Files live in the wp-content/uploads directory. We map file paths and re-attach them to the corresponding records in the destination. Large attachment volumes may require a separate file transfer pass.

Custom Fields in WP Project Manager are stored as serialized arrays in wp_postmeta. The field structure varies per project setup. We deserialize the data, normalize field names, and map values into the destination's custom field schema. Fields that do not exist in the destination are flagged for manual review.

Users are WordPress native accounts. Assignee data references wp_users by ID. We map WP user IDs to destination user records, but WordPress roles and capabilities are not directly comparable to most SaaS PM tools — we create a flat assignee list and leave capability mapping for post-migration configuration.

Team categories and project-level permissions are stored in plugin-specific options tables. Role assignments per user per project require careful mapping to the destination's access control model, which may not support identical permission granularity.

Time tracking is a premium module stored in a separate sub-table. Entries include user_id, task_id, start/end timestamps, and notes. We extract these as time entries and land them in the destination's time tracking object, noting any duration-calculation differences.

The Invoice module stores billing records separately. These are tightly coupled to WooCommerce or Stripe integrations and do not have a clean export path. We do not migrate Invoice records — we recommend exporting invoices as PDF from WP Project Manager manually before migration.

Kanban column positions and board state are stored in JavaScript-serialized format in wp_postmeta. There is no stable column-schema export. We do not migrate the visual board layout — task data migrates, but the Kanban view configuration resets to the destination default.

Gantt data is derived from task start dates, due dates, and dependencies stored in wp_cpm_task_relations. We extract dependency links and reconstruct them in the destination's Gantt or dependency model. Custom Gantt-style columns are not natively supported.

Recurring Task module stores recurrence rules as serialized data in wp_postmeta. We extract the recurrence pattern (daily, weekly, monthly) and next occurrence date. The destination's recurrence engine may interpret these rules differently, so we flag all recurring task records for manual validation.