Migrate from Planview AgilePlace to Trello

AgilePlace Boards contain Lanes and Swimlanes that create a hierarchical workflow view. Trello has a flat List structure within each Board with no native Swimlane concept. We flatten the board-to-lane hierarchy into one of two strategies during scoping: map each AgilePlace Board to a Trello Board with Lists representing each Lane, or consolidate multiple AgilePlace boards into a single Trello Board with Lists representing both the board name and lane. The customer's team structure and expected board count in Trello determine which strategy applies. Board background colors and lane color coding map to Trello List headers or board cover colors as close equivalents.

AgilePlace Cards migrate to Trello Cards preserving title, description (rich text), due dates, created and modified timestamps, and board position. Card body content is preserved as-is. Card priority indicators (low, medium, high, critical) map to Trello label colors if labels are configured for priority. WIP status migrates as card metadata but Trello does not enforce WIP limits natively, so lane-level WIP status is preserved as a custom field or note for team reference.

Custom Fields in AgilePlace are defined per-board and may carry role-gated edit permissions. Trello defines custom fields at the workspace level (Business Class and above). During migration, we export both the field definitions and all card-level values, then recreate the field definitions in Trello at the workspace level. This changes their scope from per-board to org-wide, which may require the customer to consolidate or rename fields if names冲突 occurs across boards. Role-gating on custom fields does not replicate in Trello.

AgilePlace Card Types are board-level taxonomy that classify work items (for example, Bug, Feature, Task, Spike). Trello uses Labels for card classification, which are flat string tags without hierarchical taxonomy. We map each AgilePlace Card Type to a Trello Label with a matching name and color. If the destination Trello workspace already uses Labels for another purpose, we coordinate with the customer to avoid conflicts during scoping. Card Type inheritance and sub-types collapse into a single label level in Trello.

Parent-child card links in AgilePlace are stored as a separate API relationship and can reference cards across different boards. We export these as a dependency table keyed by AgilePlace card ID and map them during the destination import. Within-board dependencies can be recreated using Trello Power-Ups such as the Dependencies Manager. Cross-board dependencies cannot be natively represented in Trello; we flag these in a reconciliation report and recommend the customer either consolidate dependent cards onto one board or use a Power-Up with cross-board support. This is a known limitation of the destination platform.

Card comments migrate as Trello Card comments with author attribution preserved via email-to-user matching. Comment timestamps and threading structure are preserved as the comment order within the card. If the comment author has no matching Trello account, the comment is attributed to the migrating user with a note indicating the original author email.

AgilePlace Tasks are child objects within a Card, each with its own completion status and assignee. We import these as Trello Checklists on the destination Card, preserving each task's completion checkbox state and the assignee's email. If a task has no assignee in AgilePlace, it migrates as an unchecked checklist item. The parent card-to-task relationship is preserved at the Trello Card level by attaching the full checklist during card import.

AgilePlace Tags are flat string labels on cards. We map these to Trello Labels, which serve the same organizational function. Tag color coding in AgilePlace maps to Label color where applicable. If Trello Labels are already in use for Card Types, we coordinate with the customer during scoping to determine whether Tags and Card Types share a Label namespace or whether Tags should be stored as a custom field instead.

Card assignee mapping is performed by email address. We match each AgilePlace assignee email against Trello workspace members. Any assignee without a matching Trello account is placed in a reconciliation queue for the customer to provision before the record import resumes. Archived or inactive AgilePlace users are flagged separately and can be mapped to inactive Trello members or to a placeholder user.

WIP limits in AgilePlace are defined per Lane on a board. Trello does not have a native WIP limit feature. We preserve WIP limit values as a card custom field in Trello or as a card description note so teams can reference the original limit values. If the customer uses a WIP limit Power-Up in Trello, we document the values for manual configuration post-migration. This is a manual step outside the automated migration scope.

File attachments on AgilePlace cards are downloaded and re-uploaded to the destination Trello Card. We handle this in a separate pass after card content is loaded. Large attachment volumes increase migration duration and require storage capacity planning. Atlassian's Trello storage limits apply; we flag any attachments that exceed Trello's per-file size limits during discovery.

AgilePlace card timestamps (created, updated, moved-to-lane) are preserved as Trello Card custom fields or as Card description metadata, depending on the destination Trello plan. These timestamps are critical for teams using cycle-time calculations and historical reporting. We do not overwrite Trello's native card creation date during import; the source timestamps are stored as supplemental fields to maintain historical accuracy for analytics.

Integration references in AgilePlace (Jira issue links, GitHub commit references, external URLs) are stored as card metadata. These linked external records do not migrate. We log the original reference URLs as a note in the Trello Card description so teams can manually re-establish the external link if needed. This is a known limitation: the integration connection itself does not transfer and requires reconfiguration in the destination tool.