Migrate from Redmine 3.3 to Jira

Redmine Projects map to Jira Projects. A Redmine subproject becomes a standalone Jira Project in the same Jira Project Category, preserving the original subproject name and identifier in the Jira Project key for traceability. Module enablement (wiki, repository, forums, time tracking) per Redmine project maps to Jira project features toggled during project creation. The Redmine project identifier (e.g., ACCT) becomes the Jira project key.

Redmine Issues migrate to Jira Issues with subject as Summary, description as Description (stored as Atlassian Document Format or plain text depending on the target Jira version), and done_ratio mapped to a Jira custom field percentage__c since Jira Issues do not have a native done ratio on standard fields. Status from Redmine (New, In Progress, Resolved, Feedback, Closed) maps to a Jira workflow status after the destination workflow is configured in Jira's workflow designer. Priority maps directly.

Redmine Trackers (Bug, Feature, Support, or custom) configure to Jira Issue Types. We create Issue Type screen schemes per Jira project to map each Redmine Tracker to a Jira Issue Type, ensuring that the correct fields appear for each type after migration. Custom Tracker definitions from plugins require schema auditing before mapping because some plugins store tracker metadata in non-standard tables not surfaced by the REST API.

Redmine Versions (milestones or releases within a project, with effective date and description) map to Jira Fix Versions. The Redmine version status (open, locked, closed) maps to a Jira Version status. Jira does not have a direct Affects Version model equivalent for unreleased version tracking, so affected-version tracking uses Fix Version for both directions unless the customer requests a custom Affects Version configuration.

Redmine list-format custom fields store numeric internal IDs in the issue record, not display labels. We query the custom_field definitions endpoint and the custom_field_possible_values table to build an ID-to-label lookup table before processing any issue export. Display values are substituted at write time so that Jira receives human-readable values instead of raw integers. Free-text and date custom fields migrate directly without lookup resolution.

Redmine Time Entries (hours, activity, comments, spent_on, issue association) map to Jira Worklogs. Redmine's activity field (e.g., Design, Development, Meeting) has no direct Jira equivalent, so we preserve it as a custom field redmine_activity__c on the Jira Issue. Time entries linked to a specific Issue are attached to the migrated Jira Issue; time entries linked to a Project without an issue are attached to the Jira Project's custom project-level worklog field if the Jira project type supports it.

Redmine user accounts (login, firstname, lastname, email, admin flag) map to Jira user accounts. We match by email address. Redmine role-based membership assignments per project map to Jira project role memberships (Viewer, Member, Admin) based on the Redmine role permissions recorded in the memberships table. Users without a matching Jira account are held in a reconciliation queue for the customer's admin to provision before record import begins.

Redmine typed issue relations (blocks, blocked by, relates to, duplicates, follows, precedes) map to Jira Issue Link types. We export the full relation graph from Redmine's issue_relations table, then resolve target issue IDs after the Jira Issue IDs are assigned during migration so that links attach to the correct records. Redmine's internal issue ID is preserved in a custom field redmine_issue_id__c for cross-reference during reconciliation.

Redmine stores uploaded files on the server filesystem under files/ and records file path and metadata in the database. We extract file paths from the attachments table, verify file accessibility, download each file, and re-upload to Jira via the REST API with the same filename and content-type. Files attached to wiki pages or documents are handled as issue attachments after migration since Jira does not have a native wiki structure equivalent.

Redmine wikis are project-scoped with page hierarchy and wiki-format content. Jira does not have a native wiki. We export wiki content as structured text and either create Jira issue descriptions (for single-page context) or deliver a written inventory of all wiki content organized by project for the customer to rebuild in Confluence or Jira's native documentation features. Page-level permissions from Redmine cannot be directly mapped to Confluence permissions without a separate permission audit.