Migrate from Planview AgilePlace to Jira

Each AgilePlace Board maps to a Jira Project. The AgilePlace board name becomes the Jira Project name and key. We set the project type to company-managed (for WIP column limits) or team-managed (for simplified setup) during scoping based on the customer's governance model. Lane structure is preserved separately for column mapping rather than becoming project names, because AgilePlace boards are the top-level container and Jira Projects do not have lane semantics.

AgilePlace Lanes map to Jira Status columns on the board. If the board uses a flat lane structure (e.g., Backlog, In Progress, Done), we map each lane to the corresponding Jira status category (To Do, In Progress, Done). If the board uses Swimlanes (e.g., rows for team, columns for stage), we map the row orientation to a custom field (Team or Squad) and the column orientation to Jira Status, reconstructing the swimlane matrix in Jira as a filtered board view rather than native swimlane support. The customer selects the mapping during discovery. WIP limits on lanes are flagged as Jira column WIP constraints (company-managed projects) or stored in a custom field (team-managed projects).

AgilePlace Cards map to Jira Issues. Card title becomes Issue Summary. Card description (rich text) migrates to Issue Description. Priority maps from AgilePlace Priority (Critical, High, Medium, Low) to Jira Priority (Highest, High, Medium, Low, Lowest). Card type (e.g., Feature, Bug, Spike) maps to Jira Issue Type (Story, Bug, Task) via the mapping table defined during scoping. Created and moved timestamps are preserved as Issue Created and a custom field card_moved_date__c for cycle-time calculations. Card due date maps to Jira Due Date.

AgilePlace Card Types are board-level taxonomy definitions. We create a mapping table during discovery that assigns each AgilePlace Card Type to a Jira Issue Type (Epic, Story, Task, Bug, Sub-task) or to Labels if the board uses a flat type model. If Jira Issue Types are insufficient, we create custom Issue Types during schema configuration. The mapping is applied during issue creation so that every imported card receives the correct type assignment from the first import pass.

AgilePlace Custom Fields are board-level definitions that map to Jira Custom Fields at the project level. We export the custom field definition (name, type, allowed values for picklists) during discovery and pre-create the corresponding Jira custom field before any issues are loaded. AgilePlace role-gated custom fields (where a user without project-level write access cannot edit) require Jira field-level security configuration post-import; we apply the same permission model in Jira so that write restrictions carry over. Standard AgilePlace fields (Card ID, Created By, Assigned To) have direct Jira equivalents.

Parent-child card links in AgilePlace are stored as a separate API relationship. We export all card dependencies as a dependency table during the first extraction pass and recreate them in Jira after all issues are loaded. We use Jira Issue Links (type: blocks or blocked by) to represent the relationship, matching by the temporary Jira issue key assigned during import. If the AgilePlace dependency graph has multi-level parent-child chains, we flatten them to single-level Jira issue links and note the chain depth in a custom field dependency_depth__c.

Card comments migrate as Jira Issue Comments. Author attribution is preserved via email-to-Jira-user matching. If no matching Jira user exists for the comment author, we set the comment author to the migration service account and note the original author in the comment body. Comment body content (rich text) migrates as-is with HTML preserved. Comment timestamps are preserved as Jira comment creation timestamps.

AgilePlace Tasks (child items within a Card) map to Jira Sub-task issues linked to the parent Issue. Task title becomes Sub-task Summary. Task completion status (Complete/Incomplete) maps to Jira Sub-task Status (Done/To Do). Assignee maps via email matching. If Jira sub-tasks are not enabled on the destination project, we promote sub-tasks to Tasks and add a custom field parent_card_id__c to preserve the hierarchy reference.

AgilePlace Tags (flat string labels on cards) map to Jira Labels. We migrate the full tag string and create matching Jira Labels during import. If the customer uses more than 200 distinct tags, we recommend a custom Label prefix strategy or a multi-select custom field to avoid Jira label namespace pollution. Jira Labels are case-insensitive and lowercase; we normalize AgilePlace tag casing during import.

Card assignees are resolved by email match to Jira User accounts. Inactive or archived AgilePlace users without a Jira match are flagged in the reconciliation report. The customer admin provisions any missing Jira users before the assignee pass runs. Unmatched assignees are stored in a custom field original_assignee__c for manual assignment post-migration.

File attachments on AgilePlace cards are downloaded during extraction and re-uploaded to Jira Issues as attachments during import. Attachment file names and content are preserved. Large attachment volumes (over 500 files) increase migration duration significantly and require storage capacity planning; we flag this during scoping and advise on Jira attachment storage limits per plan tier.