Migrate from Planisware Enterprise to Jira

Planisware Projects map to Jira Projects at the top level. For Planisware projects that represent a large initiative, we map to Jira Epic issues within the destination Project and document the parent-child relationship separately. The Planisware project start date, end date, status, and owner migrate to the Jira Project description, key prefix, and admin settings. Projects with no Jira equivalent (internal Planisware administrative projects) are excluded from migration scope unless the customer identifies them during scoping.

Planisware Portfolios have no direct Jira equivalent. We map each Planisware Portfolio to a Jira Project with a naming convention that preserves the portfolio context (e.g., 'PF: [Portfolio Name]'). Portfolio-to-project membership is preserved as Jira labels on each project member. If the customer licenses Jira Premium with Advanced Roadmaps, the Portfolio migrates as an Advanced Roadmaps Plan with the member projects linked via the plans feature. Custom financial rollup fields on the Portfolio map to Jira Project properties stored as custom fields on the representative Project.

Planisware Resource records (including allocation percentages, skill profiles, and cost rates) map to Jira User accounts. We match by email address and flag any Planisware resource without a Jira user destination for the customer's admin to provision before migration. Allocation percentages store as Jira Project role membership or custom field values (number type) on issues assigned to each user. Skill profiles from Planisware migrate to a Jira custom field (multi-select or text) if the customer's workflow requires skill-based issue assignment.

Planisware Activities and Tasks map to Jira Issues. The Planisware task hierarchy (parent-child nesting) flattens to Jira subtasks or child Epics depending on depth. Task start and due dates map to Jira Issue Due Date and custom date fields. Task status from Planisware (custom status workflows) maps to Jira Status via a customer-approved status mapping table created during scoping. Dependencies between tasks migrate as Jira Issue Links (Blocks, Is Blocked By, Depends On types).

Planisware financial objects (budgets, actuals, forecasts, cost codes) have no native Jira equivalent. We map these to Jira Project-level or Issue-level custom fields of type Number, Currency, or Text depending on the source field type. The Planisware cost code structure becomes a Jira custom field (cascading select or text) that can be used for filtering and reporting. Financial ledger entries migrate as Jira Issue comments or attachments to preserve audit trail context. Jira Premium is recommended if the customer requires currency field type support.

Planisware custom fields on any object migrate to Jira custom fields of equivalent type. Text properties map to Jira Text Field or Short Text; date properties map to Jira Date Picker; number properties map to Jira Number Field; picklist properties map to Jira Select List. We catalog all active custom fields during pre-migration discovery and apply a field-level mapping table before import. Fields with no Jira equivalent (e.g., specialized financial fields) map to Text fields with a migration note in the field description.

Planisware project-to-project and task-to-task dependencies stored in the dependency link table migrate to Jira Issue Links. We extract the full dependency graph from Planisware and recreate it in Jira using the Blocks and Is Blocked By link types, with a migration flag on any circular dependency detected. Dependency type mapping (Finish-to-Start, Start-to-Start, etc.) is preserved in the link description field since Jira Issue Links do not natively support dependency type metadata.

Planisware custom status workflows and pipeline stages vary by implementation and do not have a direct Jira equivalent. We create a Jira Status configuration that maps each Planisware status value to a corresponding Jira Status (To Do, In Progress, Done, or custom). Status probability percentages from Planisware do not migrate as Jira has no native probability field on issues; if required, we store them as a custom Number field on the Jira issue. The customer approves the status mapping table during scoping before migration begins.

Planisware User accounts and owner assignments migrate to Jira User accounts. We extract all distinct user IDs and emails referenced across Projects, Activities, and resource allocations and match against the Jira destination site's user directory. Users without Jira accounts enter a reconciliation queue for the customer's admin to provision. Owner assignments on Planisware records migrate to Jira Assignee or Lead custom fields depending on the source object context.

Planisware documents stored in the document module cannot be accessed outside the application and are not migrated as blobs. We migrate document metadata (filename, linked object reference, upload date, author) as Jira Issue comments referencing the original document location. The customer extracts the original document store separately and re-uploads to Jira after migration. This is documented in the post-migration runbook delivered at cutover.