Migrating from Jira to Redmine moves your issues, comments, and history into a self-hosted workspace you fully control. Done in the right order, the switch is predictable and keeps your data intact. This guide walks through every step from exporting Jira data to validating the final import in Redmine.
Time to plan for: a few hundred issues can move in a day. Instances with heavy attachments, worklogs, and custom fields take longer but most of that time goes to preparation and validation, not the CSV import itself.
Already deciding between the two tools? This guide assumes you’ve chosen Redmine. If you’re still weighing the options, read our Redmine vs Jira comparison first, then come back here to execute the move.
How do you migrate from Jira to Redmine?
You migrate from Jira to Redmine in four stages: prepare a matching Redmine structure, map Jira fields to Redmine fields, export Jira issues to CSV or via the REST API, then import them into Redmine. Attachments, comments, and worklogs require separate migration steps because they are not fully handled by the basic CSV issue import.
Before you start: plan the migration
A clean migration depends on decisions made before any data moves. Rushing the export is where teams lose history.
Confirm these four things first:
- Scope — decide which projects, issue types, and date ranges you actually need to move.
- Users — every Jira reporter and assignee must exist in Redmine before import.
- Downtime window — plan a freeze so no new Jira issues appear mid-migration.
- Rollback — keep Jira read-only until the Redmine import is fully validated.
According to the official Redmine documentation, the built-in CSV importer has shipped with Redmine since version 3.2, released in December 2015. That means most modern instances can import issues without any third-party plugin.
Manual migration vs. migration tools
There are two broad ways to make the move, and it’s worth choosing deliberately before you start.
Migration tools and scripts community-built scripts and paid migration services can automate much of the transfer. They’re faster on paper, but you inherit whatever field-mapping and formatting decisions the tool makes, and fidelity varies widely between them.
The manual path (this guide) Redmine’s built-in CSV importer plus the REST API for attachments, comments, and worklogs. It takes more hands-on effort, but you keep full control over how every field maps and how much history survives the move. For most teams migrating a system of record they’ll live in for years, that control is worth the extra hours which is why the rest of this guide follows the manual path.
Step 1: Prepare your Redmine target
Set up Redmine to receive the data before you export anything. A field has to exist in Redmine before Jira data can map to it.
Create the following in your Redmine instance:
- Projects that mirror your Jira projects.
- Trackers that match your Jira issue types (Epic, Story, Task, Bug).
- Statuses and a workflow matching your Jira workflow states.
- Priorities aligned to your Jira priority scheme.
- Custom fields for any Jira fields Redmine does not have by default.
- User accounts, matched to Jira users by email address.
If you’re setting up a fresh instance, our Redmine setup guide covers the base install first.
Step 2: Map Jira fields to Redmine fields
Field mapping is the core of any migration. This table shows how standard Jira fields translate to Redmine.
| Jira field | Redmine field | Notes |
|---|---|---|
| Issue Type | Tracker | Create one tracker per Jira issue type |
| Summary | Subject | Direct one-to-one mapping |
| Description | Description | Convert Jira wiki markup to Textile or Markdown |
| Status | Status | Recreate the workflow, not just the labels |
| Priority | Priority | Map High/Medium/Low to your scheme |
| Assignee | Assignee | User must exist in Redmine first |
| Reporter | Author | The importer credits the account running the import; preserving the original Jira reporter needs the REST API |
| Labels | Tags or custom field | Use the Tags plugin for a clean match |
| Story Points | Custom field (numeric) | See Step 6 for agile setup |
| Sprint | Version or agile board | See Step 6 for agile setup |
| Epic Link | Parent issue | Recreate the Jira hierarchy using Redmine parent/child issues where appropriate |
| Worklog | Time entry | Move via API, preserving logged hours, work date, activity, and user where supported |
| Comments | Journal notes | Move via API; preserving original author and timestamp may need extra logic, as the standard API does not expose arbitrary journal author/timestamp fields |
| Attachments | Attachments | Move separately via the REST API or another method; CSV import does not transfer files |
Two rows deserve extra care. The Description field is the messiest part of the whole migration: Jira wiki markup rarely converts cleanly to Textile or Markdown, and code blocks, tables, panel macros, and @mentions are the usual casualties budget time to repair formatting by hand after import. The Reporter field is the other trap. A CSV import credits every issue to the account running the import, so restoring the original Jira reporter takes additional migration logic through the REST API.
Document every mapping decision in a shared sheet it becomes your checklist during validation.
Step 3: Export your data from Jira
Jira offers two export paths, and most migrations use both together.
CSV export handles the bulk of structured issue data:
- Open your Jira project and run a filter for the issues to migrate.
- Choose the CSV export option that includes all required fields.
- Save the file with UTF-8 encoding to protect special characters.
REST API export handles data that CSV does not fully cover, such as attachments, comments, and worklogs. Pull these with a script that reads the Jira REST API and stores each item against its issue key. Additional migration logic may be required to preserve Jira-specific authorship, timestamps, or metadata.
Step 4: Import issues into Redmine
Redmine’s built-in importer reads your CSV and creates issues directly. No plugin is required for this step.
Follow this sequence:
- Open the issue import option in your target Redmine project and upload the CSV file.
- Set the encoding to UTF-8 and select the correct separator.
- Match each CSV column to its Redmine field using your mapping sheet.
- Run a test import on 10 issues first to catch mapping errors early.
- Review the sample, fix any mismatches, then run the full import.
A small test batch is the single most valuable habit in any migration — it surfaces problems while they’re still cheap to fix, before a bad column map can corrupt thousands of issues.
Step 5: Move attachments, comments, and worklogs
CSV import handles structured issue fields but does not transfer attachment files. Attachments, comments, and time logs require separate migration steps, which can include the Redmine REST API and custom migration logic.
Use your Jira API export from Step 3 and a script that:
- Uploads each attachment to its matching Redmine issue.
- Adds each Jira comment as a Redmine journal note. Preserving the original Jira author and timestamp may require additional migration logic.
- Creates a Redmine time entry for each Jira worklog, mapping the available user, work date, hours, and activity information.
This step preserves the project history the basic CSV import leaves behind. Skip it and you quietly lose attachments, comments, and worklogs.
Step 6: Recreate agile boards and sprints
Jira sprints and boards have no direct CSV equivalent in Redmine, so they’re rebuilt after the import using an agile board plugin such as the RedmineFlux Agile Board plugin. This is also where your migrated Story Points come back into play.
After import:
- Install the Agile Board plugin on your Redmine instance.
- Map your Story Points custom field to the board’s estimate field.
- Recreate the required sprint structure and assign the migrated issues accordingly.
- Configure the board columns to match your workflow statuses.
If you need to keep historical sprint data, store it in a custom field during import so it isn’t lost.
Step 7: Validate the migration
Validation confirms the import matched the plan. Never decommission Jira before this step passes.
Check each of these against your Jira source:
- Issue counts per project match exactly.
- Attachments open correctly on a sample of issues.
- Comments show the right author and timestamp.
- Worklog totals match Jira’s reported hours.
- Parent-child links and relations are intact.
- Assignees and statuses are correct on a random sample.
Once every check passes, set Jira to read-only and announce the cutover to your team.
Common migration mistakes to avoid
Most failed migrations trace back to a handful of avoidable errors:
- Importing before users exist — assignees silently drop when the user is missing.
- Skipping the test batch — a bad column map then corrupts thousands of issues.
- Ignoring encoding — non-UTF-8 files mangle names and non-English text.
- Forgetting attachments — CSV-only migrations quietly lose every file.
- Decommissioning Jira too early — always keep a read-only source until validation passes.
Frequently asked questions
Can you migrate from Jira to Redmine without losing data?
A well-planned migration can preserve issues, comments, attachments, worklogs, and much of the available history. Issues migrate through Redmine’s CSV importer, while attachments, comments, and time logs require separate migration steps. Some Jira-specific metadata may need custom logic or may have no direct equivalent in Redmine. Validating counts and samples against Jira before cutover helps identify missing or mismatched data.
How long does a Jira to Redmine migration take?
A small project of a few hundred issues may migrate in a day, depending on data complexity and approach. Larger instances with attachments, worklogs, comments, and custom fields take longer. The biggest time factors are preparation, field mapping, user setup, data transformation, and validation not the CSV import itself.
Do you need a plugin to import Jira issues into Redmine?
No third-party plugin is required for a basic issue import. Redmine’s built-in CSV importer has been available since version 3.2. Plugins are useful for extended functionality, such as recreating agile boards and sprint workflows after the import.
What happens to Jira sprints after migrating to Redmine?
Jira sprints have no direct CSV equivalent in Redmine. You can recreate the sprint structure using an agile board plugin and configure the board’s estimate field to use a Redmine custom field for Story Points. Historical sprint information can be retained in a custom field if the migration plan calls for it.
Can you migrate Jira attachments and comments to Redmine?
Yes, but they require separate migration steps. CSV import handles structured issue fields, while attachments and comments migrate via the Redmine REST API and custom logic. A migration script can upload each attachment to its corresponding issue and add Jira comments as journal notes. Preserving the original comment author and timestamp may require additional logic, because Jira and Redmine use different data models.
Ready to run Redmine the way your team needs?
Migrating is the first step. The RedmineFlux plugin suite adds the agile boards, dashboards, and time tracking that make Redmine feel complete after the switch.