Migrate from Planview AgilePlace to monday Work Management

AgilePlace Boards map directly to monday.com Boards. Each board's name, description, and type are preserved. We create monday.com Boards during the first import pass and use the board ID as the parent anchor for all subsequent Card imports. If the source AgilePlace instance uses board-level templates, we create equivalent monday.com Board templates during the same pass.

AgilePlace Lanes map to monday.com Groups. Each Lane's name, WIP limit, and color are preserved. If the source board uses nested Swimlanes within Lanes, we flatten the hierarchy by concatenating Lane name and Swimlane name into a single Group title (for example, 'Sprint 1 :: QA' becomes a monday.com Group named 'Sprint 1 :: QA'). Swimlane position within Lane is preserved as Group ordering.

AgilePlace Swimlanes are subordinate to Lanes and do not have a native monday.com equivalent. We handle Swimlanes as a naming-prefix appended to the Group title as described above, or we create a separate monday.com Group for each Swimlane if the customer confirms that flat Group names are acceptable. Position and color from the Swimlane definition migrate as Group metadata. The customer chooses the flattening strategy during scoping.

AgilePlace Cards map to monday.com Items. We migrate Card title, description (rich text), type, priority, WIP status, due date, created and modified timestamps, and board position. The Card body content (markdown or HTML) is preserved as-is in monday.com's Item description field. Card priority and WIP status are mapped to monday.com Status column values that we configure during schema setup. Board position is preserved by inserting Items into the correct Group (Lane) in the target ordering index.

AgilePlace Card Types are board-level taxonomy. monday.com does not support board-level type definitions natively, so we map each distinct Card Type to a monday.com Label with a matching color. An Item can carry multiple Labels, so if a customer uses more than one Card Type per Card, all types are preserved as Label assignments. If the destination has fewer than 50 unique Card Types, Labels provide a workable substitute. For very large type sets, we recommend the customer consolidate during scoping.

AgilePlace board-level Custom Fields map to monday.com Columns using type mapping: text fields become Text columns, dates become Date columns, users become Person columns, numeric values become Numbers columns, and multi-select fields become Tags or Status columns. Role-gated custom fields require the import user to have board-level write access in monday.com, equivalent to the project-level write permission required in AgilePlace. We flag any fields where the original AgilePlace role restriction may conflict with the customer's intended monday.com sharing model and ask for confirmation during discovery.

Parent-child card links in AgilePlace are stored as a separate API relationship distinct from the Card record itself. We export these as a dependency table during the Card pass and recreate them in monday.com after all Items are loaded using the Dependencies column (available on Pro and Enterprise). We match Cards by a temporary ID map we construct during migration, resolve the destination Item IDs, then write the Dependency relationship. Cards with broken parent references (deleted source cards) are flagged as orphans for customer review.

Card Comments in AgilePlace migrate to monday.com Updates on the corresponding Item. Author attribution is preserved via email-to-user matching against the monday.com workspace members. Timestamps are preserved so the discussion thread order matches the original. Rich text in comments transfers as-is, and @mentions in AgilePlace comments are logged as text references (not recreated as monday.com @mentions since the mention target users may differ).

AgilePlace Tasks (child items within a Card) map to monday.com Subitems. We preserve the task title, completion status, due date, and assignee. Subitems inherit the parent's Group assignment in monday.com. If a Card has more than 50 Subitems, we chunk them across multiple Subitem creation API calls with exponential backoff on rate limit responses.

Tags in AgilePlace are flat string labels on Cards. We map these to monday.com Tags on the Item. If the destination workspace has no pre-existing tags with matching names, we create them during migration. Tags are preserved as comma-separated entries per Item. If monday.com's tag limit is reached for an account, we store remaining tags as a comma-separated text in a dedicated column.

WIP limits in AgilePlace are defined per Lane and enforced visually on the board. monday.com has no native WIP limit enforcement column. We map WIP limits to a Numbers column in the destination Group, or we configure a monday.com Automation (available from Standard tier) that triggers a notification when the group item count exceeds the imported WIP threshold. The customer chooses the WIP representation during scoping. Notification automations are documented in the rebuild inventory rather than migrated as code.

File attachments on AgilePlace Cards are downloaded from the source and uploaded to monday.com's file storage during migration. We re-attach files to the corresponding Item using the monday.com Files column. Large attachment volumes (over 1 GB per board) increase migration duration significantly and require the customer to confirm that monday.com storage limits on their plan are sufficient. We flag boards with attachment volumes exceeding 500 MB for pre-migration storage capacity review.

Card assignees and comment authors are mapped by email address. Inactive or archived users in AgilePlace who are no longer in the workspace require fallback handling by username matching or explicit orphan-flagging for customer review. We build a user reconciliation table during discovery that shows which AgilePlace users have matching monday.com workspace accounts and which do not. The customer provisions any missing monday.com accounts before the production migration phase begins.

Card created, updated, moved, and last-activity timestamps are preserved as Date columns or metadata on the monday.com Item. This is critical for teams relying on cycle-time calculations and cumulative flow diagrams in reporting tools. We write timestamps as read-only Date columns so they do not change if someone updates the Item after migration. monday.com's native Last Updated field is also preserved alongside our imported created_date and moved_date values.