Migrate from Planview PPM Pro to Jira

Planview Portfolios are top-level containers that hold Programs and Projects with strategic alignment scores and portfolio-level financials. Jira has no native Portfolio object. We collapse Portfolios into a Jira Project naming convention (e.g., [PORTFOLIO NAME] / [Project Name]) and use Jira's Project hierarchy feature where available on Premium/Enterprise to create a parent-child project structure. If Jira Premium/Enterprise project hierarchy is not available, we document the portfolio-to-project mapping in a separate reference table so the customer's admin can implement it using Structure for Jira or BigGantt add-ons post-migration.

Planview Programs group related Projects under a Portfolio with program-level budgets, status, and owner assignments. We map Programs to Jira Epics in a designated Programs project, or to Jira Projects using a naming prefix (e.g., [PROGRAM] - Project Name) depending on whether the customer wants Epic-level or Project-level grouping. Program-level budgets do not map natively to Jira; we flag them for migration to custom fields or a Tempo Budgets configuration.

Planview Projects map directly to Jira Projects. We preserve Project status, start/end dates, priority, owner, and description. Custom User-Defined Fields on Projects migrate to Jira custom fields of the matching type (text, number, date, single-select, multi-select). Jira Project key prefixes and issue type schemes are configured before migration to match the Planview project's WBS structure.

Planview Tasks map to Jira Issues (Story, Task, or Bug by configured mapping rule). We preserve WBS hierarchy by mapping the Planview task parent-child relationship to Jira's Epic > Story > Sub-task structure. Start/end dates migrate to Jira's Due Date and a custom Start Date field. Percent complete from Planview maps to Jira's Status percentage if using Jira Software Premium or to a custom progress field on Standard. Gantt dependency links are reconstructed using Jira Issue links (Blocks, Is Blocked By, Depends On).

Planview Resources (people or roles with capacity, skills, and utilization data) map to Jira Project Members via email match. Capacity and utilization data does not have a native Jira equivalent; we map it to a Tempo Timesheets-compatible custom field structure if the customer licenses Tempo, or we export it as a reference dataset in CSV alongside the migration for the customer to configure manually. Role assignments map to Jira Project Roles (Administrators, Members, Viewers).

Planview Time Entries (hours logged against Projects and Tasks with dates, hours, and cost codes) map to Jira Worklog entries via the Jira REST API. We map the Worklog author to the Jira user by email, the Worklog started date to the Jira worklog startedAt timestamp, and the hours to timeSpentSeconds. Jira does not support billable vs. non-billable flags natively; we map this to a custom billable/non-billable field on the worklog record. If the customer does not license Tempo Timesheets, Jira's native worklog is the migration target.

Planview Demand Requests capture project intake before formal approval with requester, estimated effort, priority, and status. Jira has no demand management object, so we create a dedicated intake Jira Project and map Demand Requests to Issues of type Story or Task. Priority and estimated effort map to Jira Priority and Story Points (or custom effort fields). Status from Planview maps to a custom demand status field if the customer wants to track approval workflow separately from the standard issue workflow.

Planview budget records include planned cost, actual cost, labor cost, and expense line items per Project. Jira has no native financial module. We map budget data to Jira custom number fields (Planned Cost, Actual Cost, Labor Cost) on the Project. For multi-level expense line items, we create a custom Expense Lines field (JSON blob) or recommend Tempo Budgets for a native UI. Currency mismatches between Planview and Jira are flagged during scoping. We do not migrate budget as a first-class object because Jira does not support it without an add-on.

Planview User-Defined Fields of type Text, Number, Date, and Dropdown on Projects and Tasks map to Jira custom fields of equivalent type. Text fields map to Jira Text Field (single line) or Text Area (multi-line) depending on expected length. Number fields map to Jira Number Field. Date fields map to Jira Date Picker. Dropdown fields map to Jira Single Select or Multi-Select depending on Planview configuration. We handle attribute-level datatype translation and flag any User-Defined Fields that reference inactive users or deprecated custom field IDs that will break on import.

Planview User records (name, email, role, active/inactive status) map to Jira Users by email. We export the full user roster including inactive users as Jira inactive users (if migrating to Jira Cloud) or as disabled accounts (if migrating to Jira Data Center). Active/inactive status determines whether the Jira account is enabled post-migration. Role-to-permission translation is out of scope; we document the Planview role list for the customer's admin to configure Jira project roles and global permissions.