Migrate from OpenProject to Jira

OpenProject Projects map directly to Jira Projects. Each OpenProject project hosts its own activated Modules, Members, Versions, Boards, and Work Packages. We preserve the project identifier, name, description, and public/private flag. Jira project template selection (Scrum, Kanban, Bug Tracking, or Project Management) is determined during scoping based on the OpenProject project's enabled modules. Projects are created before any Work Package import to satisfy the Jira project key dependency.

OpenProject Work Packages map to Jira Issues. The Work Package subject becomes Issue Summary, description migrates as the Jira Description field (HTML content converted to Jira Wiki markup), and the Type maps to the Jira Issue Type (Task, Bug, Feature, Epic, Story, Milestone). Parent-child relationships between Work Packages map to Jira Subtask links or Issue-Hierarchy links depending on Jira configuration. Assignee resolution uses email matching against Jira User accounts. Priority values are mapped from OpenProject Priority (low, normal, high, urgent) to Jira Priority (Lowest, Low, Medium, High, Highest).

OpenProject Types (Task, Bug, Feature, Phase, Milestone) are customizable per project. We map each OpenProject Type to the closest Jira Issue Type in the destination project. OpenProject's Type-specific field visibility configuration (which attributes are shown per Type) has no direct Jira equivalent and is noted as a post-migration layout configuration step. The Type name and description migrate as metadata.

OpenProject Statuses (New, In Progress, Resolved, Closed, etc.) and their workflow transition rules per Type map to Jira Statuses and Status Categories (To Do, In Progress, Done). Custom statuses require explicit mapping to Jira Status values during scoping. OpenProject's workflow transition rules are Jira-specific and must be reconstructed in Jira's Workflow Designer post-migration; we provide the transition map as part of the written inventory.

OpenProject Versions serve two purposes: milestone-based Version tracking (equivalent to Jira Fix Version) and sprint-based scheduling (partially equivalent to Jira Sprint in Scrum boards). We split this mapping: Versions with a scheduled sprint flag in OpenProject are created as Jira Sprints within the appropriate Scrum board; static Versions are created as Jira Versions (Fix Versions). Version date ranges are preserved on the Jira Version record. The original OpenProject Version identifier is stored in a Jira custom field for traceability.

OpenProject Kanban and Scrum Boards are derived from work package queries. We recreate these as Jira Board configurations, preserving column-to-status mappings and query filters. Jira's Board is tied to a saved Filter (JQL query) that determines which issues appear. OpenProject's board-specific swimlane settings require manual configuration in Jira Board settings post-migration. Board sharing and project membership map to Jira Board permissions.

OpenProject Time Entries (hours, cost type, rate, spent against a Work Package) map to Jira Issue Worklogs. The hours value converts directly. OpenProject's cost type and rate are preserved in Jira custom fields on the worklog or the issue. Time entry author maps to Jira User by email match. Note that OpenProject time entries are hours-only, and Jira's Log Work supports days, hours, or original estimate units; we set the display unit preference during schema setup.

OpenProject custom fields (instance-specific, various types including text, number, list, user, date, boolean) require explicit schema creation in Jira before values import. We create the equivalent Jira custom field with the matching type during schema design, activate it on the destination project, and map values field-by-field during import. Custom fields that span multiple OpenProject projects with different configurations are split into separate Jira custom fields per project context. The original OpenProject custom field name is preserved in a Jira label or description for reference.

OpenProject Users (email, name, login, admin status, global roles) map to Jira User accounts by email address. We resolve users referenced on Work Packages (Assignee, Responsible), Time Entries, and Members by email. Users without a matching Jira account are held in a reconciliation queue for the customer's admin to provision before record import. Global roles and admin status in OpenProject have no direct Jira equivalent and are noted for manual permission configuration in Jira project roles.

OpenProject Members are user-project assignments carrying a Role (permission set). These map to Jira Project Roles (Administrators, Members, Viewers) and Project Memberships. Role names are preserved in a Jira custom field on the project for reference. OpenProject's granular module-level permissions require mapping to Jira's project-level and issue-level security schemes; this mapping is provided in the written inventory for manual configuration.

Attachments on OpenProject Work Packages are stored either in the database (small files) or on disk (larger files). We migrate attachment metadata (filename, size, uploader, timestamp) and handle file transfer via the Jira REST API. Disk-path remapping is required for on-disk OpenProject files. Jira Cloud has a 1TB per-site aggregate attachment limit; we flag this during scoping if the source attachment volume approaches this threshold. Null-filename attachments in OpenProject are skipped and listed in the reconciliation report.

OpenProject Wiki pages within a project are project-level structured text content. Jira does not have a native wiki. If the customer uses Confluence alongside Jira, we map OpenProject Wiki content to Confluence Pages within the same Space as the Jira project. If no Confluence exists, Wiki content is exported as structured Markdown files for manual recreation. Wiki-page work package links are converted to Jira issue links in the Confluence Page.