Migrate from WP Project Manager to Trello

WP Project Manager Projects from wp_cpm_projects map to Trello Boards. We extract project title, description, visibility setting, and start/end dates. The project name becomes the Board name. Each Board gets a default List (e.g., 'To Do', 'In Progress', 'Done') created during Board setup. Project-level permissions from WP Project Manager map to Board membership roles — project administrators become Board admins, and team members become Board normal members. Boards are created via the Trello REST API before any Cards are imported so that the Board ID is available as the parent reference.

WP Project Manager Tasks (type=task in wp_cpm_messages) map to Trello Cards. We extract task title (as Card name), description (as Card description in markdown), due date (as Card due date), priority integer (as a colored Label or Card cover), and status. The task's project_id foreign key is resolved to the corresponding Trello Board ID during import. Open tasks map to Cards in the 'To Do' List; completed tasks (with a done or closed status flag) map to Cards in the 'Done' List. Cards are created via the Trello REST API with parent Board ID and List ID resolved at migration time.

Subtasks stored in wp_cpm_task_relations with parent_id referencing the parent task_id map to Checklist items on the corresponding Trello Card. We reconstruct the subtask tree by preserving the parent-child relationship and landing each subtask as a named checklist item with its own completion status. Trello checklists are flat — there is no nested checklist depth in any Trello tier, so multi-level subtask hierarchies from WP Project Manager (e.g., task > subtask > sub-subtask) flatten to a single checklist level. We flag any subtask records that exceed two levels of nesting in the migration summary so the customer is aware of the depth reduction.

Milestones are type=milestone records in wp_cpm_messages. Task-to-milestone associations are stored as linked task_ids. We offer two migration strategies during scoping: (a) Premium/Enterprise Trello — create a colored Label for each milestone and attach it to all Cards linked to that milestone; (b) Free/Standard Trello — create a dedicated 'Milestones' List and place milestone Cards in that List. The customer chooses the strategy. We preserve milestone title, due date, and linked task count in the migration summary for reconciliation.

Task comments stored in wp_cpm_task_comments linked to task_id migrate as Trello Card Comments via the Trello REST API. We extract comment body (as markdown), author WordPress user ID, and comment timestamp. Author mapping resolves the WordPress user ID to a Trello member by email — if the member email has no matching Trello account, we use the WordPress display name as the comment author text and flag it in the reconciliation report. Comment ordering is preserved by timestamp. Comment attachment references point to the corresponding Card attachment that we import separately from the WordPress uploads directory.

File attachments are stored as WordPress post attachments linked to tasks or comments via post_parent. The actual files live in wp-content/uploads. We extract the attachment post record (file path, filename, MIME type) and pair it with a file transfer step. The customer provides SFTP or hosting file manager access to the wp-content/uploads directory, and we sync files to a cloud storage location accessible to Trello or directly re-upload them as Card attachments via the Trello API. File path references containing the source domain are stripped and normalized. If files exceed Trello's per-attachment size limits (10MB on Free, 250MB on Standard/Premium), we flag the oversized files for the customer's admin to handle manually.

Custom Fields in WP Project Manager are stored as PHP-serialized arrays in wp_postmeta with per-project field definitions that vary in structure. We deserialize each array, normalize field names, and map values into Trello Custom Fields (Premium/Enterprise only) or convert to colored Labels (Free/Standard). For Premium/Enterprise destinations, we create the corresponding Custom Field definition in the destination Board before data import and map the WP Project Manager value to the nearest Trello field type (text, number, date, checkbox, dropdown). For Free/Standard, we fall back to label-based encoding and document the mapping in the inventory handoff. Any Custom Field values that fail to deserialize (due to PHP serialization format changes after WordPress upgrades) are flagged in the migration summary.

Users are WordPress native accounts stored in wp_users. Assignee data references wp_users by ID on Tasks and subtasks. We export wp_users as a separate step (display_name, user_email, user_registered) and match by email address against Trello member invites. Each matched user receives a Board membership invitation via the Trello API. If a WordPress user has no corresponding Trello account, we hold that assignment in a reconciliation queue — the customer provisions the Trello account and we re-run the assignment step. WordPress roles and per-project capability levels cannot be mapped 1:1 to Trello's Board-admin/normal-member model; we default to normal member and the customer elevates any admin-level users manually post-migration.

Time tracking entries (premium module) stored in a separate sub-table contain user_id, task_id, start/end timestamps, and notes. We extract these as checklist items on the parent Card with the time range in the item name (e.g., 'Time: 2h 15m — 2025-09-01 09:00-11:15') and the notes content preserved as the checklist item description. Trello has no native time tracking feature at any tier; a dedicated time tracking Power-Up is the recommended replacement post-migration, and we document this in the inventory handoff.

Task dependencies stored in wp_cpm_task_relations (start-to-start, finish-to-finish, finish-to-start types) are extracted as linked Card references. For Premium Trello destinations, we create a 'Blocked By' or 'Blocking' label and attach it to the dependent Card referencing the blocking Card's name and URL. For Standard and Free tiers, we add a checklist item to the dependent Card with the blocking task name and link text. Trello has no native dependency graph, so the relationship is encoded as metadata rather than enforced as a blocking rule. A dedicated Power-Up like Card Peek or Dependencies for Trello is the recommended post-migration replacement for teams that need enforced dependency logic.

Recurring task rules stored as serialized data in wp_postmeta contain recurrence pattern (daily, weekly, monthly) and next occurrence date. We extract the recurrence pattern and next date and encode them as a labeled Card description annotation (e.g., 'Recurrence: Monthly — next: 2025-10-01') plus a colored Label. Trello has no native recurrence engine; the customer rebuilds recurrence logic using Butler automation or a Power-Up post-migration. We document each recurring task's original rule in the migration inventory so the customer can recreate it in Trello.

Team categories and per-project role assignments stored in WP Project Manager's plugin-specific options tables map to Trello Board membership roles. WP Project Manager's project administrator, project member, and client viewer roles reduce to Trello's Board admin and Board normal member. We extract the role mapping per project and apply it during Board creation. Client-viewer access (read-only on specific projects) has no direct Trello equivalent without a separate Workspace; we flag these cases in the inventory and recommend the customer use Trello's guest feature (available on Standard and above) for client-facing boards.