Migrate from OpenProj to Jira

OpenProject Projects (top-level containers with configurable Modules) map to Jira Projects. We preserve project name, description, identifier/key, and member list. Jira project key must be defined before migration; we use a sanitized uppercase version of the OpenProject identifier. Module visibility (which modules are active per project) has no direct Jira equivalent and is documented for manual configuration post-migration.

Work Packages map directly to Jira Issues. The OpenProject type (Task, Feature, Bug, Milestone, Phase, Epic) maps to a Jira Issue Type defined in the destination project's Issue Type Scheme. Subject becomes Summary, description HTML is preserved as the Issue description, and dates (start, due, estimated hours) map to Due Date and Time Tracking fields. Jira Priority maps from OpenProject Priority with a value mapping defined during scoping.

OpenProject global statuses (New, In Progress, Closed, etc.) map to Jira Statuses within the destination project's Status Workflow. Custom statuses defined in OpenProject Enterprise are created in Jira and added to the relevant workflow transitions. We preserve the status name; the workflow transition logic is a separate configuration step that the customer's Jira admin configures post-migration.

OpenProject's type inventory (Task, Feature, Bug, Milestone, Phase, Epic) is recreated as Jira Issue Types in the destination project. Each type gets a dedicated Issue Type Scheme entry. Custom types defined in OpenProject Enterprise are created in Jira with matching names. Type-level workflows (which statuses are valid per type) are documented for the admin to configure in Jira.

OpenProject Versions (sprints and milestones with name, description, status, and date) map to Jira Fix Versions. Version status (Open, Locked, Closed) maps to Jira Released flag. Work Package membership in each Version is preserved by linking the migrated Issue to the corresponding Fix Version. OpenProject milestone types (date-bearing) map to Jira versions with a target release date set.

OpenProject's hierarchical work package structure (parent-child relationships within a project) maps to Jira's parent Issue relationship. We extract the parent ID from the source export and write the child Issue with the parent reference resolved. Jira does not support multi-level hierarchy within the same Issue Type in the same way OpenProject does; we preserve up to two levels of hierarchy and document deeper trees for manual restructuring.

OpenProject time entries (hours, rate, cost, user, work package association) map to Jira worklog entries on the corresponding Issue. Jira requires Premium or Data Center for built-in time tracking visibility; on Standard tier, worklog is accessible via API and reporting tools but not the native UI. We flag the tier requirement during scoping and migrate time data regardless so the data is present if the customer upgrades post-migration.

OpenProject attachments (file metadata: filename, mime type, author, created date, file content) map to Jira Issue attachments. The OpenProject API limits file link creation to 20 per request; we chunk large attachment sets into batches of 20 or fewer, pre-scanning the source export to identify work packages above the threshold. Jira Cloud supports up to 2 GB per issue; we verify total attachment volume per issue against this limit before migration.

OpenProject wiki pages (Markdown content per project) have no direct Jira equivalent. Jira and Confluence are separate Atlassian products. We migrate wiki page content as Markdown files preserved in a structured archive and recommend Confluence as the destination for project documentation. If the customer holds a Confluence license, we can map wiki pages to Confluence spaces and pages with the project as the parent. This is an optional scope item confirmed during scoping.

OpenProject users (name, email, login, admin flag) map to Jira user accounts. Memberships (project-user-role assignments) map to Jira project role memberships. We match users by email; any OpenProject user without a Jira account goes to a reconciliation queue for the customer's admin to provision. Roles are mapped using the OpenProject role name as the Jira project role name.

OpenProject custom fields (Enterprise-only: text, integer, float, Boolean, list, date, user, hierarchy formats) require equivalent Jira custom field definitions created before migration. Jira's custom field context scoping per project means each destination project needs the custom field added to its context. We pre-create all Jira custom fields with matching types during schema design, add them to the relevant context, and then migrate values as a post-project-creation step.

OpenProject cost tracking (labour costs, unit costs, budget values per work package via the Costs module) has no direct Jira equivalent. Jira does not natively support cost tracking or budget fields. We preserve cost entry data as Jira custom number fields on the Issue, flag the limitation in the migration inventory, and recommend an Atlassian Marketplace add-on (e.g., BigGantt, tempo-timesheets) if ongoing cost tracking is required post-migration.