Migrate from Planview AdaptiveWork to Jira

Planview Projects map directly to Jira Projects. Each Planview Project becomes a Jira Project with the same name, description, and start/end dates preserved in custom fields. If the customer has multiple business-unit Projects, we create separate Jira Projects rather than a single portfolio Project, since Jira portfolios are a separate licensing layer (Jira Software Premium or Enterprise). The Planview project identifier is preserved in a custom field aw_project_id__c for cross-reference.

Planview Tasks map to Jira Issue records. Task name becomes Issue Summary; description migrates to Issue Description as rich text; status maps from Planview status to a Jira Status in the target project's workflow. Tasks that are direct children of the Project map as Jira Stories or Tasks based on the Planview Task Type field. We resolve the parent-child hierarchy using Jira Subtasks where the original nesting was two levels deep (Task with Subtask). Grandchild Tasks (three levels) require flattening since Jira does not support deeper nesting without Subtasks enabled per project type.

Planview Subtasks map to Jira Subtask issues. Jira Subtask must be enabled in the target project's issue type scheme before import. We link each Subtask to its parent Issue using the Jira Parent Link field (parent key). If the Planview entity relationship has Subtasks nested under Subtasks, we flatten the lowest level to a flat Subtask of the top-level parent Issue.

Planview Milestones do not have a native Jira equivalent. We map Milestones to Jira Fix Versions (releases) within each Project. The Milestone name becomes the Fix Version name, and the Milestone due date becomes the Fix Version release date. We preserve the original Planview Milestone ID in a custom field aw_milestone_id__c. If multiple Planview Milestones share the same target date within a Project, they merge into a single Fix Version with a comma-separated aw_milestone_ids__c custom field carrying all source IDs.

Planview Users map to Jira Users by email match. We extract every User referenced in Task assignments and resource allocations, then reconcile against the Jira destination site. Any Planview User without a matching Jira account goes to a reconciliation queue for the customer's admin to provision before the assignment phase begins. Inactive Jira users can be assigned if the project permissions allow it.

Planview predecessor/successor task dependencies map to Jira Issue Links. A Planview predecessor-successor relationship becomes a Blocks/Is Blocked By link in Jira. We resolve the Jira Issue key for both ends of the link during the transformation phase before inserting the links. Circular dependency chains (A blocks B, B blocks A) are flagged and broken by removing the secondary link during migration, with the cycle reported in the migration summary.

Planview Time Entries map to Jira Issue Worklog records. We migrate hours logged, the date worked, and the billing flag (if applicable) against the parent Task. Jira Worklog is native; no custom field is required. However, Jira Worklog does not store billing amounts—financial data from Planview Time Entries (hourly rate, cost, billing amount) is preserved in a separate structured CSV exported alongside the migration for manual entry into Jira-compatible billing apps (Tempo Timesheets, etc.).

Planview picklist custom fields map to Jira custom fields of type Select List (single) or Multi-select List (radio button for Jira's equivalent). We preserve the picklist option values as Jira field options. Note that Planview picklist fields render on card views while free-text fields do not—a rendering difference that does not affect data migration but is documented for post-migration admin review.

Planview free-text custom fields map to Jira Text Field (single line) or Text Area (multi-line) depending on the expected content length. We do not attempt to map free-text data to structured Jira fields; the raw value transfers as-is. Jira does not enforce picklist restrictions on text fields, so validation rules that existed in Planview do not carry forward.

Planview Project-level financial data (budget amounts, actual costs, revenue) has no native Jira equivalent. We migrate these values to Jira Project-level custom fields (Number type) and also produce a structured CSV export of all financial line items keyed by the Planview Project ID and Jira Project key for manual reconciliation or a supplemental Confluence table. Currency handling is preserved as the original currency code in a custom field; Jira does not perform currency conversion.

Planview resource capacity planning uses user working calendars, skills, and availability calculations that are platform-specific algorithms. The underlying allocation data (which User is assigned to which Task with what percentage) migrates as Jira Issue Assignee plus a custom field aw_allocation_pct__c. The capacity heatmap, workload distribution, and calendar-based availability calculations do not migrate; we deliver a capacity planning CSV with User, Project, Task, and allocation percentage for the customer to re-enter in a Jira-compatible capacity tool (Tempo, Capacity, Structure).

Planview's Customer module links Projects to external client organizations. Jira does not have a native customer or account entity. We map Customer records to Jira Project Labels (prefixed with customer_) and produce a Customer-to-Jira-Project mapping CSV. If the customer also has a CRM (Salesforce, HubSpot), we recommend linking the Jira Project to the CRM Account via a custom field rather than duplicating the customer record in Jira.