Migrate from Redmine to Jira

Redmine Projects map directly to Jira Projects. We pull the full project hierarchy including subprojects via Redmine's REST API (or direct DB query) and recreate the parent-child structure in Jira as Jira Projects with parent Project keys. Project description, enabled modules, and lead user migrate. Note that Jira requires project administrators to configure the project before data import can begin.

Redmine Issues map to Jira Issue Type scheme entries. We map Tracker values (Bug, Feature, Support, etc.) to Jira Issue Types (Bug, Story, Task, Epic) that we pre-create in the target project. Standard fields—subject, description, status, priority, assignee, reporter, due date, start date—migrate directly. Custom field values migrate as a secondary step after Jira custom fields are created and mapped. Note that CSV exports exclude issue history from the journals table; we extract journals separately via direct DB query or REST API and append them as Jira comments with a [Migrated from Redmine] prefix and original timestamp.

Redmine Versions (milestones) map to Jira Fix Version values. Each Version carries a name, description, due date, and status (open, locked, closed) that transfer directly as Jira Fix Versions within the target project. We pre-create all Versions before importing Issues so that Fix Version can be set during Issue migration.

Redmine Time Entries map to Jira worklog entries. Each Time Entry carries hours, activity (enumeration), comments, user, and date. We preserve hours and comments as Jira worklog (via Tempo if the customer licenses it, or via the native worklog API on applicable Jira tiers). Note that Jira's free tier does not include native worklog; we flag this gap during scoping and the customer decides whether to license Tempo or accept worklog as out-of-scope.

Redmine Custom Fields are defined separately via /custom_fields.json and apply to specific object types. We retrieve all Custom Field definitions first (name, format, possible_values, multiple flag), then create equivalent Jira Custom Fields in the target project. Text, number, date, list, boolean, and user Custom Fields map to Jira's text field, number field, date picker, single/multi-select, checkbox, and user picker respectively. Custom fields must be created and assigned to the relevant Issue Type scheme before Issue import begins.

Redmine Users (login, first name, last name, email, admin flag) map to Jira Users. We match by email address during migration. Note that Redmine does not store password hashes compatible with Jira's authentication model (Atlassian account, SAML, or LDAP), so migrated users must receive Jira invitations or be provisioned via the customer's identity provider post-migration.

Redmine Groups organize Users for role-based access. We recreate Groups in Jira and populate membership. Note that Jira Groups must be explicitly added to project permissions via Permission Schemes; we document the Group-to-permission mapping as part of the migration scope and the customer's admin applies it post-migration.

Redmine Trackers (Bug, Feature, Support, and any custom trackers) are enumerations that categorize Issues. We map Tracker names and custom tracker definitions to Jira Issue Types pre-created in the target project. Each Issue Type in Jira has its own workflow and screen, so we document which Tracker maps to which Issue Type and configure the Issue Type scheme accordingly before migration.

Redmine Issue Statuses (New, In Progress, Resolved, Closed, Feedback) map to Jira Status values. We align active Redmine statuses to Jira statuses within the target project's workflow. Deprecated or closed statuses migrate with a flag indicating archived status. The workflow transitions are pre-configured in Jira before Issue import to avoid status assignment errors.

Redmine attachments are stored on the filesystem (typically under Redmine's /files directory) with metadata in the database. We enumerate the /files directory during discovery, copy each file, and re-upload to Jira using the corresponding Issue key to relink them. This step is separate from database migration because a database-only migration loses all attachments. File size limits in Jira Cloud (32 MB per attachment) may require chunking for large files.