docs/installation-and-operations/jira-migration/field-mapping/README.md
| Jira field | Becomes in OpenProject | What you should know |
|---|---|---|
| Old/renamed project keys | Also work as project identifier | If a Jira project was renamed, the old key still resolves to the same project afterward |
| Project description | Project description | Copied as-is |
| Project key | Project identifier | - |
| Project name | Project name | Copied as-is |
Every migrated project is created private and active, with no parent — this isn't based on anything in Jira, it's just how the tool creates them.
| Jira field | Becomes in OpenProject | What you should know |
|---|---|---|
| Affects Versions | Not migrated | — |
| Assignee | Assignee | — |
| Attachments | Attachments | Re-uploaded to the work package, original author preserved where possible |
| Change history (status changes, field edits, etc.) | Activity entries | Preserved, but grouped more coarsely than Jira's own history — see the Post-Migration checklist |
| Comments | Activity/notes | Author and date preserved; text converted from Jira markup |
| Components | Not migrated | — (planned: JIM-107) |
| Creator | Author | — |
| Description | Description | Converted from Jira's markup to OpenProject's — headings, bold/italic, links, code/quote blocks, and tables all convert. Some elements don't: {info}/{warning}/{note}/{tip} boxes, {toc}, and {expand}/{section}/{column} layouts aren't recognized at all — their content is kept, but the raw {macro} tag text is left behind, visible and unconverted, rather than being cleanly stripped or styled. Bare issue-key links like [PROJECT-123] and attachment links like [^file.pdf] are also left as literal, non-clickable text. See the Pre-Migration checklist and Post-Migration checklist |
| Due date | Due date | Copied as-is |
| Environment | Not migrated | — |
| Fix Versions | Not migrated | — (planned: JIM-154) |
| Issue creation date | Work package created date | Set to date when the migration ran, not the original date of the issue in Jira. (tracked: JIM-189) |
| Issue id | Not migrated | Internal Jira ID (planned: JIM-8) |
Issue key (e.g. PROJECT-123) | Work package identifier | Old/renamed issue keys also keep working afterward, the same way as project keys |
| Issue links (blocks/relates to/etc.) | Not migrated | — (planned: JIM-76) |
| Issue type | Type | Matched by name (not case-sensitive); a new Type is created automatically if nothing matches, and it's attached to the right projects (mirroring Jira's per-project Issue Type Scheme). Only the name comes across. No migrated type is marked as the project's default, even if it was the default in Jira. |
| Logged work / time entries | Not migrated | Only the two estimate fields above come across, not actual logged time (planned: JIM-93) |
| Original time estimate | Estimated hours | Copied as-is |
| Priority | Priority | Matched by name (not case-sensitive); created automatically if missing. If an issue has no priority in Jira, OpenProject's default priority is used. Only the name comes across — Jira's severity order, colors, and icons aren't preserved, and this matters beyond appearance: OpenProject falls back to whichever priority ends up first in the list when an issue has none set |
| Remaining time estimate | Remaining hours | Copied as-is |
| Reporter | Not migrated | Jira's "Reporter" concept doesn't exist in OpenProject and is dropped; only Creator becomes Author |
| Resolution | Not migrated | Jira tracks why an issue was closed (Fixed, Won't Fix, Duplicate, Cannot Reproduce) separately from its workflow state (Status). Only Status comes across — the reason is dropped entirely, and several different Jira resolutions can end up mapped to the same single OpenProject status with no trace of which one applied (planned as a custom field: JIM-149; broader native support tracked as FND-231) |
| Resolution date | Not migrated | — |
| Security Level | Not migrated | — |
| Status | Status | Matched by name (not case-sensitive); created automatically if missing. Only the name comes across — a migrated status is never automatically marked as "closed" in OpenProject, even if it represented a finished state in Jira (e.g. Done, Closed, Resolved). This affects any filtering or reporting that depends on knowing which work packages are actually finished |
| Sub-tasks / parent-child links | Not migrated | — (planned: JIM-75) |
| Summary | Subject | Copied as-is |
| Votes | Not migrated | — |
| Watchers | Not migrated | — (planned: JIM-180) |
| Jira field | Becomes in OpenProject | What you should know |
|---|---|---|
| Active flag | Account status | Created locked; unlocked automatically only after you Approve the import, and only for users who were active in Jira |
| Display name | First / last name | Split automatically; single-word names get used for both |
| If a Jira user has no email, a placeholder one is generated so the account can still be created. Not always a direct 1:1 copy of the Jira value — see the email/username collision handling below | ||
| Jira group membership | OpenProject Group membership | Matched or created by name. Note: pulls in the user's entire Jira group list, not just groups relevant to the migrated projects |
| Username | Username | Not always a direct 1:1 copy either — see the email/username collision handling below |
| Password | Randomly generated | Jira passwords can't be migrated, so every new user needs a password reset or invitation afterward (planned: JIM-116) |
For field type mapping, supported/unsupported types, and edge cases, see the Custom fields migration documentation.
"To Do" and "TO DO" will correctly match to the same status. But "To-Do" vs "To Do", or "Doing" vs "In Progress", will each create their own separate status/type/priority. Standardize naming across Jira projects beforehand if you want them to merge.[email protected]) so both accounts can coexist. If a Jira user’s username already exists in OpenProject, the importer disambiguates it by appending the Jira user key to the username (e.g. name+JIRAKEY).locked, regardless of their status in Jira. Approving the import only unlocks users who were both (a) newly created by this specific run — not reused from an existing OpenProject account — and (b) marked active in Jira. Reused/matched accounts are left exactly as they were.[~username] mention found in a description or comment, the importer calls Jira's user endpoint directly — even if that person isn't otherwise referenced anywhere else in the imported data (e.g. never an assignee, author, or watcher). If resolved and imported, the mention renders as a genuine OpenProject <mention> tag (clickable, triggers a notification); if not resolvable, it falls back to flat @username text.firstname/lastname are derived by splitting Jira's displayName on the last whitespace character — not real name-parsing logic. A single-word display name gets duplicated into both fields. Characters not valid in an OpenProject name are stripped beforehand.