Migrate from ProjectManager to Jira

ProjectManager Projects map directly to Jira Projects. We create the Jira project with the appropriate project type (Team-managed or Company-managed) during schema setup. The ProjectManager project name becomes the Jira project key prefix (up to 5 characters) and project name. Standard fields including start date, end date, status, and description transfer as project-level metadata.

ProjectManager Tasks map to Jira Issues with type decisions made at migration time based on task attributes. Top-level WBS tasks (no parent) become Jira Epics if they have children, Stories if they are deliverables, or Tasks if they are action items. Child tasks become Stories or Subtasks under the parent Epic or Story. We reconstruct the parent-child WBS using Jira issue links (Relates to, Blocks, is Blocked by) or Epic-Story hierarchy where the Epic link field is populated. Dependency chains from ProjectManager (Finish-to-Start, Start-to-Start, Finish-to-Finish, Start-to-Finish) migrate to Jira Issue Links with optional lag day preservation.

ProjectManager TaskAssignees link Resources to Tasks and drive the workload view. We map assignee records to Jira issue Assignee fields by resolving the Resource email against Jira User accounts. ResourceTeam membership from ProjectManager maps to Jira Project Role membership after we create the corresponding project roles during schema setup.

ProjectManager Resources represent team members and equipment. We map Resources to Jira User accounts by email lookup. Availability windows and cost rates from ProjectManager Resources do not have a direct Jira equivalent; availability windows are not migratable to Jira's sprint planning model, and cost rates are preserved in a custom field pm_resource_cost__c on the Jira User record if the customer requires cost tracking post-migration.

ProjectManager ResourceTeams group Resources for scheduling and reporting. Jira has no direct scheduling-team object, so we create Jira Project Roles with the ResourceTeam name and populate membership by mapping ResourceTeam members to the role. Jira's project role model allows the same user to hold multiple roles across projects, which is the closest equivalent. Note that ProjectManager Teams (org membership, distinct from ResourceTeams) also map to Project Roles or Jira Groups based on the customer's preference during scoping.

ProjectManager ProjectFields (custom properties scoped to Workspace) map to Jira custom fields scoped to the destination Project. Field types (string, number, date, choice) map to equivalent Jira field types. Jira requires custom fields to be created via POST to the issue metadata API before values can be written, matching ProjectManager's two-step pattern. We discover existing ProjectField definitions via ProjectManager's GET /api/data/projects/fields, create the equivalent Jira custom fields via Jira's REST API, then write values in a separate pass.

ProjectManager TaskFields work identically to ProjectFields but are scoped to Tasks. We handle both field definitions and per-record values using the same two-step API process: discover via GET /api/data/projects/{projectId}/fields, create via Jira POST /rest/api/3/field, then write values via PUT /rest/api/3/issue/{issueId}. Not all TaskField types have native Jira equivalents; choice fields map to Jira Select (single) or Multi-Select; date fields map to Jira Date Picker; string and number fields map directly.

ProjectManager Risks are standalone objects linked to Projects with severity, status, and linked ProjectId. Jira does not have a native Risk object, so Risks map to Jira Issues of type Task or a custom Issue Type named Risk (if the customer creates it). We preserve severity and status in custom fields (pm_risk_severity__c, pm_risk_status__c) and attach any RiskFiles as Jira issue attachments.

ProjectManager Timesheets record hours logged by Resources against Tasks. Jira's native worklog stores time only without billing rate. Timesheet records may embed platform-specific billing rates that do not map directly to ProjectManager's Resource cost model. We flag Timesheet data during discovery and migrate hours as Jira Worklog entries with the original timestamp preserved. Billing rate reconciliation is a separate decision point: the customer can migrate hours only and set rates manually in the destination tool, or attempt to reconcile rates in a custom field on the Jira User record.

ProjectManager Tags and TaskTags are lightweight labeling objects. We preserve tag names and associations as Jira Labels on the mapped Issues. Labels in Jira are plain text strings without separate schema definitions, making the mapping straightforward.

ProjectManager UserRoles define Workspace-level permissions. Role definitions are proprietary to ProjectManager. We map source permission profiles to the closest matching Jira built-in roles (Administrators, Developers, Users) or to a custom Project Role we create during schema setup. Custom role definitions in ProjectManager that have no Jira equivalent are flagged in the scope document with a recommendation for Jira permission scheme configuration.