Migrate from Planisware Orchestra to Jira

Planisware Orchestra Projects map directly to Jira Software Projects. Each Orchestra Project becomes a top-level Jira Project with the same name and description. If the customer uses Jira Software Premium, we create the project using the company-managed or team-managed template matching the Orchestra delivery methodology (Agile or stage-gate). Project-level metadata (start date, target end date, status) migrates to custom fields since Jira native project fields are limited.

Orchestra Activities map to Jira issue types based on a configurable hierarchy rule. Typically, high-level milestones map to Epic, deliverables map to Story, individual work packages map to Task, and defects map to Bug. The activity hierarchy (parent-child dependencies) maps to Jira's parent-link and Fix Version relationships. We preserve the original activity ID in a custom field pwo_original_id__c for traceability. Start/end dates map to Jira's custom Due Date and custom Start Date fields; Jira does not have native schedule tracking at the issue level without a third-party add-on.

Orchestra Resources map to Jira User accounts by email match. Resource capacity (FTE, availability percentages) and cost rates migrate as custom fields on the User record in Jira Software Premium (resource management module) or as custom fields for simpler reporting. If the destination Jira instance has fewer users than Orchestra resources, unmapped resources are held in a reconciliation report for the admin to provision or reassign before final import.

Orchestra Programs aggregate quantitative data (cost, time, resources) from contributing projects. Jira has no native Program object. We handle this in one of two ways depending on the destination tier: (1) For Jira Software Premium, we create a Portfolio hierarchy of Jira Projects representing the Program structure, enabling roll-up view but not native financial aggregation. (2) For Jira Standard, we document the Program-to-Project mapping as a written reference table and advise the admin to use Labels or Components for manual grouping. Financial program roll-up data does not migrate.

Orchestra budget, forecast, and actual cost values migrate to Jira custom number fields at the Project level (for aggregate budget data) and at the Issue level (for activity-level actuals). We map budget, forecast, and actuals to separate custom fields (e.g., pwo_budget__c, pwo_forecast__c, pwo_actual__c). Variance is calculated post-migration in a Jira仪表板 using Jira's built-in number formula capabilities or exported to a reporting tool. Jira has no native cost accounting or financial governance model; this is a known capability gap the customer accepts by choosing Jira.

Orchestra Risk records map to Jira issues using a Risk issue type we create in the destination project. Risk probability, impact, and mitigation fields migrate to custom select and text fields on the Jira Risk issue. Cross-project risk relationships map to Jira labels or linked issues. Risk registers at the portfolio level are flattened to the project level since Jira has no native portfolio risk object.

Orchestra Deliverables tied to phase-gate milestones map to Jira issues marked with a Deliverable label and linked to their parent Activity. Approval status from Orchestra becomes a custom select field (Approved, Pending, Rejected). Checklist items within deliverables migrate as Jira subtasks or as a checklist custom field if the Jira instance has the native checklist app enabled.

Orchestra timesheet entries and actual hours logged against activities map to Jira Worklog records on the corresponding issues. Each timesheet line becomes a Worklog entry with the date, hours, and the resource mapped to a Jira User. The Jira assignee must exist in Jira for Worklog to attach; we resolve this via the User mapping step before timesheet migration begins. Orchestra timesheet approval chain and workflow validation history do not migrate (stored as system-state records); we deliver a written description of the current approval workflow for manual reconstruction in Jira.

Orchestra documents uploaded to the document module are accessible only through the Orchestra interface and have no standalone access URL. We extract document metadata (filename, upload date, associated project/activity) via the API and re-associate files to Jira issues as attachments where feasible, or document the link reference for manual re-upload to Jira. Document access-control settings do not transfer and must be reapplied manually in Jira's permission scheme per project.

Orchestra custom object schemas vary per deployment and require pre-migration schema profiling. We map known custom object types to Jira custom fields (text, number, select, date, user) based on the Orchestra field type. If Orchestra custom objects have lookup relationships to other Orchestra objects, we flatten these to Jira custom fields with the referenced record's name stored as text. Complex calculated-value fields from Orchestra (business-rule driven) cannot reproduce the calculation logic in Jira without manual rebuild; we document the field definition and formula source for the admin's reference.