Migrate from Planview AgilePlace to Asana

Each AgilePlace Board maps to one Asana Project. We export the board name, description, and lane structure as a first-pass import, then map each Lane to either a Section or a nested Section within the Asana project. Swimlanes, which represent a second hierarchy level in AgilePlace, require a flattening decision during scoping: either promoted to top-level Asana Projects within a Portfolio or stored as a custom field value on cards. The customer confirms the preferred approach before migration begins. Board archive status migrates as a custom field or project status note.

Cards represent work items and map directly to Asana Tasks. We migrate title, description (rich text preserved), Card Type, priority, WIP status, due date, created and modified timestamps, and card position within the lane. The Asana project membership and section placement are resolved from the Lane assignment at import time. Historical timestamps are stored as custom fields so that cycle-time reporting tools can still reference the original created date.

AgilePlace custom fields are defined at the board level with role-gated write access, meaning a user without project-level write access cannot edit certain fields even if assigned across all records. We export the field definitions alongside card values, map field types to Asana equivalents (text to Text, single-choice to Single-Select, multi-choice to Multi-Select, number to Number, date to Date), and create matching fields in the Asana project. Any Relations Summary fields showing ERROR in AgilePlace are excluded from migration and recomputed in Asana. Role-based write restrictions in AgilePlace do not have a direct Asana equivalent; we document the original restriction so the admin can configure Asana project-level field editing permissions post-migration.

Card Types are a board-level taxonomy in AgilePlace used for filtering and card styling. Asana uses Labels for a similar categorization purpose. We map each distinct Card Type to an Asana Label on the corresponding project. If the customer uses Card Types as workflow states rather than categories, we map them to Asana Sections instead. The customer confirms the intended use of Card Types during discovery to select the correct destination representation.

Parent-child card links in AgilePlace are stored as a separate API relationship, not embedded in the card record. We export these as a dependency table during the first card pass and resolve them in a second pass after all cards have received their Asana GIDs. The second pass creates dependency records in Asana using the Asana API, matching each child task to its parent task via the temporary AgilePlace card ID mapping table. Cross-board dependencies require the customer to confirm whether the parent and child boards map to the same Asana project or separate projects, which affects how the dependency is created in Asana.

Card comments migrate as Asana subtasks (if they represent action items) or as comments on the task (if they are discussion notes). Author attribution is preserved via email-to-user matching against the Asana workspace members. Rich text formatting in comments is preserved as-is. Threaded comment structures in AgilePlace become flat comments in Asana since Asana does not support nested comment threads natively.

AgilePlace Tasks are child items within a Card. These map to Asana Subtasks, preserving title, completion status (mapped to subtask completion in Asana), assignee, and due date. Subtask order within the parent card is preserved by setting the Asana subtask creation sequence.

Tags in AgilePlace are flat string labels on cards. These map directly to Asana Tags within the workspace. Asana Tags are workspace-level and can be applied to any task across any project. We preserve the tag string values and create matching tags in the destination workspace before the card import phase.

Card assignees are resolved by email address match against the Asana workspace user list. A user in AgilePlace with no matching Asana account is flagged in a reconciliation report for the customer's admin to provision before record import continues. Archived or inactive AgilePlace users are flagged with a status note in the Asana assignee field so that the admin can decide whether to reassign or leave them as orphaned assignees.

WIP limits in AgilePlace are defined per Lane and enforced visually when the lane is full. Asana has no native WIP limit enforcement. We migrate the WIP limit values as custom Number fields on each card (populated with the lane-level limit value), or as a project-level custom field if all cards in the project share the same limit. Post-migration, the admin can use Asana Rules or a third-party WIP enforcement app to alert when column limits are exceeded, but native enforcement requires a separate rebuild.

File attachments on cards are downloaded from AgilePlace and re-uploaded to Asana as task attachments. Large attachment volumes (over 500 attachments per 1,000 cards) increase migration duration and require storage capacity planning in the Asana workspace. We handle attachments after card creation so that each attachment is linked to the correct task by its Asana GID.

Integration references stored as card metadata in AgilePlace such as Jira issue IDs, GitHub commit hashes, Azure DevOps work item URLs, and external hyperlinks do not migrate as live links. We log these references as Notes on the corresponding Asana task so that the admin has a record of the external reference without the link itself functioning in Asana.