Migrate from OpenText Project and Portfolio Management (PPM) to Jira

OpenText PPM Projects map directly to Jira Software Projects. We preserve the project name, description, start and end dates, project manager assignment, and project status. Custom properties on the OpenText PPM Project record migrate as Jira custom fields scoped to the destination project. The Jira project must be provisioned before task-level migration begins so that all issues reference the correct project key.

OpenText PPM Programs represent top-level containers grouping related projects. We map Programs to Jira Epics within a Jira Project when the program's member projects will share a single Jira project. If the programs represent distinct organizational units with separate governance, we recommend creating separate Jira Projects with a naming convention that preserves program grouping. The choice is made during scoping based on the customer's Jira project structure.

OpenText PPM Demands represent incoming work requests or ideas that feed project intake. We map active Demands to Jira Epics or high-priority Issues depending on the size and approval lifecycle of the Demand. Demand status, priority, requestor, and submission date migrate to Jira fields. Workflow state transitions from OpenText PPM's demand-management process are not migrated as Jira workflows; they are documented as a separate rebuild item.

OpenText PPM Tasks map to Jira Issues with the appropriate issue type determined by the task's category field. Subtasks map to Jira Subtasks with the parent Issue reference resolved at migration time. Task hierarchies (summary tasks and child tasks) translate to Jira's parent-subtask relationship structure.

OpenText PPM project-level and task-level dependencies (finish-to-start, start-to-start, finish-to-finish, start-to-finish) map to Jira Issue Links using the Jira API. We preserve the dependency type as the link type (blocks, is blocked by, relates to, or clone) and set the lag where the destination Jira project supports lag on the link. Circular dependency detection is performed during the dependency mapping phase and flagged for the customer's review before import.

OpenText PPM Resources (staff members, equipment, or capacity units) map to Jira Users by email address. Skill profiles and role assignments from OpenText PPM migrate as Jira user properties or as project roles. Availability calendars and capacity allocations do not have a native Jira equivalent; we document the original allocation percentages as Jira custom fields on the user's profile so the customer's admin can reference them when configuring sprint capacity.

OpenText PPM Financial Lines (cost lines and benefit lines at portfolio, program, and project levels) have no direct Jira equivalent. Jira Software does not include portfolio financial management. We map Financial Lines to Jira custom number fields on the corresponding Project or Epic record, preserving the cost or benefit amount, line type, and fiscal period where these attributes exist. For customers requiring full financial tracking, we recommend Jira with a financial management app as a separate implementation scope.

OpenText PPM Portfolios aggregate Programs and Projects for executive-level governance and rollup reporting. Jira's native hierarchy supports Project > Epic > Story > Subtask, which covers two levels of the OpenText PPM hierarchy. For organizations requiring a third aggregation level, we recommend Portfolio for Jira (Atlassian's native portfolio tool) or a third-party app. Portfolio membership and rollup data migrate as Jira Project properties or linked Epic records.

OpenText PPM custom properties on any object migrate to Jira Custom Fields. We perform a pre-migration schema discovery pass enumerating all active custom properties, their data types, and the objects they are attached to. Each property maps to the equivalent Jira field type (text, number, date, select, multiselect, user picker). Custom fields are created in Jira before data migration begins, scoped to the relevant projects.

Documents and attachments on OpenText PPM Projects or Tasks migrate as Jira Attachments. Binary files are transferred in a parallel stream from OpenText PPM's file management layer, re-uploaded to Jira using the REST API, and associated with the correct issue by issue key. We preserve the original filename, content type, upload date, and uploader where these attributes are available in the source export.

OpenText PPM Time Entries logged against Projects or Tasks migrate to Jira Issue Worklogs. We map the hours logged, the date, the resource (mapped to Jira User), and any time entry notes. Approval status on OpenText PPM timesheets is not preserved as Jira does not have a native timesheet approval model; we flag this as a workflow gap in the handoff documentation.

OpenText PPM stage-gate lifecycle definitions govern workflow transitions across Programs and Projects. Jira Workflows are structurally different and cannot be migrated as code. We audit every active OpenText PPM workflow definition, document the stage transitions, approval gates, and conditional routing, and deliver a written Workflow Scheme design for the customer's Jira admin to rebuild using Jira's Workflow Designer. The documentation includes the equivalent Jira statuses, transitions, validators, and post-functions for each stage-gate.