Migrate from Easy Redmine to Jira

Easy Redmine projects map 1:1 to Jira projects. Each Jira project has a project key (e.g., PROJ) that prefixes all issue keys (PROJ-123). Sub-projects in Easy Redmine map to Jira sub-projects or to a Jira project with a shared JQL filter. Project settings (description, lead, default assignee) migrate as project configuration fields.

Easy Redmine's issue is the core record. Its tracker type (Bug, Feature, Support) maps to a Jira issue type per the mapping plan. Jira issue types have their own workflows, fields, and screen configurations — we create one issue-type mapping per tracker so the right Jira type receives each migrated issue. Sub-issues in Easy Redmine (parent_id set) migrate as Jira subtasks with the parent link preserved.

Easy Redmine statuses (New, In Progress, Resolved, Closed, Feedback) map to Jira statuses (To Do, In Progress, In Review, Done) via value-by-value mapping. Jira statuses are shared across projects via the Status categories (Unstarted, In Progress, Complete). Each status transition in Easy Redmine's workflow requires a corresponding Jira workflow transition in the target issue type's workflow.

Easy Redmine trackers (Bug, Feature, Support, Task) map to Jira issue types (Bug, Story, Task, Task respectively). Jira issue types are project-level and each has its own default workflow. Epic is a Jira-native issue type — if Easy Redmine uses an 'Epic' tracker, it maps directly to the Epic issue type. We apply the mapping per project based on which trackers exist in the source.

Easy Redmine versions (milestones with target date and status) map to Jira Fix Version for resolved releases and Affects Version for reported releases. Versions are created per Jira project before data migration so the import can reference them by name. Released/unreleased state and release date transfer as Jira version attributes.

Easy Redmine users (login, firstname, lastname, mail, admin flag) map to Jira users by email match. Active/inactive status transfers. Jira requires users to exist in the target instance before issue assignment — unmatched users are flagged pre-migration for your Jira admin to provision or reassign to a fallback user.

Easy Redmine time entries (hours, spent_on, activity, comments, user) map to Jira worklog entries on the corresponding issue. Jira's native worklog stores hours, started date, and author. If Jira Tempo is in use, time entries align with Tempo's schema (Tempo Worklog entity). Original timestamps and activity type preserved as worklog metadata.

Easy Redmine issue relations (relates, blocks, blocked by, duplicates, precedes, follows) map to Jira issue link types. Jira has built-in link types (blocks, is blocked by, duplicates, relates to, cloners, etc.). We create the link records after both issues exist in Jira, using the relation type from the source to select the matching Jira link type.

Easy Redmine global custom fields (defined at the instance level and applied to projects) require Jira custom field creation before migration. Each custom field's data type (text, integer, date, list) determines the Jira field type to create. Jira custom fields are global by default but scoped to projects via field configuration schemes. We pre-create the Jira fields and map them in the import plan.

Easy Redmine file attachments (filename, content_type, filesize, created_on) re-upload to Jira via Jira's REST API attachment endpoint. Files are downloaded from Easy Redmine's storage and uploaded to the corresponding Jira issue. File size limits apply (Jira default 10MB, configurable to 25MB). Inline images in descriptions are downloaded and re-hosted as Jira attachments.

Easy Redmine wiki pages are project-level documentation. If your team uses Confluence, wiki content migrates to Confluence pages under the matching project space. Without Confluence, wiki content migrates as Jira issue descriptions (with a dedicated 'Documentation' issue type or a custom field). We preserve wiki formatting (Markdown → Confluence Storage Format or Jira XHTML) during transformation.

Easy Redmine news posts and forum threads have no Jira equivalent. Jira does not have a news or forum module. We export these as a structured JSON file for archival. If Confluence is available, they can be imported as pages in a 'Archive' space. This is disclosed as a migration gap upfront.

Easy Redmine plugins add tables outside the standard Redmine schema — Help Desk tickets, CRM contacts, Diagrams, and advanced Gantt data. Jira has no native equivalents for these modules. We map plugin-stored data to Jira custom fields or Jira Service Management tickets where applicable, and flag unrepresentable plugin data for manual extraction.

Easy Redmine priorities (Low, Normal, High, Urgent, Immediate) map to Jira priorities (Low, Medium, High, Highest). Value-by-value mapping applied based on the priority name. Jira priorities control how issues appear in the priority field and affect triage views but do not drive workflow transitions unless configured.

Easy Redmine issue categories are project-level classification labels. Jira's nearest equivalents are Components (per-project groupings) or Labels (cross-project tags). We map Easy Redmine categories to Jira Labels by default for cross-project flexibility, or to Jira Components if the category is strictly project-scoped in the source.