Migrate from WP Project Manager to monday Work Management

WP Project Manager Projects (stored in wp_cpm_projects) map to monday.com Boards. Each Project's title, description, start date, and end date map to the Board's name, description, and date range columns. Project visibility (public/private) maps to monday.com Board privacy settings. We extract project-level user role assignments from wp_cpm_project_members and apply them as Board-level permissions in monday.com Workspace during migration. Projects are imported first as the top-level container so that all child records (Tasks, Milestones) can resolve their parent-project lookup.

WP Project Manager Tasks (records with type=task in wp_cpm_messages) map to monday.com Items within a Board. Task title, description (stored as post_content), due date, priority (high/medium/low), and status (open/archived) map to monday.com Item name, text column, date column, priority column, and status automation or label column. The original wp_cpm_messages task_id is preserved in a text column for reconciliation. Tasks reference their parent project via project_id, which we resolve to the monday.com Board ID during the mapping phase.

WP Project Manager Subtasks are stored in wp_cpm_task_relations linked to a parent task_id. Each Subtask is a child record with its own title, description, due date, assignee, and status. We reconstruct the subtask hierarchy by iterating wp_cpm_task_relations and creating monday.com Sub-items under the parent Item that corresponds to the parent task. The subtask-to-parent relationship is preserved 1:1 in monday.com's Sub-items structure. If a task has multiple levels of subtasks, we flatten them to a single level of Sub-items as monday.com does not support nested Sub-items beyond one level.

WP Project Manager Milestones (records with type=milestone in wp_cpm_messages) are project-level milestones with title, due date, and linked task_ids. We offer two migration strategies: map Milestones to monday.com Groups (with the milestone title as group name and linked tasks as items within the group), or map them to Labels with a dedicated label color. The choice depends on whether the customer uses Groups structurally in their monday.com boards or relies on Labels for classification. Milestone due dates migrate to a date column on the milestone label or as a milestone date field if the board uses the Timeline or Gantt view.

WP Project Manager Comments (stored in wp_cpm_task_comments linked to task_id) map to monday.com Updates on Items. Comment body, author (WordPress user ID resolved to monday.com user), timestamp, and any attachment file IDs migrate to the Update body with author attribution. File attachment references in comments are resolved by extracting the attachment post record from wp_posts and uploading the file to monday.com before creating the Update so that the file attachment appears inline. Updates are inserted in chronological order by timestamp.

File attachments in WP Project Manager are WordPress media library entries (post_type=attachment in wp_posts) with post_parent pointing to the task or comment. Files reside in wp-content/uploads with a file path stored in guid and _wp_attached_file meta. We extract the file paths, download the files via SFTP or the hosting file manager, and upload them to monday.com via the monday.com Files API, attaching each file to the corresponding Item. Absolute URL references containing the source domain are normalized to strip the domain and preserve only the path. The maximum file size in monday.com is 500MB per file; files exceeding this are flagged for the customer to store externally and link.

Custom Fields in WP Project Manager are stored as PHP-serialized arrays in wp_postmeta, with field names and values varying per project setup. We run a deserialization script against wp_postmeta to extract all key-value pairs, normalize field names to lowercase_snake_case, and infer the data type (text, number, date, dropdown, person, link) by examining the PHP-serialized value. Each distinct custom field schema across projects is then created as a monday.com Column in the target Board before Item migration begins. Multi-select custom field values (stored as serialized arrays in PHP) map to monday.com dropdown columns with the values pre-populated as column options.

WP Project Manager stores assignees, commenters, and project administrators as WordPress user IDs referencing wp_users. We export wp_users (ID, user_email, display_name, user_registered) and match by email against the monday.com Workspace's existing team member list. Any WordPress user without a matching monday.com account goes to a reconciliation queue where the customer provisions a monday.com user before migration resumes. Role assignments per project (wp_cpm_project_members: is_admin, is_manager, is_member) are mapped to monday.com Board-level permissions (owner, editor, viewer) based on the highest role held.

Time Tracking entries in WP Project Manager (premium module, stored in a separate sub-table) include user_id, task_id, start_time, end_time, and notes. These map to monday.com Time Tracking column entries on the corresponding Item. Each time entry's duration is computed from start_time and end_time, and the WordPress user_id is resolved to a monday.com team member for attribution. Time entry notes map to the entry description. The monday.com Time Tracking column requires Pro or Enterprise plan; we confirm the destination plan before migrating time tracking data.

Gantt chart dependencies in WP Project Manager are stored in wp_cpm_task_relations as serialized arrays (wp_postmeta with meta_key patterns like _pm_dependency). We deserialize the dependency records to extract task_id pairs representing predecessor-successor relationships. These map to monday.com Dependency columns on Items, where each Item lists its dependent Items. Start date and due date from the task records populate the monday.com Timeline or Gantt view so that dependency chains render correctly. Circular dependencies are detected during transform and flagged for the customer to resolve before import.

Recurring task rules in WP Project Manager are stored as serialized data in wp_postmeta with recurrence pattern (daily, weekly, monthly) and next_occurrence_date. monday.com does not have a native recurring task object; recurring scheduling is handled through Automations with date-based triggers. We extract the recurrence pattern and next occurrence date and document them as a recommended monday.com Automation rule (trigger: date column equals today, action: create item or duplicate item) that the customer's admin configures post-migration. We do not create recurring instances as static records because they would be stale from the day of migration.

WP Project Manager Invoice records (premium module, tightly coupled to WooCommerce orders and Stripe transactions) have no clean export path. The Invoice module stores billing data in a format that references WooCommerce order IDs and Stripe transaction metadata without a standalone export. We do not migrate Invoice financial records. Before migration begins, we recommend exporting invoices as PDF reports from WP Project Manager's UI and storing them in a shared drive. The associated task and time tracking data migrates normally; the customer re-creates invoices in their preferred accounting tool post-migration.

WP Project Manager's Kanban column positions and visual board state are stored as JavaScript-serialized data in wp_postmeta with no stable column-schema structure. The column order and swimlane layout are client-side state rather than persisted server data, making reliable extraction impossible. We do not migrate the visual Kanban layout. Task data (title, description, assignee, due date, priority, status) migrates to monday.com Items, and the customer recreates the Kanban view in monday.com by applying the appropriate Group structure or using monday.com's native Kanban column view.

Team categories and project-level permission assignments in WP Project Manager are stored in plugin-specific options tables (wp_options with meta_key patterns like pm_team_ or cpm_permission_). Role assignments per user per project require careful mapping to monday.com's Workspace-level team structure and Board-level permission model. We extract all unique team-role mappings, normalize them into a permission matrix (which users have owner/editor/viewer access to which boards), and document the mapping as monday.com Workspace permission settings and Board-level invites for the customer to apply post-migration.