Migrate from Jira to Redmine

Migrate from Jira to Redmine: what the move involves

If a Jira renewal, a licensing change or a data residency rule is pushing issue tracking onto your own servers, the practical route to Redmine is a Jira CSV export loaded through Redmine's built-in CSV issue import. Most of the effort goes into preparation: the trackers, statuses, custom fields and users that the import needs must exist in Redmine before the first file is loaded. The total effort depends on how many projects you move, how many custom fields carry meaning, and how much issue history you need to keep. Jira Cloud's CSV export from the issue navigator handles up to 10,000 work items per export, so larger projects will need several exports, and you should confirm how your own Jira edition and data volume behave before you plan the schedule.

Redmine's import assistant expects the first line of the file to hold column names, which it maps to issue fields, and it matches assignees against existing Redmine usernames. That makes the user list the first thing to reconcile: every person who appears as an assignee or author in Jira needs a Redmine account with the same login, or the import will not assign their work correctly. Map Jira issue types and workflow statuses to Redmine trackers and statuses on paper first, then create the custom fields in Redmine with matching names and formats. Keep in mind that the third-party Jira migration scripts listed on Redmine's migration wiki are described there as neither tested nor supported, so do not build your process on them without your own validation.

The people who usually do this work are a platform or IT team with a Redmine administrator, supported by whoever owns the Jira projects. Redmine has no paid edition, because it is free under GPL v2, so the cost of the move comes from hosting, implementation work, any plugins you need, upgrades and the staff who maintain the server. Those costs are partly one-time (the migration and the first configuration) and partly recurring (patching, backups and the Redmine upgrade procedure, which includes migrating plugins). Ask any implementation partner for a fixed-scope quote based on a written list of projects, custom fields, users and history requirements, and confirm which Redmine release line you will support before you start.

Which Jira capabilities map to Redmine and which need rework

This table compares the Jira capabilities a team typically relies on with what Redmine provides out of the box. Read clean rows as direct carry-over, needs rework rows as work to rebuild or reconfigure, and gap rows as features to confirm with plugins or a process change before you commit to a migration.

Jira capability	Redmine fit	Status	What to confirm or rebuild
Issue tracking	Issues with trackers, statuses, priorities, assignees and relations	Clean	Map each Jira issue type to a Redmine tracker and each status to a Redmine status before importing
Custom fields	Custom fields on issues, projects and users, attached to trackers	Needs rework	Recreate each Jira custom field with matching type and options; the CSV import only maps fields that already exist
Boards and sprints	No built-in Jira-style Kanban boards or sprint objects; versions and the Gantt chart cover release planning	Gap	Confirm whether a board or sprint plugin meets your needs, or plan to use versions and queries instead
Workflows and permissions	Role-based access control per project; status transitions are set per role and tracker	Needs rework	Rebuild Jira workflows as Redmine role and tracker transitions, and review each role's permissions
Gantt charts and calendars	Built-in Gantt chart and calendar views	Clean	Re-enter dependencies and dates if your Jira plans used advanced roadmap data, since it does not carry over
Time tracking	Built-in time entries against issues, projects and activities	Clean	Confirm how Jira worklogs map to Redmine time entries and which activities you need
Wikis and documentation	Built-in project wikis; Confluence content is not imported	Needs rework	Move linked documentation separately and update links in issues that point to Confluence pages
LDAP sign-in	Built-in multiple LDAP authentication support	Clean	Confirm your directory structure and test sign-in with migrated usernames before cutover
SAML or OIDC sign-in	Not built in; sign-in through these protocols depends on a plugin	Gap	Confirm a plugin that meets your identity requirements and test it, or keep LDAP for the first phase
Attachments	Attachments on issues, subject to the CSV import route	Needs rework	Attachments do not come through the CSV import; plan a separate transfer and map links back to issues
Jira automation rules	No direct equivalent; email-based issue creation and plugins cover some cases	Gap	List every automation rule, then confirm plugins or scripts for each; third-party Jira migration scripts are unsupported

What data can leave Jira and how it reaches Redmine

Jira gives you two main ways to get data out, and Redmine gives you two main ways to get it in. Each route carries a different slice of your project history, so the export you choose decides what you must rebuild or copy by hand. Check each route against the item types, comments and attachments your teams depend on before you schedule a cutover.

Jira Cloud CSV export

The issue navigator's asynchronous Export CSV produces a file for the issues you filter, with up to 10,000 work items per export. Larger projects need several filtered exports, split by date range, project or issue type. Confirm which fields your export template includes, since comments and attachments do not always come through in a plain CSV. Test one export before planning the full set.

Jira Cloud backup

Backup for cloud covers work items, board and sprint data, comments, users and project configuration such as workflows and schemes. It does not cover automation rules, third-party apps or Assets, so those need separate documentation and rebuilding in Redmine. Use the backup as a reference copy and an archive of the full record, not as a file Redmine imports directly.

Automation rules and apps

Automation rules, third-party app data and Assets sit outside Jira Cloud backup. Inventory every rule and app your workflows depend on, such as approvals, notifications and field updates, before you retire Jira. Redmine has no equivalent of these rules out of the box, so each one needs a plugin, a manual process or an explicit decision to drop it.

Redmine CSV issue import

Redmine imports issues from CSV since version 3.2.0. The first line must hold column names, and the import assistant maps them to issue fields. Assignees must match existing Redmine usernames, and trackers, statuses and custom fields must exist before the import runs. Map Jira issue types to Redmine trackers and Jira statuses to Redmine statuses during the mapping step.

Redmine REST API

An administrator must enable the REST API before any script can call it. Core resources include issues, projects, users and time entries, which are marked stable, and requests authenticate with a per-user API key in the X-Redmine-API-Key header. Use the API for scripted, repeatable loads, and confirm comments and attachments are written in each run, because support for them depends on how your script calls the endpoints.

Comments and attachments checks

Comments and attachments are the most common losses in a Jira-to-Redmine move. A CSV import may carry issue text without the full comment thread, and attachments usually move as separate files that must be reattached or linked. Sample issues with long comment histories and large files in a test project, then compare counts and content in Redmine before you accept the load.

Migration sequence from Jira export to Redmine cutover

This sequence moves Jira issues into Redmine in controlled stages, so each project is inventoried, mapped, test-imported and verified before the team switches over. Each step produces a written artifact that the next step depends on, which keeps the cutover auditable.

Inventory Jira projects, workflows and users
The project lead and a Jira administrator list every project in scope, its issue types, workflow statuses, custom fields, components, versions and active users. Record which projects are still in use and which can be archived instead of migrated. The output is an inventory sheet that names each project, its item count and its owner, reviewed and signed off by the business owner. If your Jira is Cloud, confirm the export size per project, because the asynchronous CSV export from the issue navigator supports up to 10,000 work items per export.
Map Jira fields to Redmine trackers and statuses
Build a field mapping sheet that pairs each Jira issue type with a Redmine tracker, each Jira status with a Redmine status, and each Jira custom field with a Redmine custom field of a compatible format. Redmine's CSV importer maps columns to issue fields, so every Jira value you plan to keep needs a destination. Decide now how priorities, labels, components and sprints will be represented, since Redmine has no direct equivalent for every Jira concept. The output is a signed-off mapping sheet and a list of Jira data that will be left behind.
Prepare Redmine and create prerequisite data
An administrator installs Redmine on the target server, enables the REST API if the team plans to use it, and creates the trackers, statuses, custom fields, roles and projects defined in the mapping sheet. Every person who will be an assignee or author must already exist as a Redmine user with a username that matches the value in the Jira export, because the importer resolves assignees against existing usernames. Confirm the database, Ruby and Rails versions against the installation guide before building the server. The output is a configured Redmine instance and a user list reconciled against the Jira export, signed off by the administrator.
Run a CSV test import on a pilot project
Export one small, representative Jira project to CSV and import it into a pilot Redmine project using the import assistant. The first line of the file must contain column names, which you map to Redmine issue fields. Check the import log for rows rejected because of unknown assignees, invalid statuses or custom field formats, and correct the source data or mapping sheet until the log is clean. Compare record counts and a sample of issues side by side with Jira. The output is a validated import log and a list of known gaps that the business owner has accepted in writing.
Import all projects and reconcile counts
Repeat the validated process for each remaining project in the agreed order, saving each export and import log in a controlled location. Reconcile issue counts, open and closed status totals, attachment availability and a sample of comments against the Jira source for every project. Attachments and comments do not travel in a plain CSV, so confirm with the implementer or with your own test how these will be handled before you rely on them. The output is a reconciliation report per project and a signed-off list of projects that are ready for users.
Run a parallel period with both systems
Keep Jira available in read-only or limited use while a named group of pilot users works in Redmine for real tasks. Track defects in the Redmine migration, such as wrong statuses, missing assignees or broken links to moved content, and resolve them in the mapping or the import. Confirm access control in Redmine by testing each role against the permissions matrix, since Redmine roles and project membership replace Jira permission schemes. The output is a defect log that is closed out and a sign-off from the pilot group that the Redmine workflow covers their daily work.
Cut over and decommission Jira
Freeze Jira for the migrated projects, run a final incremental export of changes made during the parallel run, and import the delta into Redmine. Announce the cutover date, update links and bookmarks, and point integrations such as source control hooks and email routes to Redmine. Retain a complete, verified archive of the Jira export, including the export files and reconciliation reports, under your retention policy before any Jira instance is shut down. The output is a cutover record, an archive of the source data and written confirmation from the owner that Jira is retired for those projects.

What drives cost and duration in a Redmine migration

This table shows the components that move the cost and timeline of a Jira to Redmine move, and whether each one is paid once or keeps recurring. Read it as a checklist for the written quote: each driver should appear as a line item with its assumptions stated. Redmine has no license fee, so most of the money goes to mapping, import work, testing and the people who run the system afterward.

Cost driver	Why it changes cost or effort	One-time or recurring	What to ask for in a quote
Projects and issue volume	Each project needs its own mapping and test import, and Jira Cloud CSV export returns up to 10,000 work items per export, so large backlogs need more export batches and checks.	One-time	Batch plan, record counts per project, and reconciliation method
Custom field count and types	Every Jira custom field needs a matching Redmine custom field with the right format, scope and tracker assignment before import, and mismatched types usually mean rework.	One-time	Field inventory with a target Redmine field for each
Trackers, statuses and workflows	Trackers, statuses and role-based transitions must exist in Redmine before the CSV import maps to them. Complex Jira workflows with many conditions and validators need design decisions, not just mapping.	One-time	Mapping table for issue types and statuses, and a list of workflow rules that will not carry over
User mapping	Assignees must match existing Redmine usernames, so every Jira user who owns issues needs an account or a mapped login before import. Inactive or duplicate accounts add review time.	One-time, with ongoing account handling	User list with matching rules, account creation process and handling of departed staff
History, comments and attachments	The standard CSV route does not carry full change history or every attachment, so keeping them means a separate extraction and attachment handling step, which increases scope.	One-time	Written decision on which history and files must be kept, and where archived copies will live
Plugins and integrations	Jira apps, automation rules and SAML or OIDC sign-in do not transfer. Redmine plugins must be selected, tested and kept compatible with each Redmine version.	One-time to select, recurring to maintain	Plugin list with versions, compatibility statement for Redmine 7.0.x and maintenance terms
Hosting and database	Redmine supports PostgreSQL, MySQL and SQL Server. SQLite is not suited to multi-user production, so the database choice affects server sizing and backups.	Recurring	Architecture diagram, sizing assumptions and backup schedule
Upgrades and version planning	Redmine 7.0.x is the fully supported line, and the upgrade procedure requires database and file backups, plugin migration and cache clearing. Each Redmine upgrade is a planned change.	Recurring	Upgrade runbook, test environment scope and frequency of security patches
Internal staff who maintain Redmine	Someone must own administration, plugins, backups and user accounts. If no internal owner exists, that role becomes an ongoing service cost.	Recurring	Named owner, support hours and escalation path in writing

What goes wrong when moving Jira issues to Redmine

Most failed Jira-to-Redmine moves trace back to a handful of avoidable choices: trusting unsupported scripts, importing data before the target is ready, and running the tracker on a database that cannot handle multiple users. Each card below names one risk and the check that prevents it before the first import file is created.

Relying on third-party Jira scripts

Redmine's migration wiki lists third-party scripts for systems such as Jira, but describes them as neither tested nor supported. Treat any listed script as a starting point for your own review, not as a supported path. Before running one, read its source, run it against a copy of your data, and confirm who will fix it when it breaks. The supported route in this topic is Jira's CSV export into Redmine's built-in CSV issue import.

Importing before usernames match

Redmine requires assignees in the CSV to match existing usernames, so rows referencing people who have no Redmine account will not map cleanly. Export the Jira user list, create every required account in Redmine first, and agree on one username format, such as the login name your directory uses. Check reporter and assignee columns row by row on a test project before importing the full backlog.

Losing custom field types

Jira custom fields such as dates, multi-select lists or user pickers need matching custom fields in Redmine with the same format, and the import assistant only maps columns to fields that already exist. Create each custom field, set its type and whether it applies to the target trackers and projects, then confirm values survive on a sample of issues. Fields with no Redmine equivalent need a decision: drop them, store them in the description, or keep the Jira export as an archive.

Exceeding the 10,000 item export limit

Jira Cloud's asynchronous CSV export from the issue navigator returns up to 10,000 work items per export. Projects or filters larger than that will be silently incomplete if you assume one export is enough. Split the export by project, date range or saved filter, count the rows in each file against the Jira total, and keep the files in a fixed order so the import runs in a known sequence.

Running multi-user Redmine on SQLite

Redmine's installation guide says SQLite is not suited to multi-user production use, yet it is the easiest database to set up for a test. Teams often keep the test instance and move the same data into production without changing the database. Choose PostgreSQL, MySQL 8.0 to 8.4 with transaction isolation set to READ COMMITTED, or SQL Server 2012 or higher before the first import, and run the import rehearsal on that same engine.

Skipping the upgrade path

Redmine 7.0.x is the fully supported line, 6.1.x receives only bug fixes and security updates, 6.0.x receives only important security updates, and 5.1.x and older are unsupported. A tracker migrated onto an unsupported release inherits that exposure from day one. Pick a supported line, document the upgrade order (database and uploaded files backed up first, then configuration, uploads and plugins copied, then migrations run), and rehearse it on a copy before the first real release arrives.

How the Redmine move differs by starting point

When only a handful of projects move, the simplest route is Jira's CSV export from the issue navigator, which runs as an asynchronous export and supports up to 10,000 work items per export. Each project or filtered set of issues becomes one CSV file that Redmine's import assistant reads. Because the volume is small, most of the effort goes into preparing Redmine rather than into the export itself, since trackers, statuses, custom fields and user accounts must exist before the first import.

Export by filter: Build a saved filter per project in the issue navigator and export each one separately.
Map columns early: Compare the exported column headers with the Redmine custom fields you have created so the import assistant has matching targets.
Create users first: Assignees must match existing Redmine usernames, so confirm the account list before importing.
Plan a test import: Load one project into a non-production Redmine instance and check statuses, dates and attachments.
Rebuild the rest by hand: Workflows, automation rules and dashboards do not travel through CSV, so note them for manual rebuilding.

Before starting, confirm with your Atlassian administrator which fields the export includes for your site and whether attachments are needed, because the CSV route does not carry them in the same way as a full backup.

Questions teams ask before moving Jira to Redmine

Is Redmine free, and what costs remain after I switch?

Yes, Redmine has no paid edition. It is released under the GNU General Public License v2, so the software itself costs nothing to download and use. The remaining costs come from hosting, implementation, plugins, upgrades and the people who maintain the instance. Hosting is recurring, covering servers or cloud capacity, backups and database operations. Implementation is largely one-time, covering the import, trackers, statuses, custom fields and permissions you rebuild. Plugins, if you need SAML or OIDC sign-in or other features Redmine does not include, add licensing and upkeep decisions of their own. Ask any implementation partner for a quote built from a written scope that lists each of these components separately.

How long does a Jira to Redmine migration take?

The duration depends on the scope you agree, not on a fixed figure. The main drivers are the number of projects, the volume of work items, how many custom fields and workflows must be mapped to Redmine trackers, statuses and fields, how cleanly user accounts match, and whether you need attachments and history preserved. Jira Cloud's asynchronous CSV export from the issue navigator supports up to 10,000 work items per export, so larger projects need several exports and a consolidation step. Redmine's CSV importer then needs each mapping to be defined before the run. Plan a pilot project first, then the remaining projects in batches, and confirm the timeline with your team or partner in writing.

Do we need a consultant, or can our own team run the migration?

A competent internal team can run a small migration alone, provided it has Redmine administration skills and time to prepare. Redmine's CSV import is built into the product, so no extra software is required for the basic route. The work becomes harder when many projects, custom fields or permission schemes must be rebuilt, or when the team has not run a Rails application in production before. The third-party Jira migration scripts listed on Redmine's migration wiki are described there as neither tested nor supported, so do not rely on them without your own testing. An external partner can plan, implement, customize and document the target instance under a fixed-scope agreement, and can support upgrades later. Ask for the scope, deliverables and responsibilities in writing before work begins.

Will Jira comments, attachments and workflows carry over to Redmine?

Not automatically, so plan each item separately. The CSV route carries issue fields that you export and map, and Redmine expects the first line to hold column names that the import assistant maps to issue fields. Comments and attachments are not part of a plain issue CSV, so they need a separate extraction and re-attachment step if you must keep them. Jira workflows do not transfer as such. You recreate the equivalent trackers, statuses and transitions in Redmine, and you rebuild role-based permissions and custom fields by hand. Jira Cloud's backup covers work items, comments, users and project configuration such as workflows and schemes, but it excludes automation rules, third-party apps and Assets, so those need their own inventory. Confirm which of these matter to your audit trail before you start.

Can Redmine handle single sign-on the way Jira does?

Redmine supports multiple LDAP authentication sources natively, so directory-based sign-in is available without extra plugins. SAML or OIDC sign-in is not part of the core feature list and generally depends on plugins, so you should check which plugin you would use, its maintenance status and its compatibility with the Redmine version you run. Compare this with Atlassian's identity features in your current plan before deciding. If single sign-on is a hard requirement for your audit or security baseline, confirm the approach in a proof of concept before committing to a migration date.

What does the migration require from our internal team?

Your team needs to make decisions and provide access, more than it needs to write code. Expect to name owners for each project and approve how Jira issue types, statuses and custom fields map to Redmine trackers, statuses and fields. Someone must create the target users in Redmine with usernames that match the assignees in your export, because the importer requires assignees to match existing usernames. An administrator must enable the REST API if you plan scripted checks, and someone must own ongoing operations: backups of the database and uploaded files, upgrades and plugin compatibility. Redmine 7.0.x receives new features, bug fixes and security updates, while 6.1.x receives only bug fixes and security updates, so pick the supported line that fits your upgrade cadence.

How DeployOpen scopes and runs a Redmine migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a move from Jira to Redmine, we start with a written scope covering the trackers, statuses, users and custom fields that must exist before any CSV import runs, then build and test the import in your environment.

How we scope

We agree a written, fixed scope covering which Jira projects and fields move to Redmine and which stay behind.
We map Jira issue types to Redmine trackers, and Jira statuses and workflows to Redmine statuses, before any data moves.
We list every assignee and confirm each has a matching Redmine username, so the CSV import does not fail on ownership.

How we build

We deploy Redmine 7.0.x on your infrastructure with the database you select, and confirm the supported Ruby and database versions first.
We prepare the CSV exports from Jira, align column names with the first-line header Redmine expects, and run test imports on a copy.
We rebuild custom fields, roles and project structure by hand, and test that Gantt charts, calendars and permissions behave as scoped.

How we hand over

We deliver documentation of the field mapping, import steps, exceptions and the rebuilt configuration, so your team can repeat or audit the move.
We walk your administrators through reconciling issue counts and spot-checking history, attachments and assignees against the Jira source.
We document the upgrade procedure for Redmine, including database and file backups and plugin migration, for your own maintenance team.

How we support

Ongoing support, upgrades and security testing for the Redmine deployment are available as retainers after handover.
Retainers can cover moving to newer supported Redmine lines as they are released, with plugin compatibility checked before each upgrade.
Confirm with us in the quote which items are one-time migration work and which recur as retainer support.