Migrate from Planio to monday Work Management

Planio Projects map to monday.com Workspaces containing a primary Board. Each Planio project becomes one monday.com Workspace with a Board of the same name. We pre-create the Workspace before any Items migrate so that all Items inherit the correct workspace context. Project-level custom fields from Planio are created as monday.com Board columns before item import. Project membership maps to Workspace Members with their assigned Planio role noted for admin to reassign in monday.com.

Planio Issues map to monday.com Items on the target Board. We map Issue status to monday.com Status column values, Issue priority to a Priority label column or Status color coding, and assignee to the Person column. All Planio custom field types (text, integer, float, date, boolean, list) are pre-created as monday.com column types before import. The Issue subject becomes Item name; Issue description (Redmine textile format) is converted to plain text for monday.com text columns or Docs integration.

Planio sub-issues map to monday.com Subitems attached to the parent Item. We reconstruct the parent-child link by extracting the parent_issue_id from Planio's Redmine relation table and creating a corresponding Subitem on the target Item. Cross-issue relations (blocks, duplicated by, related to, follows, precedes) have no monday.com native equivalent; we export these as a relation graph document listing each pair and recommend a manual re-creation of blockers as dependency columns or as a separate relation board if the team relies on them operationally.

Planio custom field definitions are read from the Redmine schema and mapped to monday.com column types before any Items are created. Text, integer, float, date, and boolean map directly. List fields (single-select or multi-select) map to monday.com Status or Dropdown columns. User-type fields map to Person columns. Version fields (tracking software versions) map to Dropdown columns. Boolean checkboxes map to Checkbox columns. We require board-level column creation before item import to avoid silent data loss on custom field values.

Planio time entries are a separate object linked to Issues with hours, activity type, and comments. monday.com Time Tracking is a column on an Item aggregating total hours. We merge Planio time entries for the same Issue into a single monday.com Time Tracking value per Item, preserving total hours. Activity type maps to a Label or Tag column on the Item if the team needs categorization. Comments from Planio time entries are preserved in a Notes column or Doc linked to the Item for audit purposes. This represents a data model change: Planio granular time entries become aggregated time totals at the destination.

Planio wikis are project-scoped with internal links to Issues, Projects, and repository files. We export wiki pages as structured HTML and transform internal Redmine-style cross-references (wiki links like [[Issue #123]] and [[Project:Name]]) into plain text placeholders with a migration notes document listing every cross-reference that needs manual re-linking in monday.com Docs. Wiki page hierarchy (parent-child pages) maps to monday Doc folder structure. If the team relies on wiki content for process documentation, we recommend migrating to monday Docs and rebuilding links manually; if the wiki is archival, the HTML export satisfies the data preservation requirement.

Planio Documents (uploaded files stored under Projects or Issues) are exported as binary files with their original folder hierarchy preserved. We upload each file to the corresponding monday.com Board or Item and link it to the correct Item using the File column. Large attachment sets (over 500 files per project) require chunked upload with retry logic due to monday.com file API rate limits. The original file names and Planio document descriptions are preserved as Item metadata.

Planio's Agile Kanban boards are a Pro-tier derived view built from Issue status and assignee, not a separate data object. We reconstruct the board state by mapping Planio Issue status values to monday.com Status column groups on the target Board, preserving the swim-lane layout concept as groups in monday. Sprint planning data (if tracked as Issue custom fields or version fields) maps to Timeline columns or Dropdown labels.

Planio's granular custom roles per project (Member, Reporter, Non-member, Anonymous, and custom role definitions) map to monday.com Workspace Member roles (Member, Admin, Viewer, Guest). We export the full role definition matrix and membership assignments from Planio, then deliver a written permission mapping document showing each Planio role and its recommended monday.com equivalent. Full parity is not possible since monday.com does not support custom role definitions at the Planio level; we flag the gaps for the customer's admin to configure post-migration.

Planio Users (login, email, name, admin flag, preferences) map to monday.com Team Members. We resolve by email match. Locked or suspended Planio users are noted in the migration inventory; the customer decides whether to invite them as inactive monday.com members or exclude them. Planio group memberships are preserved as a Group mapping document for the admin to recreate in monday.com Groups. Active user count in Planio determines the minimum monday.com seat count at the destination.

Planio Help Desk Customers are a distinct role who submit tickets via email without consuming a paid user seat. monday.com Work Management has no native Help Desk module; the standard product does not include a customer-facing ticket portal. We map Help Desk Customers to monday.com Contact records (if monday CRM is also licensed) or to a manual Guest invite list. Active Help Desk ticket history is exported as structured data and delivered as a CSV inventory for the customer to re-enter in a third-party help desk tool or monday Service if that product is added to the account.

Planio Git and SVN repositories with Issue commit linking have no direct monday.com Work Management equivalent. We export repository metadata (repo name, URL, commit history summary) and the commit-to-Issue linkage table as a structured document. The recommendation is to migrate the bare git repository to a dedicated Git hosting platform (GitHub, GitLab, Bitbucket) and use a third-party integration or Integromat/Make scenario to link commits to monday.com Items by matching commit message patterns. We do not migrate full git history; the bare repo transfer is a separate DevOps task.